[e2e] opening multiple TCP connections getting popular

Bob Briscoe rbriscoe at jungle.bt.co.uk
Mon Sep 3 05:07:53 PDT 2007


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

You may have missed my second posting (in response to JonC),
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

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

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.



>However, those last two points have nothing to do with this thread,
>again, AFAICT.
>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  

More information about the end2end-interest mailing list