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
