On Tue, Oct 21, 2008 at 3:02 PM, Stanislav Shalunov
<shalunov at shlang.com> wrote:
The genesis of TANA was at the P2PI workshop. A lot of people there were concerned about multiple connections used by P2P apps. Some concerns are meritorious, others require mostly just information -- there, apparently, exists a belief that P2P apps are designed to open multiple TCP connections to the same destination to circumvent TCP fairness. (I even have an inkling of how that one could get started.)
People also said that P2P applications filled up all available bandwidth, with no explanation provided as to how these applications exceed the limits programmatically imposed by the ISP.
Before anyone redefines fairness, we need data on the current situation. We need to ensure that redefining fairness isn't simply suppressing a market choice. One ISP is reportedly prioritizing HTTP above most other traffic. If, 15 years ago, someone prioritized Gopher over all other traffic, then probably never would have succeeded it.
Please let's not write this problem statement without data confirming the problem and the size of the fairness bias (which probably does exist on paper, but we have no data as to the extent given these applications at ISP-subscriber speeds and P2P latencies).
Also, I think the name change is useful since there is not inkling that this really is about congestion control. Scavenger Network Congestion Protocols sounds good.
I worry about the idea of moving congestion management and packet handling instructions up a layer in the network stack. Worry is not fatal, but it fogs up an area of clarity. I also worry that the last two attempts to help transit providers understand their customer's packets handling needs haven't really been seriously trialled by ISPs as far as I know.
