I have tried to summarize the solution space for addressing fragmentation,
congestion control and reliability issues when using an unreliable
transport. This includes the proposal by Bruce. I think that the WG needs
to contrast their complexity with the use of a reliable transport (TCP),
and consider whether to specify these mechanisms in a separate document
or the base document.
Fragmentation
-------------
*Hop-by-hop fragmentation, hop-by-hop complete reassembly
*Hop-by-hop fragmentation and end-to-end reassembly
-When RELOAD header exceeds MTU --> do IP fragmentation
-When RELOAD header does not exceed MTU --> do RELOAD fragmentation
Congestion control and hop-by-hop reliability of a message fragment
------------------
*Stop-and-wait
-send a packet and wait for a response before transmitting next packet.
-retransmit lost packets at RTO.
-introduce gap of 10ms btw packet transmissions.
*AIMD-like
-transmit packets as permitted by a congestion window.
-No slow start, fast retransmit, or recovery.
-always in congestion avoidance, at every loss, reduce window by half.
-retransmit at RTO if permitted by congestion window.
*TFRC
-TFRC for congestion control
-retransmission at RTO intervals
-needs careful consideration whether TFRC can be implemented using
existing message parameters.
(The above methods require RTO estimation with some caveats. See Bruce's
email:
http://www.ietf.org/mail-archive/web/p2psip/current/msg04697.html)
*Use TCP
-use TCP if expecting fragmentation, otherwise use UDP
-issue: TCP may not work behind some NATs for setting up
direct connections, however:
--UDP may also be blocked by firewalls--
--and nodes behind restrictive NATs can act as clients.
-salman
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
