Re: [e2e] opening multiple TCP connections getting popular

From: Bob Briscoe <rbriscoe(at)jungle.bt.co.uk>
Date: Thu Aug 30 2007 - 11:28:52 EDT

Joe,

At 06:07 30/08/2007, Joe Touch wrote:
>Bob,
>
>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
> products

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.

Cheers

Bob

>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 Thu Aug 30 13:11:06 2007