I am worried about the situation in which packets traversing peers
that run TCP have to be sent to a peer behind NAT using RELOAD's custom
transport and cc protocol. Some unexpected failures may happen if this
reliable and cc protocol is not properly designed.
In the light of WG discussion, the questions I mentioned before need to be
addressed before a full-blown solution, i.e.,
What are the performance requirements of this protocol?
Where should this protocol be specified?
-s
On Sun, 5 Apr 2009, Bruce Lowekamp wrote:
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
