[e2e] opening multiple TCP connections getting popular

[Joe Touch]

Lachlan Andrew wrote:
> Greetings Joe,
> 
> On 30/08/2007, Joe Touch <touch at 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.
> 
> True, the charging is network layer, but letting the application know
> how much it is being charged so that it can change its rate is
> transport layer, isn't it?

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.
> 
> Agreed.  The question is whether the IETF should be working to address
> those issues, or ignoring them.

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.
> 
> Can't the same be said for enforcing flow-rate fairness? 

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.

Joe

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070830/6d42d897/signature.bin