[e2e] [SPAM] opening multiple TCP connections getting popular

[Bob Briscoe]

Jon,

I think you've jumped to the conclusion I'm saying mulitple TCPs is a 
problem. I'm not saying that at all - I positively encourage it (in my 
paper cited in my posting I positively ref your paper on MulTCP) because w 
TCPs still respond to congestion... But I would only encourage it IFF 
there's some accountability framework to prevent everyone setting w -> 
infinity.

The posting was criticising those (ie those suffering from the TCP 
delusion) who say we don't need accountability for the volume of congestion 
different people cause, because they say TCP shares out capacity fairly.

more inline...

At 19:54 29/08/2007, Jon Crowcroft wrote:
>I agree
>
>I dont really see the new problem, or any problem at all -
>
>every day I have an SSH session, a remote file system mounted and two 
>different browsers
>- so i have lots of TCP connections mostly from one site to another site, 
>albeit
>to possibly slightly different machnes (although often all via the ssh 
>tunnel, so
>via th e same end point)
>
>the point is that, like topological DDoS attacks, the crucial point is 
>what share
>ot the bottleneck piint in the net I get - since in my caser the 
>bottleneck is a
>20Mbps DSL line I pay for, i see it is fair, and agnostic of me t, to run 
>as many
>or few TCP conenctions as I choose over my (I bought it) dsl line, and I 
>see the
>access ISPs right to choke the line if they have a problem - it is way 
>below the
>IP or TCP level and is to do with traffic engineering in general how thee 
>trade
>off between my use of capacity and the service provider's offering of capacity
>are matched - tcp is not about resource allocation, it is about congestion
>control which is about avoiding probklems when they arise, not about normal
>operational cake-slicing imho.

1/ This isn't just an issue between a user and her local ISP. Shifting the 
focus from your personal DSL use (which is probably to an over-provisioned 
academic campus at the other end), a typical filesharing user is just as 
likely to be hitting a bottleneck in another ISP's backhaul (or bottlenecks 
in both local and remote backhauls).

Even if her bottleneck is remote, I'd still like her to be able to behave 
like w TCPs, but we need a simple accountability framework that allows her 
own ISP to choke her if she causes excessive congestion, whether the 
bottleneck is local or remote (which, as you know, is what I've proposed).

I think we're agreeing (modulo the misunderstanding about what I was saying 
the problem was).

2/ If everyone was trying to fill their access link with TCPs (or MulTCP) 
continuously, the bottlenecks would nearly always NOT be their own lines, 
no matter how carefully they spread out the traffic. This is in fact close 
to the current situation - even without everyone participating in p2p 
filesharing, bottlenecks have already moved out of the lines into the backhaul.

So I'd question your assertion that the norm is that you can do what you 
want within your line limit, and the exception is the ISP should be able to 
throttle you. Contention is the norm (which I'm sure your contract makes 
clear). So we need a way to do resource allocation. Yes, TCP is not the 
answer to this question. But a simple accountability framework that allows 
users to choose w TCPs AND gives them a reason for not setting w to 
infinity *is* needed.

Are we actually agreed on that too?


Bob


>bob: you are suffering from what I might call the TCP-delusion, (with 
>apologies
>to richard dawkings)
>In missive <46D5B665.6090800 at reed.com>, "David P. Reed" typed:
>
>  >>It's worth pointing out that this is nothing new.   So-called
>  >>download-accelerators that do exactly that have been around for at least
>  >>5 years now, and are extensively used  on Windows platforms, because
>  >>they work as advertised.   I think the one I used to use on Windows was
>  >>called "Lightning Download" and it was freeware.
>  >>
>  >>But a deeper question is this: if I want a movie each day, and my daily
>  >>average rate of consumption is not going to change because I can't watch
>  >>movies faster than my eyeballs work, why is this going to be a big
>  >>problem?   Is there any evidence of people downloading movies that they
>  >>don't watch?
>  >>
>  >>The mitzvah gained from shorter latencies allows other people to
>  >>download at their convenience with out me competing with them.
>  >>
>  >>In fact, isn't dragging one's download out just maximizing all the users
>  >>wait time?
>  >>
>  >>Maybe the sky isn't falling?
>  >>
>  >>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 -
>  >>> essentially using the well-known broken feature of TCP (see the I-D
>  >>> below) to enable one user to compete more aggressively for the same
>  >>> bandwidth against other users. But it flies below the limit of 10
>  >>> concurrent half open connections added to Windows XP SP2 - claimed to
>  >>> be added to slow down worms but also limiting p2p filesharing clients.
>  >>>
>  >>> Amazingly, these guys are approaching ISPs to re-sell this product -
>  >>> so their customers will just be competing more aggressively with each
>  >>> other and largely end up back where they started. It's worth reading
>  >>> the Business Week article linked off the above page to see just how
>  >>> convincingly this is being marketed - They fooled the technology
>  >>> assessment people in at least one large ISP (mentioning no names).
>  >>>
>  >>> 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?
>  >>>
>  >>> To quote the Internet Draft "Flow Rate Fairness: Dismantling a Religion"
>  >>> <http://www.ietf.org/internet-drafts/draft-briscoe-tsvarea-fair-02.pdf>
>  >>> "...flow rate fairness isn't even capable of reasoning about questions
>  >>> like, "How many flows is it fair to start between two endpoints? ...
>  >>> ...there will certainly be no solution until the networking community
>  >>> gets its head out of the sand and understands how unrealistic its view
>  >>> is; and how important this issue is--a conflict between the vested
>  >>> interests of real businesses and real people."
>  >>>
>  >>> King Cnut commanded the tide not to wash over him sitting on his
>  >>> throne on the English beach, but at least when the experiment failed
>  >>> he humbly accepted he was subject to greater powers, never wearing his
>  >>> crown again. I'm worrying away at the IETF to work on a proper
>  >>> solution to the TCP-fairness problem, rather than merely issuing the
>  >>> decree that RFC2616 HTTP/1.1 clients should observe a 2 connection
>  >>> limit to each server.
>  >>>
>  >>>
>  >>> Bob
>  >>>
>  >>>
>  >>> 
> ____________________________________________________________________________
>  >>>
>  >>> 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
>  >>>
>  >>>
>
>  cheers
>
>    jon

____________________________________________________________________________
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