[e2e] opening multiple TCP connections getting popular

[Bob Briscoe]

Joe,

To take the last point first about relevance to this thread.

You may have missed my second posting (in response to JonC),
<http://www.postel.org/pipermail/end2end-interest/2007-August/006933.html>
clarifying that any assumption that multiple TCP connections are 
bad/unfair/cheating was in the reader's head, not in my posting (and hey, I 
started this thread!). This thread is about how it would be OK to open 
multiple connections (or window scaling) if there were accountability for 
the congestion caused.
Or as I put it at the start, "Why shouldn't app-layer people expect the 
transport layer to correctly handle fairness?" [fairness would actually be 
done below the transport layer].

Nonetheless, I believe Hitler was bad/unfair/cheating (that may help Ted 
place me on his political spectrum :)

more inline...


At 11:05 01/09/2007, Joe Touch wrote:

>Bob Briscoe wrote:
> > Joe,
> >
> > I composed responses yesterday to each of your points, but I've realised
> > there's no purpose in sending them until the underlying terms of
> > reference are mended...
>
>The underlying issues are, as far as this thread is concerned, IMO:
>
>1) any mechanism that TCP needs to be per-user fair - to defeat multiple
>TCP connections as a cheat - is needed both for TCP and flow-rate fairness.

Yes. Indeed, it's needed irrespective of how a user's bits are carved up 
into flows.

Nit: If you really meant "TCP and flow rate fairness", this might indicate 
we're taking different meanings for FRF. The term "FRF" is surely a general 
term for TCP fairness, generalised to include other attempts to define 
fairness; as approximate equality of the rates of individual competing flows.

 From a couple of other instances later in this thread, I think you've 
mistakenly used the term "flow rate fairness" where you possibly meant 
"cost fairness". But in one case, I think you might have really meant flow 
rate fairness. I need to check whether I need to decode an intermittent 
substitution cipher!


>2) that mechanism doesn't exist, so flow-rate fairness alone isn't
>sufficient

I'm lost. We must be talking at complete cross-purposes here.

But whatever, that mechanism does exist, at least as a proposal (mine).

My proposal (re-ECN) can do both:
- any form of flow-rate fairness (by confining its scope to each flow 
myopically) including TCP-fairness
- and wider fairness across flows (cost fairness).

>3) if that mechanism did exist, THEN we're back to arguing the
>definition of fairness at two levels (at least):
>
>         a) from the user down to the flow/connection within that
>         nonexistent mechanism
>
>         b) among flows/connections
>
>Near as I can tell, FRF addresses ONLY 3b.
>
>IMO, this thread is more about 3a; FRF has absolutely nothing to do with
>that.

Now, I do agree with both these statements.

>IMO, 3a drives more about what people consider 'fair' than anything else.

I think you're saying "what people believe" is what you believe they should 
believe? If that's a correct reading, yes I agree. And that's one of the 
main motivations of my proposal.



>You raised an excellent point that there's nothing about this mechanism
>that we cannot implement, however, 3a requires knowing the policy we
>want to enforce, and we don't know (or at least don't agree upon) that.

re-ECN doesn't take a position on what the policy should be - it allows 
policy to be applied to it. We need a policy control system precisely when 
we don't know what the policy should be.

>Further, we agree that FRF is better than TCP-friendly 'fairness'.

Again, eh? FRF is a superset of TCP-friendly. But I'm glad to see you've 
put 'fairness' in quotes, so we must be agreeing at some level, but there's 
a misunderstanding or a substitution cipher here somewhere too.

>We probably ought to agree to disagree about whether TCP-friendly
>fairness is so utterly broken that it needs to be replaced, and whether
>the impact required to deploy FRF is worth the benefit gained. That's
>the devil in our past arguments, and in most of the negative FRF
>feedback I've seen from the IETF in public.

I think you might be meaning cost fairness, when you say FRF? Otherwise, 
there's a deep level of misunderstanding here.

Cheers


Bob

>However, those last two points have nothing to do with this thread,
>again, AFAICT.
>
>Joe
>
>--
>----------------------------------------------------------------------
>Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
>                Postel Center Director & Research Assoc. Prof., USC/ISI

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196