Another related option: Use TCP-tunneled-over-UDP for those cases
where "native" TCP fails. There are plenty of UDP tunneling protocols
around to choose from, so the amount of stuff to be invented or
standardized may be relatively small.
On Mar 16, 2009, at 3:36 PM, Salman Abdul Baset wrote:
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
