[e2e] opening multiple TCP connections getting popular

[Joe Touch]

Hi, Andrew,

Lachlan Andrew wrote:
> Greetings Joe,
> 
> On 31/08/2007, Joe Touch <touch at isi.edu> wrote:
>> '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.
> 
> Per connection, relative to RTT, relative to packet size, relative to
> number of points of congestion.  Is it also "relative to corruption
> rate" or is that not part of the definition?

Yup - sorry, I tried to include everything.

> Yes, it is agreed upon, but I'd venture to suggest that it is mainly
> agreed upon by (a) those few who played a role in developing the
> algorithm which implements it (at low BDP etc), and (b) those trying
> to gain the support of those original designers.

It's implicitly agreed upon because it works well enough in practice.
Even those who developed it didn't sign a compact on it. And some of its
properties were discovered along the way. Those we didn't think worked
we fixed as we went. But there's no consensus that it's working so
horribly bad it needs a major overhaul either.

> Per-flow max-min is much more "agreed upon" in the research community
> as an *objective*, as distinct from the outcome of a particular
> algorithm (which was a very useful emergency bandaid).  I haven't done
> a survey, but I'm confident that if you asked the average user, they
> would be more in favour of max-min fairness than TCP-friendly
> fairness.

max-min fairness still needs to be tied to a user-level policy. How do
you decide what a flow is? If a flow is a socket pair (src/dst addr,
src/dst port), then (and here's been the point):

	flow-fairness doesn't solve "opening multiple TCP connections
	getting popular" [as a cheat]

> You mentioned that the IETF's role isn't to do research.  How about a
> commitment to be *open* to research into a concept of fairness which
> is more systematic and less historically-driven?  The current
> impression that I get from the research community is that the IETF
> will    on principle    block any proposal which implements a "better"
> form of fairness (i.e. one with a theoretical justification and more
> in line with a layman's notion of fairness, such as user-pays).  Bob's
> experience seems to bear that out...

This isn't another "blocking any form of fairness" reply. The problem
with this thread overall is that the new solution is argued as solving
multiple TCP connections as a cheat.

The parts required to make flow-fairness work around that cheat appear
to equally defeat the cheat for TCP -- the part that ties users to flows
and makes sure their behavior is enforced based on network feedback.

The IETF doesn't enjoy overhauling a currently sufficient system with a
new one when it doesn't solve the problem. **the problem discussed in
this thread** hasn't been shown to be solved by flow-fairness.

> What exactly do you mean by a fairness definition "working"?  The
> internet still "works", who knows if that is just because of
> "receiver window fairness"  or  "small P2P user-base fairness", or
> "overprovisioning fairness"  rather than  "per flow fairness"  :)

It works until it breaks. "Breaks" is open to debate, and can be
somewhat subjective. And if any of the above are true, then they work
fine. But note that few of the other items say "throw out everything
else for this solution".

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/864d1aca/signature.bin