Re: [e2e] opening multiple TCP connections getting popular

From: Bob Briscoe <rbriscoe(at)jungle.bt.co.uk>
Date: Mon Sep 03 2007 - 08:07:53 EDT

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@bt.com> Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 Received on Mon Sep 3 08:18:55 2007