Salman, We're not doing TCP over UDP. If you want to do that, then please by all means go do it in TSVWG.
We have the option of simpy saying "use TFRC." That will be good enough performance, and require relatively little specification since TSV has already put a lot of work into it. It's also a bit complicated. A lot more complicated than is really needed for most p2psip implementations/deployments. So the motivation of the other options was to provide simpler options that are going to provide enough performance for many/most deployments. You seem very focused on thinking that they're trying to duplicate TCP. They're not. They are trying to be something that a fairly typical development team can build and get right, and get enough performance for their deployment scenarios to work. They are addressing congestion and reliability just like *every* UDP protocol needs to. If they need TCP-level performance out of UDP, they can implement TFRC. We can debate which features are needed or useful for performance without being too complicated for a long time, but that doesn't change the basic focus of what we're doing. (I think there may need to be a tweak in the receiver algorithm as speced now to let TFRCs reach full performance, but the intention is certainly to make sure TFRC implementations have the information they need.) Bruce On Wed, Apr 1, 2009 at 11:11 PM, Salman Abdul Baset <[email protected]> wrote: > > Assuming TCP-over-UDP is needed, my understanding from the list discussion > and from the meeting is that our options are: > > 1) Design TCP-over-UDP in TSV. RELOAD refers to it. > 2) If that may not be possible, then > a) Design TCP-over-UDP as a seperate draft in P2PSIP WG. RELOAD refers to > it. > b) Define TCP-over-UDP in the base document. A custom protocol that only > RELOAD can use. > > > Now, what should be the performance requirements of TCP-over-UDP as compared > to regular TCP? > > -Clearly, it should not exceed the performance of TCP. > -It should not *only* rely on timeouts to recover losses. Otherwise, the > performance is horrible. > -It should not assume anything about the number of fragments. > > Do you think (1-3) are our only options for a TCP-over-UDP solution or did I > miss something? Do you agree with the performance requirements of a > TCP-over-UDP solution? > > If TCP-over-UDP is the solution, I prefer (1) or (2-a) as they are less > likely to stall progress on the RELOAD base document. > > > Now, the tricky question :) > >> 3rd question: What protocols work in scenarios with peers behind NATs >> trying to establish direct connections. >> >> If you believe this is anything other than TCP when possible, but UDP >> in an awful lot of cases, please direct your effort toward making >> ICE-TCP work in MMUSIC, and refer to discussions in MMUSIC for >> experiences with other solutions. >> >> My reading of the current charter, concepts draft, and state of the >> art for NAT traversal makes me believe that the RELOAD must define a >> UDP-based overlay link protocol. I hope we can discuss solutions to >> this problem. But if there is agreement that the requirements are >> different or need to be changed, let's be explicit in what question >> we're asking and what draft(s) need(s) to be changed. Those aren't >> RELOAD questions. > > I am totally willing to believe what you are saying but I want to arrive at > the conclusion in a more systematic manner. Specifically, I am looking for a > paper or a draft, that will exactly list the problems with the existing > approaches (including Characterizing paper), and conclude that these > approaches don't work or using these approaches is much expensive than a > TCP-over-UDP solution. However, I am not able to find such a paper, or a > draft in the BEHAVE WG. If there was a mailing list discussion, it will be > helpful to have it in a draft form. > > > Regards, > Salman > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
