Henning, I agree. My recollection is that TSV wasn't too fond of this idea the last time it came up at an area meeting, so I wouldn't expect it to happen quickly, but maybe I'm wrong. Would certainly be an easy drop-in if it were available.
Bruce On Mon, Mar 16, 2009 at 5:32 PM, Henning Schulzrinne <[email protected]> wrote: > 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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
