[e2e] [SPAM] opening multiple TCP connections getting popular
rbriscoe at jungle.bt.co.uk
Thu Aug 30 07:27:52 PDT 2007
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 ->
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.
At 19:54 29/08/2007, Jon Crowcroft wrote:
>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
>- so i have lots of TCP connections mostly from one site to another site,
>to possibly slightly different machnes (although often all via the ssh
>via th e same end point)
>the point is that, like topological DDoS attacks, the crucial point is
>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
>or few TCP conenctions as I choose over my (I bought it) dsl line, and I
>access ISPs right to choke the line if they have a problem - it is way
>IP or TCP level and is to do with traffic engineering in general how thee
>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: you are suffering from what I might call the TCP-delusion, (with
>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
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