[e2e] opening multiple TCP connections getting popular
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 :)
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
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
>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,
>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