[e2e] opening multiple TCP connections getting popular

[Joe Touch]

Bob (et al),

There are completely separate things at play here:

- a mechanism to gate traffic into the net
	transport, app, or otherwise

- a mechanism to penalize use that causes congestion
	that needs to go proportionally back to the source

Whether to use TCP or something else for the former, the two are
separate. Gating functions are "per-something" fair, and you need to
flow that tag all the way down from its source (e.g., the user, the
process, etc.). Once you have that, it's the gating mechanism isn't
important.

I.e., AFAICT, to make "flow rate fairness" work, you need something
outside the transport layer to determine how to group things that are
penalized as a group. If you do that, you don't need FRF's new transport
mechanism necessarily.

...
>> 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
> 
> "We need to do something" is a rather dismissive characterisation of a
> fully spec'd protocol proposal:
> <http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-04.txt>

"we need to do something" isn't a sufficient motivation. It's irrelevant
what the "something" you need to do is; the deficit is in the motivation.

> I can't win either way. When I put re-ECN to the IETF, everyone didn't
> understand why it was needed. Now I've explained why it's needed, people
> complain the IETF doesn't get involved in economics and policy. I'm not
> asking the IETF to get involved in economics and policy, I'm asking for
> a bit in a header. The wider industry does the policy. But the IETF
> needs to state the requirements it understands it is trying to meet.

The point appears to be that the bit in the header is the least of the
issues; without the broader mechanisms at the policy level that flow up
to the app/user, the bit isn't sufficient. With that broader mechanism,
the bit may not be necessary.

>> (and, as others have noted, it's not
>> clear we _need_ to do anything).
> 
> Tell that to the CEO of any network operator. I think you're saying
> there's not an engineering problem. But that's because resource
> allocation problems are economic problems not engineering problems...

No - I'm saying it isn't a problem. Whether it's economic or otherwise,
as others have noted, not being 'fair' depends on an agreed concept of
fairness. We have one now - per-TCP connection, relative to RTT. That's
not perfect, but it is a definition, and it does work.

On a final note:

> Consider this: folks at the IETF can expend weeks on whether a certain
> sentence about the minutiae of a certain protocol field will be a MUST
> or a SHOULD. But apparently we don't need to spend any time at all on
> fixing the whole of resource allocation and accountability.

IMO, a specific proposal at the transport layer doesn't solve the whole
of resource allocation and accountability either. The transport layer
isn't the crux of that problem - it's all the other layers for which we
don't agree how to proceed yet.

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/20070831/f7df3fba/signature.bin