Re: [e2e] opening multiple TCP connections getting popular

Lachlan Andrew wrote:
> Greetings Joe,
>
> On 30/08/2007, Joe Touch <touch@isi.edu> wrote:

>> Lachlan Andrew wrote:
>>> I thought that Bob's suggestion was simply that the transport/network
>>> layer provide a mechanism for charging based on the congestion caused.
>>>   That sort of mechanism *is* "solvable at the transport layer".
>> If we charge based on congestion caused, that's a network layer issue,
>> not transport.

It's transport layer if you're charging the app based on what the app sends to the transport. Unfortunately, the network can be just as congested by a retransmission as a first try, so this is network pricing. Although the transport and application may _react_ to it, it is generated (and thus the problem exists) at the network layer.

>> First, however, what does that mean?
>>
>> There are many issues there; it's not cut-and-dry.

I've stated before - the IETF isn't the IRTF; some of this is research (i.e., what are the dimensions of the solution). Some of it is also a combination of policy and pricing - neither of which are IETF purvue either.

The IETF is a good place to standardize a technical solution once we know what we're solving. At this point, "we need to do something" is insufficient rationale to proceed (and, as others have noted, it's not clear we _need_ to do anything).

>> A solution inside the transport layer solves only the most
>> trivial variant, and leaves so many loose ends elsewhere it doesn't put
>> a dent in the overall problem.

Excellent point. You'll note that we do nothing to enforce that. The goal is that the network congestion feedback is proportional the number of streams - there's no rule that prevents opening multiple streams (as was noted) or merging them either. The whole thing works mostly because the degenerate case - a stream per packet - is prohibitive.

> If that does
> more than put a dent in the overall problem, then congestion charging
> can make a bigger dent. If flow-rate fairness *doesn't* put more than
> a dent in the overall problem, should we forget about "TCP
> friendliness"?

We don't enforce that either. We encourage that as a general principle, and assume (as above) that so long as the number of TCP streams is roughly proportional to the number of users, things will work fine. They don't work if the number of flows grows with the load; if we get to a point where that actually happens, then maybe we'll need to do somthing.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related postel.org Links end2end-interest Request more information about Pantek

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI


application/pgp-signature attachment: OpenPGP digital signature