다음은 2007년 3월에 진행된 NTCP에 대한 논의입니다. 현재 구현을 반영하여 업데이트되지 않았습니다. 현재 NTCP 사양은 NTCP2 페이지 를 참조하세요.
NTCP vs. SSU 논의, 2007년 3월
NTCP 질문들
(zzz와 cervantes 간의 IRC 토론에서 각색)
NTCP가 SSU보다 선호되는 이유는 무엇인가요? NTCP가 더 높은 오버헤드와 지연 시간을 가지지 않나요? 더 나은 신뢰성을 제공합니다.
NTCP를 통한 streaming lib이 전형적인 TCP-over-TCP 문제로 어려움을 겪지 않나요? streaming-lib에서 발생하는 트래픽을 위한 정말 간단한 UDP transport가 있다면 어떨까요? SSU가 그런 정말 간단한 UDP transport가 되어야 했다고 생각하는데 - 하지만 너무 신뢰할 수 없음이 입증되었습니다.
zzz의 “NTCP Considered Harmful” 분석
새로운 Syndie에 게시됨, 2007-03-25. 이것은 토론을 촉진하기 위해 게시된 것이니 너무 심각하게 받아들이지 마세요.
요약: NTCP는 SSU보다 지연 시간이 길고 오버헤드가 크며, streaming lib과 함께 사용할 때 연결이 끊어질 가능성이 더 높습니다. 그러나 트래픽은 SSU보다 NTCP를 선호하도록 라우팅되며, 이는 현재 하드코딩되어 있습니다.
논의
현재 우리는 NTCP와 SSU라는 두 가지 transport를 가지고 있습니다. 현재 구현된 바에 따르면, NTCP는 SSU보다 낮은 “bid"를 가지므로 선호되지만, 피어에 대해 설정된 SSU 연결은 있지만 설정된 NTCP 연결이 없는 경우는 예외입니다.
SSU는 확인응답, 타임아웃, 재전송을 구현한다는 점에서 NTCP와 유사합니다. 하지만 SSU는 타임아웃에 대한 엄격한 제약과 왕복 시간, 재전송 등에 대한 이용 가능한 통계를 가진 I2P 코드입니다. NTCP는 블랙박스인 Java NIO TCP를 기반으로 하며, 매우 긴 최대 타임아웃을 포함한 RFC 표준을 구현하는 것으로 추정됩니다.
I2P 내의 대부분의 트래픽은 TCP 구현체인 streaming-lib에서 발생하는 것들(HTTP, IRC, Bittorrent)입니다. 하위 레벨 전송이 일반적으로 낮은 입찰로 인해 NTCP이므로, 시스템은 잘 알려진 그리고 두려운 TCP-over-TCP 문제 http://sites.inka.de/~W1011/devel/tcp-tcp.html 에 취약합니다. 이는 TCP의 상위 및 하위 계층이 동시에 재전송을 수행하여 붕괴를 일으키는 문제입니다.
위의 링크에서 설명된 PPP over SSH 시나리오와 달리, 우리는 하위 계층에 여러 홉을 가지고 있으며, 각각은 NTCP 링크로 커버됩니다. 따라서 각 NTCP 지연 시간은 일반적으로 상위 계층 스트리밍 라이브러리 지연 시간보다 훨씬 적습니다. 이는 붕괴 가능성을 줄입니다.
또한, 하위 계층 TCP가 상위 계층에 비해 낮은 타임아웃과 재전송 횟수로 엄격하게 제한될 때 붕괴 확률이 줄어듭니다.
.28 릴리스에서는 최대 스트리밍 라이브러리 타임아웃을 10초에서 45초로 증가시켜 상황을 크게 개선했습니다. SSU 최대 타임아웃은 3초입니다. NTCP 최대 타임아웃은 RFC 권장사항인 최소 60초로 추정됩니다. NTCP 매개변수를 변경하거나 성능을 모니터링할 방법은 없습니다. NTCP 레이어의 붕괴는 [편집자: 텍스트 손실]. tcpdump와 같은 외부 도구가 도움이 될 수 있습니다.
그러나 .28을 실행할 때, i2psnark가 보고하는 업스트림은 일반적으로 높은 수준을 유지하지 않습니다. 다시 올라가기 전에 종종 3-4 KBps까지 떨어집니다. 이는 여전히 붕괴가 발생하고 있다는 신호입니다.
SSU가 더 효율적입니다. NTCP는 오버헤드가 더 높고 아마도 왕복 시간도 더 길 것입니다. NTCP를 사용할 때 (tunnel 출력) / (i2psnark 데이터 출력)의 비율은 최소 3.5 : 1입니다. SSU를 선호하도록 코드를 수정한 실험을 실행했을 때(현재 코드에서 설정 옵션 i2np.udp.alwaysPreferred는 효과가 없음), 비율이 약 3 : 1로 감소하여 더 나은 효율성을 나타냈습니다.
streaming lib 통계에 보고된 바와 같이, 상황이 크게 개선되었습니다 - 평생 윈도우 크기가 6.3에서 7.5로 증가하고, RTT는 11.5초에서 10초로 감소했으며, ack당 전송 횟수는 1.11에서 1.07로 줄어들었습니다.
아웃바운드 메시지가 거쳐갈 총 3~5개 홉 중 첫 번째 홉의 전송 방식만 변경했음에도 불구하고 이것이 상당히 효과적이었다는 점은 놀라웠습니다.
일반적인 변동으로 인해 아웃바운드 i2psnark 속도에 미치는 영향은 명확하지 않았습니다. 또한 실험을 위해 인바운드 NTCP가 비활성화되었습니다. i2psnark의 인바운드 속도에 미치는 영향은 명확하지 않았습니다.
제안서
1A) 이것은 쉽습니다 - 다른 모든 종류의 문제를 일으키지 않고 할 수 있다면, 모든 트래픽에 대해 SSU가 선호되도록 입찰 우선순위를 뒤바꿔야 합니다. 이렇게 하면 i2np.udp.alwaysPreferred 설정 옵션이 (true 또는 false로) 작동하도록 수정할 수 있습니다.
1B) 1A)의 대안, 그리 쉽지 않음 - 익명성 목표에 부정적인 영향을 주지 않고 트래픽을 표시할 수 있다면, streaming-lib에서 생성된 트래픽을 식별하고 SSU가 해당 트래픽에 대해 낮은 입찰가를 생성하도록 해야 합니다. 이 태그는 각 hop을 통해 메시지와 함께 전달되어야 하므로 forwarding router들도 SSU 선호도를 존중할 수 있습니다.
2) SSU를 더욱 제한하는 것(현재 10회인 최대 재전송 횟수를 줄이는 것)은 아마도 붕괴 가능성을 줄이기 위해 현명할 것입니다.
3) 스트리밍 라이브러리 하위의 준신뢰성 프로토콜의 이점 대비 해로움에 대한 추가 연구가 필요합니다. 단일 홉에서의 재전송이 유익하고 큰 이득이 되는지, 아니면 쓸모없는 것보다 더 나쁜지? 새로운 SUU (secure unreliable UDP)를 할 수 있지만 아마 가치가 없을 것입니다. 스트리밍 라이브러리 트래픽의 재전송을 전혀 원하지 않는다면 SSU에 확인응답 불필요 메시지 유형을 추가할 수 있을 것입니다. 엄격히 제한된 재전송이 바람직한가요?
4) .28의 우선순위 전송 코드는 NTCP 전용입니다. 지금까지 제 테스트에서는 SSU 우선순위가 크게 유용하지 않았는데, 메시지들이 우선순위가 효과를 발휘할 만큼 오래 대기열에 머물지 않기 때문입니다. 하지만 더 많은 테스트가 필요합니다.
5) 새로운 스트리밍 라이브러리의 최대 타임아웃 45초는 아마도 여전히 너무 낮습니다. TCP RFC에서는 60초를 명시하고 있습니다. 기본 NTCP 최대 타임아웃(추정 60초)보다 짧아서는 안 될 것 같습니다.
jrandom의 답변
새로운 Syndie에 게시됨, 2007-03-27
전반적으로 이것을 실험해보는 것에 대해서는 열린 마음을 가지고 있지만, 애초에 NTCP가 존재하는 이유를 기억해야 합니다 - SSU가 혼잡 붕괴에서 실패했기 때문입니다. NTCP는 “그냥 작동하며”, 일반적인 단일 홉 네트워크에서는 2-10%의 재전송률을 처리할 수 있지만, 2홉 tunnel에서는 40%의 재전송률을 가지게 됩니다. NTCP가 구현되기 전에 측정했던 SSU 재전송률(10-30%+) 중 일부를 고려하면, 83%의 재전송률을 가지게 됩니다. 아마도 그러한 비율들은 낮은 10초 타임아웃으로 인해 발생했을 수 있지만, 그것을 너무 많이 증가시키는 것은 우리에게 해가 될 것입니다(기억하세요, 5배로 곱하면 여정의 절반이 됩니다).
TCP와 달리, 메시지가 성공적으로 전달되었는지 알 수 있는 tunnel로부터의 피드백이 없습니다 - tunnel 레벨 확인응답(ack)이 없습니다. 종단 간 ACK는 있지만, 소수의 메시지에서만 사용됩니다 (새로운 세션 태그를 배포할 때마다) - 제 router가 보낸 1,553,591개의 클라이언트 메시지 중에서 145,207개만 ACK를 시도했습니다. 나머지는 조용히 실패했거나 완벽하게 성공했을 수 있습니다.
우리의 경우 TCP-over-TCP 논증에 확신이 서지 않습니다. 특히 우리가 데이터를 전송하는 다양한 경로들에 걸쳐 분할되는 상황에서는 더욱 그렇습니다. 물론 I2P에서의 측정 결과가 그 반대를 증명할 수도 있겠지만요.
NTCP 최대 타임아웃은 RFC 권장사항인 최소 60초로 추정됩니다. NTCP 매개변수를 변경하거나 성능을 모니터링할 방법은 없습니다.
맞습니다. 하지만 네트워크 연결이 그 수준에 도달하는 것은 정말 심각한 문제가 발생했을 때뿐입니다. TCP의 재전송 타임아웃은 보통 수십 밀리초에서 수백 밀리초 정도입니다. foofighter가 지적했듯이, 그들의 TCP 스택에는 20년 이상의 경험과 버그 수정이 축적되어 있고, 더불어 수십억 달러 규모의 산업이 하드웨어와 소프트웨어를 최적화하여 그들이 하는 일에 따라 잘 작동하도록 만들고 있습니다.
NTCP는 더 높은 오버헤드와 아마도 더 높은 왕복 시간을 가집니다. NTCP를 사용할 때 > (tunnel 출력) / (i2psnark 데이터 출력)의 비율은 최소 3.5 : 1입니다. > SSU를 선호하도록 코드를 수정한 실험을 실행했을 때 (현재 코드에서 > i2np.udp.alwaysPreferred 설정 옵션은 효과가 없음), 비율이 > 약 3 : 1로 감소하여 더 나은 효율성을 나타냈습니다.
이는 매우 흥미로운 데이터입니다. 하지만 대역폭 효율성보다는 router 혼잡 문제에 관한 것으로 보입니다 - 3.5*$n*$NTCPRetransmissionPct ./. 3.0*$n*$SSURetransmissionPct를 비교해야 할 것입니다. 이 데이터 포인트는 router에 이미 전송 중인 메시지들의 과도한 로컬 큐잉을 야기하는 무언가가 있음을 시사합니다.
lifetime window size가 6.3에서 7.5로 증가, RTT가 11.5초에서 10초로 감소, ACK당 전송 횟수가 1.11에서 1.07로 감소.
sends-per-ACK는 전체 카운트가 아닌 샘플일 뿐임을 기억하세요 (모든 전송에 대해 ACK를 시도하지 않기 때문입니다). 이것은 무작위 샘플도 아니며, 대신 비활성 기간이나 활동 버스트의 시작 시점을 더 집중적으로 샘플링합니다 - 지속적인 부하는 많은 ACK를 필요로 하지 않습니다.
해당 범위의 윈도우 크기는 AIMD의 실질적인 이점을 얻기에는 여전히 매우 낮으며, 단일 32KB BT 청크를 전송하기에도 여전히 너무 낮습니다 (최소값을 10 또는 12로 늘리면 이를 해결할 수 있습니다).
그래도 wsize 통계는 유망해 보입니다 - 그것이 얼마나 오랫동안 유지되었나요?
실제로 테스트 목적으로는 apps/ministreaming/java/src/net/i2p/client/streaming/에 있는 StreamSinkClient/StreamSinkServer 또는 TestSwarm을 살펴보는 것이 좋습니다. StreamSinkClient는 선택된 파일을 선택된 목적지로 보내는 CLI 앱이고, StreamSinkServer는 목적지를 생성하여 전송된 모든 데이터를 기록합니다(크기와 전송 시간 표시). TestSwarm은 이 둘을 결합하여 연결된 상대방에게 무작위 데이터를 플러딩합니다. 이러한 도구들은 BT choke/send와 달리 streaming lib를 통한 지속적인 처리량 용량을 측정할 수 있는 도구를 제공할 것입니다.
1A) 이것은 간단합니다 - > 다른 모든 종류의 문제를 일으키지 않고 할 수 있다면, 모든 트래픽에 대해 SSU가 선호되도록 입찰 우선순위를 뒤집어야 합니다. 이것은 i2np.udp.alwaysPreferred 설정 옵션이 작동하도록 수정할 것입니다(true 또는 false 중 어느 것이든).
i2np.udp.alwaysPreferred를 존중하는 것은 어떤 경우든 좋은 아이디어입니다 - 해당 변경사항을 자유롭게 커밋해 주세요. 하지만 기본 설정을 바꾸기 전에 조금 더 데이터를 수집해 봅시다. NTCP는 SSU로 인한 혼잡 붕괴를 해결하기 위해 추가된 것이기 때문입니다.
1B) 1A)의 대안, 그리 쉽지 않음 - > 우리가 익명성 목표에 악영향을 주지 않고 트래픽을 표시할 수 있다면, > streaming-lib에서 생성된 트래픽을 식별하고 > SSU가 해당 트래픽에 대해 낮은 입찰가를 생성하도록 해야 합니다. 이 태그는 각 hop을 통해 메시지와 함께 전달되어야 하므로 > 전달 router들도 SSU 선호도를 존중할 수 있습니다.
실제로는 세 가지 유형의 트래픽이 있습니다 - tunnel 구축/테스트, netDb 쿼리/응답, 그리고 스트리밍 라이브러리 트래픽입니다. 네트워크는 이 세 가지를 구별하는 것을 매우 어렵게 만들도록 설계되었습니다.
2) SSU를 더욱 제한하는 것(현재 10 이상인 최대 재전송 횟수를 줄이는 것)은 아마도 붕괴 가능성을 줄이기 위해 현명할 것입니다.
10번의 재전송에서는 이미 심각한 상황에 처해 있다는 데 동의합니다. 전송 계층 관점에서 1번, 아마도 2번의 재전송은 합리적이지만, 상대방이 너무 혼잡해서 제시간에 ACK를 보낼 수 없다면 (구현된 SACK/NACK 기능이 있음에도 불구하고), 우리가 할 수 있는 일은 많지 않습니다.
제 생각에는 핵심 문제를 실제로 해결하려면 router가 시간 내에 ACK하기에 너무 혼잡해지는 이유를 해결해야 합니다 (제가 발견한 바로는 CPU 경합 때문입니다). 새로운 tunnel 요청을 해독하는 것보다 이미 존재하는 tunnel의 전송을 더 높은 CPU 우선순위로 만들기 위해 router의 처리에서 몇 가지를 조정할 수 있을까요? 하지만 기아 상태(starvation)를 피하도록 주의해야 합니다.
3) 스트리밍 라이브러리 하단의 반신뢰성 프로토콜의 이점 대 피해에 대한 추가 연구가 필요하다. 단일 홉을 통한 재전송이 유익하고 큰 승리인가, 아니면 쓸모없는 것보다 나쁜가? > 새로운 SUU (secure unreliable UDP)를 만들 수 있지만 아마 그만한 가치가 없을 것이다. 스트리밍 라이브러리 트래픽의 재전송을 전혀 원하지 않는다면 SSU에 ACK 불필요 메시지 유형을 추가할 수도 있을 것이다. 엄격하게 제한된 재전송이 바람직한가?
살펴볼 가치가 있음 - SSU의 재전송을 그냥 비활성화하면 어떨까? 아마도 스트리밍 라이브러리의 재전송 비율이 훨씬 높아질 것 같지만, 그렇지 않을 수도 있다.
4) .28의 우선순위 전송 코드는 NTCP에만 적용됩니다. 지금까지 제 테스트에서는 메시지가 우선순위가 효과를 발휘할 만큼 충분히 오래 대기열에 머물지 않기 때문에 SSU 우선순위가 그다지 유용하지 않은 것으로 나타났습니다. 하지만 더 많은 테스트가 필요합니다.
UDPTransport.PRIORITY_LIMITS와 UDPTransport.PRIORITY_WEIGHT가 있고 (TimedWeightedPriorityMessageQueue에서 준수됨), 하지만 현재 가중치들이 거의 모두 동일해서 효과가 없습니다. 물론 이는 조정할 수 있습니다 (하지만 말씀하신 대로 큐잉이 없다면 중요하지 않습니다).
5) 새로운 스트리밍 라이브러리의 최대 타임아웃 45초는 아마도 여전히 너무 낮습니다. TCP RFC에서는 60초라고 합니다. 기본 NTCP 최대 타임아웃(아마도 60초)보다 짧지 않아야 할 것입니다.
그 45초는 스트리밍 라이브러리의 최대 재전송 타임아웃이지, 스트림 타임아웃이 아닙니다. 실제로 TCP는 훨씬 짧은 재전송 타임아웃을 가지지만, 노출된 케이블이나 위성 전송을 통한 링크에서는 60초까지 갈 수 있습니다 ;) 스트리밍 라이브러리의 재전송 타임아웃을 예를 들어 75초로 늘리면, 웹 페이지가 로드되기 전에 맥주 한 잔 마실 수 있을 겁니다 (특히 98% 미만의 안정적인 전송을 가정하면). 이것이 우리가 NTCP를 선호하는 이유 중 하나입니다.
zzz의 응답
새로운 Syndie에 게시됨, 2007-03-31
재전송이 10번에 이르면, 우리는 이미 심각한 상황에 처해 있다는 것에 동의합니다. 전송 계층 관점에서 보면 1번, 아마도 2번의 재전송이 합리적이지만, 상대방이 너무 혼잡해서 제때 ACK를 보낼 수 없다면 (구현된 SACK/NACK 기능을 사용해도), 우리가 할 수 있는 것은 많지 않습니다.
제 관점에서는 핵심 문제를 실제로 해결하려면 router가 왜 제때 ACK를 보낼 수 없을 정도로 혼잡해지는지 그 원인을 해결해야 합니다 (제가 발견한 바로는 CPU 경합 때문입니다). 아마도 router의 처리 과정에서 몇 가지를 조정하여 이미 존재하는 tunnel의 전송을 새로운 tunnel 요청을 복호화하는 것보다 더 높은 CPU 우선순위로 만들 수 있을 것입니다. 하지만 기아 상태(starvation)를 피하도록 주의해야 합니다.
제가 주로 사용하는 통계 수집 기법 중 하나는 net.i2p.client.streaming.ConnectionPacketHandler=DEBUG를 활성화하고 RTT 시간과 윈도우 크기가 변화하는 것을 관찰하는 것입니다. 잠시 일반화해서 말하면, 일반적으로 3가지 유형의 연결을 볼 수 있습니다: ~4초 RTT, ~10초 RTT, 그리고 ~30초 RTT. 30초 RTT 연결을 줄이는 것이 목표입니다. CPU 경합이 원인이라면 약간의 조정으로 해결할 수 있을 것입니다.
SSU 최대 재전송 횟수를 10에서 줄이는 것은 사실상 암중모색에 불과합니다. 우리가 연결이 끊어지고 있는지, TCP-over-TCP 문제가 발생하고 있는지, 아니면 다른 문제인지에 대한 충분한 데이터가 없기 때문에 더 많은 데이터가 필요합니다.
검토할 가치가 있음 - SSU의 재전송을 그냥 비활성화하면 어떨까? 아마도 스트리밍 라이브러리의 재전송률이 훨씬 높아질 것 같지만, 그렇지 않을 수도 있다.
제가 이해하지 못하는 부분이 있는데, 자세히 설명해 주실 수 있나요? 비스트리밍 라이브러리 트래픽에 대한 SSU 재전송의 이점이 무엇인지요. tunnel 메시지 (예를 들어)가 준신뢰성 전송을 사용해야 하는지, 아니면 비신뢰성이나 어느 정도 신뢰성 있는 전송 (예: 최대 1-2회 재전송)을 사용할 수 있는지요? 다시 말해서, 왜 준신뢰성인가요?
(하지만 말씀하신 대로, 대기열이 없다면 상관없습니다).
UDP에 대해 우선순위 전송을 구현했지만, NTCP 측 코드보다 약 10만 배 정도 덜 작동했습니다. 이것이 추가 조사를 위한 단서나 힌트일 수도 있습니다 - NTCP에서 왜 그렇게 자주 백업이 발생하는지 이해할 수는 없지만, 아마도 이것이 NTCP가 더 나쁜 성능을 보이는 이유에 대한 힌트일 수도 있습니다.
jrandom이 답변한 질문
새로운 Syndie에 게시됨, 2007-03-31
NTCP가 구현되기 전에 보았던 측정된 SSU 재전송률 > (10-30+%) > > router 자체에서 이를 측정할 수 있나요? 만약 그렇다면, 측정된 성능을 기반으로 > 전송 방식을 선택할 수 있을까요? (즉, 특정 피어로의 SSU 연결이 > 비정상적으로 많은 메시지를 손실하는 경우, 해당 피어로 전송할 때 NTCP를 선호)
네, 현재 그 통계를 간단한 MTU 탐지 방법으로 사용하고 있습니다 (재전송률이 높으면 작은 패킷 크기를 사용하고, 낮으면 큰 패킷 크기를 사용합니다). NTCP를 처음 도입할 때 (그리고 원래 TCP 전송에서 처음 벗어날 때) SSU를 선호하지만 해당 피어의 전송을 쉽게 실패시켜 NTCP로 폴백하도록 하는 몇 가지 시도를 했습니다. 하지만 이 부분에서 확실히 더 많은 작업이 가능하지만, 빠르게 복잡해집니다 (언제/어떻게 입찰가를 조정/재설정할지, 이러한 선호도를 여러 피어 간에 공유할지 여부, 같은 피어와의 여러 세션 간에 공유할지 여부 (그리고 얼마나 오랫동안), 등등).
foofighter의 응답
새로운 Syndie에 게시됨, 2007-03-26
제가 이해한 바로는, TCP를 선호하는 주된 이유(일반적으로 구버전과 신버전 모두)는 좋은 TCP 스택을 코딩할 걱정을 할 필요가 없다는 것이었습니다. 올바르게 구현하는 것이 불가능할 정도로 어려운 것은 아니지만… 기존 TCP 스택들이 20년의 앞선 경험을 가지고 있다는 점입니다.
제가 알기로는, 다음과 같은 고려사항들을 제외하고는 TCP 대 UDP의 선호도에 대한 깊이 있는 이론은 많지 않았습니다:
- TCP 전용 네트워크는 도달 가능한 피어들(NAT를 통해 들어오는 연결을 전달할 수 있는 피어들)에 매우 의존적입니다
- 도달 가능한 피어들이 드물더라도, 그들이 높은 용량을 가지고 있으면 토폴로지 부족 문제를 어느 정도 완화할 수 있습니다
- UDP는 “NAT 홀 펀칭"을 허용하여 사람들이 “일종의 의사 도달 가능한” 상태가 되도록 합니다(introducer의 도움으로) - 그렇지 않으면 외부 연결만 가능했을 것입니다
- “기존” TCP 전송 구현은 많은 스레드가 필요했으며, 이는 성능 저하 요인이었습니다. 반면 “새로운” TCP 전송은 적은 스레드로도 잘 작동합니다
- A 집합의 router들은 UDP로 포화되면 문제가 발생합니다. B 집합의 router들은 TCP로 포화되면 문제가 발생합니다.
- A가 B보다 더 널리 배포된 것으로 “느껴집니다” (즉, 일부 징후는 있지만 과학적 데이터나 품질 통계는 없습니다)
- 일부 네트워크는 non-DNS UDP 데이터그램을 매우 낮은 품질로 전달하면서도, TCP 스트림은 어느 정도 신경써서 전달합니다.
이러한 배경에서 적은 수의 다양한 전송 방식(필요한 만큼이지만 그 이상은 아닌)이 어느 경우든 합리적으로 보입니다. 어떤 것이 주요 전송 방식이 되어야 하는지는 성능에 달려 있습니다. UDP로 회선의 전체 용량을 사용하려고 했을 때 제 회선에서 심각한 문제를 겪었습니다. 35% 수준의 패킷 손실이 발생했습니다.
UDP와 TCP 우선순위를 조정해보는 것은 분명히 시도해볼 수 있지만, 이에 대해서는 신중함을 당부하고 싶습니다. 한 번에 너무 급진적으로 변경하지 않기를 권하는데, 그렇지 않으면 시스템이 망가질 수 있습니다.
zzz의 답변 (foofighter에게)
새로운 Syndie에 게시됨, 2007-03-27
내가 아는 한, TCP 대 UDP의 선호도에 대한 깊은 이론은 많지 않았으며, 다음 고려사항들을 제외하고는:
이 모든 것들은 유효한 문제입니다. 하지만 당신은 특정 상위 레벨 프로토콜(즉, streaming lib 사용 여부)에 가장 적합한 전송 프로토콜이 무엇인지 생각하지 않고, 두 프로토콜을 분리해서만 고려하고 있습니다.
제가 말하는 것은 스트리밍 라이브러리를 고려해야 한다는 것입니다.
따라서 모든 사용자의 기본 설정을 변경하거나 스트리밍 라이브러리 트래픽을 다르게 처리해야 합니다.
그것이 바로 제 제안 1B)에서 말하는 내용입니다 - streaming-lib 트래픽과 non streaming-lib 트래픽(예: tunnel 구축 메시지)에 대해 서로 다른 우선순위를 두는 것입니다.
이러한 배경에서, 적은 수의 다양한 전송 방식들(필요한 만큼이되 그보다 많지는 않은)이 어느 경우든 합리적으로 보입니다. 어떤 것이 주요 전송 방식이 되어야 하는지는 성능에 달려 있습니다. UDP로 전체 용량을 사용하려고 했을 때 제 회선에서 심각한 문제들을 봤습니다. 35% 수준의 패킷 손실이 있었습니다.
동의합니다. 새로운 .28 버전이 UDP를 통한 패킷 손실을 개선했을 수도 있고, 아닐 수도 있습니다.
한 가지 중요한 점은 - transport 코드는 transport의 실패를 기억한다는 것입니다. 따라서 UDP가 선호되는 transport라면 먼저 시도하지만, 특정 목적지에 대해 실패하면 해당 목적지에 대한 다음 시도에서는 UDP를 다시 시도하는 대신 NTCP2를 시도할 것입니다.
UDP 대 TCP 우선순위를 조정해 볼 수는 있지만, 신중하게 접근할 것을 강력히 권합니다. 한 번에 너무 급진적으로 변경하지 말 것을 권하는데, 그렇게 하면 문제가 발생할 수 있습니다.
우리는 네 개의 조정 노브를 가지고 있습니다 - 네 개의 입찰 값들(SSU와 NTCP, 이미 연결된 것과 아직 연결되지 않은 것). 예를 들어, 둘 다 연결된 경우에만 SSU가 NTCP보다 선호되도록 하되, 어느 transport도 연결되지 않은 경우에는 NTCP를 먼저 시도하도록 할 수 있습니다.
점진적으로 수행하는 다른 방법은 스트리밍 lib 트래픽만 이동하는 것입니다(1B 제안). 하지만 이는 어려울 수 있고 익명성에 영향을 미칠 수 있습니다. 확실하지 않습니다. 또는 첫 번째 아웃바운드 hop에서만 트래픽을 이동하는 방법도 있습니다(즉, 다음 router로 플래그를 전파하지 않음). 이는 부분적인 이점만 제공하지만 더 익명성이 보장되고 더 쉬울 수 있습니다.
토론 결과
… 그리고 같은 시기(2007년)의 기타 관련 변경사항들:
- 아웃바운드 성능을 크게 향상시키는 스트리밍 라이브러리 매개변수의 중요한 튜닝이 0.6.1.28에서 구현되었습니다
- NTCP용 우선순위 전송이 0.6.1.28에서 구현되었습니다
- SSU용 우선순위 전송이 zzz에 의해 구현되었지만 체크인되지 않았습니다
- 고급 전송 비드 제어 i2np.udp.preferred가 0.6.1.29에서 구현되었습니다
- NTCP용 푸시백이 0.6.1.30에서 구현되었고, 익명성 우려로 인해 0.6.1.31에서 비활성화되었으며, 해당 우려사항을 해결하기 위한 개선사항과 함께 0.6.1.32에서 재활성화되었습니다
- zzz의 제안 1-5 중 어느 것도 구현되지 않았습니다