[e2e] opening multiple TCP connections getting popular
rbriscoe at jungle.bt.co.uk
Thu Aug 30 08:28:52 PDT 2007
At 06:07 30/08/2007, Joe Touch wrote:
>Bob Briscoe wrote:
> > e2e-interest folks,
> > This product is being very aggressively marketed:
> > <http://www.speedbit.com/video%5Faccelerator/>
> > It opens 10 HTTP/TCP connections to accelerate video downloads -
> > Amazingly, these guys are approaching ISPs to re-sell this product
>There have been other companies predicated on similar model - e.g.,
>packeteer. The IETF doesn't do compliance verification, and doesn't
>issue seals of approval.
> > If you're tempted to poke fun at all these people because they clearly
> > don't understand, I actually think we should be chastened ourselves. Why
> > shouldn't app-layer people expect the transport layer to correctly
> > handle fairness?
>The issue isn't how many flows are fair. It's whether users can get
>around such notions by spawning processes, opening multiple sockets, etc.
>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.
This possibly sounds like a misinterpretation of the example I gave in my
(very belated) reply (8 Aug) to your tsvwg email on a similar subject.
I explained that the solution I propose doesn't rely on identifiers at all.
It reveals info about congestion being caused downstream in the headers
passing between any two economic entities (whether user and provider or
network to neighbouring network). That matches the pairwise bilateral
contracts people have.
I only brought up the multi-user OS example in that email because I know
you're particularly interested in virtualisation. And, even then, I wasn't
saying there's a problem doing what I propose in an OS - it's dead easy to
do secure accounting across different users on all multi-user OSs I know of.
>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:
> 1) the IETF doesn't enforce its standards in
No - I have no illusions in that direction.
My beef is that I'm having trouble getting the IETF to accept that it
should do work to produce accountability/fairness protocols in the first
place. I merely pointed to RFC2616 HTTP/1.1 decreeing one shouldn't do
this, to point out that's really all the IETF has got on fairness (if one
looks at TCP in the wider context of being able to open w of them).
> 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.
Well, I've solved it - with a solution straddling the network layer and the
transport layer plus policy control hooks for the app-layer or human-layer
to control it - both provider and user.
>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