[e2e] opening multiple TCP connections getting popular

[Joe Touch]

Lachlan Andrew wrote:
> Greetings Joe
> 
> On 29/08/2007, Joe Touch <touch at isi.edu> wrote:
>> The transport layer is per-connection fair. If you want per user or per
>> parent process fair, you need user/process IDs (which isn't what we
>> have). That's not a protocol issue per se; it creeps deeply into the OS.
>>
>> It also begs the question of what fairness is - and whether you'll need
>> biometrics to enforce this all the way to layers 8, 9, 10, 11, etc. in
>> the stack ;-) If you want per-login fairness, or per port group, or per
>> process group, you can enforce this through RFC2140-style aggregation.
>>
>> It seems like you're bothered by two problems:
>>
>>         2) TCP fairness doesn't flow up through the OS to
>>            a unit you prefer (e.g., a user)
>>
>> Neither one is solvable at the transport layer.
> 
> "Fair" doesn't mean "one size fits all" like current transport-layer
> fairness.  To me, it means that users to whom an  incremental
> increase in throughput is more valuable get that incremental increase,
> while others who are harmed less by an incremental decrease get that
> decrease.
> 
> I thought that Bob's suggestion was simply that the transport/network
> layer provide a mechanism for charging based on the congestion caused.
>   That sort of mechanism *is* "solvable at the transport layer".

If we charge based on congestion caused, that's a network layer issue,
not transport. First, however, what does that mean?

- charge for packets that could compete with others?
	that could count bytes (if byte-competing),
	or could count packets (if per-packet competing)

- charge extra for packets that actually compete with others?
	i.e., ones that don't collide are free, but tag
	anything in the queue when something else gets dropped
	as "more expensive"
		when we do the tagging, does it depend on the
		amount of stuff in the queue?
		is it proportional to the number of bytes
		in each packet or the number of packets?

- how do we handle packets that are rerouted to avoid congestion?
	does rerouting incur a penalty even if the new route doesn't
	incur congestion?

There are many issues there; it's not cut-and-dry. Even if we figure
that all out, there's a different issue that this is all back-end. We
need a way to decide WHO gets the fee...

So let's say my app causes a DNS request, then your app uses the cached
copy. Does your app incur a fee because it would have caused packets to
be injected, but didn't only because mine came first? does that mean my
app gets a credit?

Even for a single application, we may know which process to charge, but
how do we know which user to charge? Again, we're back to biometrics...

Overall, the problems here are much harder outside the transport layer
than inside. A solution inside the transport layer solves only the most
trivial variant, and leaves so many loose ends elsewhere it doesn't put
a dent in the overall problem.

Joe

-- 
----------------------------------------------------------------------
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/20070830/93b450a3/signature.bin