Salman, Unfortunately, the conversation is dominated by the need to work in the real Internet, where the dominant situation is that UDP will work and TCP won't.
We do have the advantage that we don't have to match TCP in performance, although the exact requirement will of course vary by the particular deployment. Also, a TCP overlay link will also need to estimate RTO to determine when the link has failed. Bruce On Mon, Mar 16, 2009 at 3:36 PM, Salman Abdul Baset <[email protected]> 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
