개요
이 제안서는 메시지를 전송할 때 대상 Destination의 LeaseSet에 있는 IBGWs 중 하나와 OBEP가 일치하도록 터널을 선택하거나 구축하는 아웃바운드 터널에 대한 I2CP 옵션을 추가합니다.
동기
대부분의 I2P 라우터는 혼잡 관리를 위해 패킷 제거 형태를 사용합니다. 참조 구현은 메시지 크기와 이동 거리를 모두 고려하는 WRED 전략을 사용합니다 (tunnel throttling 문서 참조). 이 전략으로 인해 패킷 손실의 주요 원인은 OBEP입니다.
설계
메시지를 전송할 때, 발신자는 수신자의 IBGWs 중 하나와 동일한 라우터인 OBEP가 있는 터널을 선택하거나 구축합니다. 이를 통해 메시지는 두 터널 사이를 직접 이동하며, 중간에 전송될 필요가 없습니다.
보안 영향
이 모드는 실제로 수신자가 발신자의 OBEP를 선택하게 되는 것을 의미합니다. 현재의 프라이버시를 유지하기 위해 이 모드는 outbound.length I2CP 옵션으로 지정된 대로 아웃바운드 터널이 한 홉 더 길어지도록 합니다 (마지막 홉은 발신자의 빠른 계층 외부일 수 있음).
명세
I2CP 명세에 새로운 I2CP 옵션이 추가됩니다:
outbound.matchEndWithTarget
Boolean
기본값: 사례별로 다름
true로 설정하면, 이 세션 동안 전송된 메시지의 아웃바운드 터널이 대상 Destination의 IBGWs 중 하나인 OBEP를 갖도록 라우터가 선택합니다. 해당 터널이 없을 경우, 라우터가 새로운 터널을 구축합니다.
호환성
라우터는 항상 자신의 메시지를 보낼 수 있기 때문에 하위 호환성을 보장합니다.
구현
Java I2P
터널 구축과 메시지 전송은 현재 별도의 하위 시스템입니다:
BuildExecutor는 아웃바운드 터널 풀의 outbound.* 옵션만 알고 있으며, 그들의 사용에 대해 가시성이 없습니다.
OutboundClientMessageOneShotJob는 기존 풀에서만 터널을 선택할 수 있습니다; 만약 클라이언트 메시지가 들어오고 아웃바운드 터널이 없다면, 라우터는 메시지를 버립니다.
이 제안서를 구현하려면 이 두 하위 시스템이 상호작용할 수 있는 방법을 설계해야 합니다.
i2pd
테스트 구현이 완료되었습니다.
성능
이 제안서는 지연 시간, RTT 및 패킷 손실에 다양한 영향을 미칩니다:
대부분의 경우, 이 모드는 기존 터널을 사용하기보다는 첫 메시지에서 새로운 터널을 구축해야 하므로 지연 시간이 추가될 가능성이 높습니다.
표준 터널의 경우 OBEP가 IBGW를 찾아 연결해야 하므로 지연 시간이 증가하여 첫 번째 RTT가 증가합니다 (첫 번째 패킷이 전송된 후 발생). 이 모드를 사용할 경우, OBEP는 터널을 구축하는 동안 IBGW를 찾아 연결해야 하므로 동일한 지연이 있지만 첫 번째 RTT는 감소합니다 (첫 번째 패킷이 전송되기 전에 발생).
현재 표준 VariableTunnelBuild 크기는 2641바이트입니다. 따라서, 평균 메시지 크기가 이보다 큰 경우, 이 모드는 패킷 손실을 줄이는 데 기여할 것으로 예상됩니다.
이러한 효과를 조사하여 어떤 표준 터널에 이 모드를 기본으로 활성화하는 것이 유익한지 결정하기 위해 더 많은 연구가 필요합니다.