[e2e] opening multiple TCP connections getting popular

[Joe Touch]

Bob,

Bob Briscoe wrote:
> 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.

I didn't miss it; it doesn't address the issue that this sort of
fairness is defined by a policy that we don't currently have.

> 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].

IMO, the missing piece is above the transport layer, not below.

> 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!

Pick an acronym suitable for the mechanism you propose. ;-)

>> 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).

So can RFC2140. The missing piece is "what is fair":

	one 'chunk' (flow, cost, unit - again, the term isn't	
	as relevant as the concept) per:

		- user (what's a user?)
		- process
		- transport connection
		- endpoint IP address
		- HIP ID
		- IPsec SA

Until we decide how aggregate accounting happens, the rest is moot. The
fundamental problem with opening multiple TCP flows to 'cheat' is that
there are different groups with different views on that aggregation.

Given whatever aggregation you find comfortable, there are different
versions of fair:

	- yours
	- TCP-friendly

Now, admittedly, TCP-friendly doesn't jib with what some would call
fair, especially because, other things being equal:
	- smaller RTT gets a bigger slice
	- lower loss gets a bigger slice
	- obeying TCP's rules for friendliness

The useful point about TCP-friendly is that it's currently sufficient
largely (IMO) because users can't do anything to make the first two of
those parameters smaller; they can only increase them, and that is
self-penalizing.

The last parameter is the devil, but it's somewhat a defining
characteristic of any mechanism that lacks enforcement, somewhat of a
Nash-ism: everyone plays by the rules, and the rules work for everyone.

>> 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.

I agree! You want to define a more 'fair' concept of 'fair' among
parties, but the problem in this thread is more with defining a 'party'
(IP flow, endpoint, HIP ID, etc.) than with what's fair once you do that.

>> 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.

Right! And it's the lack of that policy that is the key to *this* thread.

>> 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.

s/FRF/Bob's mechanism/ -- I think we agree here.

>> 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.

Probably.

>> However, those last two points have nothing to do with this thread,
>> again, AFAICT.

Let's not please lose this last point, however.

-- 
----------------------------------------------------------------------
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/20070903/e976b624/signature.bin