[e2e] link between Kelly's control and TCP's AIMD
Cannara
cannara at attglobal.net
Sun Feb 20 15:37:10 PST 2005
Right Jon. In one hot area of the network systems industry now, we see huge
corporate interest in taming p2P traffic (Kazaaa, BitTorrent, eDonkey...) and
IM file xfers -- not only due to traffic loading at edge interfaces, but due
to copyright-suit fears and intellectual property loss (the other IP). This
too is a direct result of the historically poor grasp of what's important in a
truly global Internet, much as earlier issues with DOS, etc.
So, the upshot is lots of $ being and to be spent on systems that analyze,
report and even intervene on such flows. Most of this $ will go to companies
and investors in them, but come from all of us, just as the historical subsidy
for the Internet paths, protocols, conventions and other yadda yadda that's
left us in the current state of mediocrity came mostly from taxpayers. What
other publicly funded system has turned out to have its dominant daily service
volumes in scams, spam, pornography and whatever else low lifes can think of?
The Internet is its own denial of service system. The issue isn't free
access, it's misappropriation -- the little secret ISPs haven't really wanted
to expose -- and, the culprit? The same Internet bureacracy that cloyingly
plotted graphs of doubling (or more) of variables X, Y... every year, but
failed to grasp old networking truths and act on them with speed & common
sense.
Here's a test for any new CS grad student: Name 4 reasons the Internet is
poorly designed. You have 4 minutes. :]
Alex
Jon Crowcroft wrote:
>
> dont want to argue about the non-linearity stuff - seems reasonable -
>
> but about cults and so on - i thin you hit the nail on the head (and in the research community
> we've bemoaned the zillion small-delta on tcp papers - last time i looked there were on the order of
> 3000 references on nano-deltas to TCP and acive queue management...)
>
> but i think its a bit unfair on the people that did try and think bigger:
> the same people fixed tcp had a very good go at various designs for
> fixing the ip layer if you check the history - not only are many of the same
> technical people associated with the better ideas in resorce reservation
> and fair queueing, but they also looked at getting out of the mess of IP over ATM,
> and tried very hard to think about _scaling_ of new network techniques for efficiency
> and fairness (e.g. core stateless fair queueing, and diffserv stuff that is actually
> in use in quite a few VOIP deployments (the ones that aren;t just freeriding on overprovisioning)
>
> the actual reasons that ip survived are non technical - they are "cant get here from there, however much you'd like
> to" - e.g. installed base, deployment, cost, inertia, intractable software and hardware development problems
> (e.g. certain router vendors in very deep potential wells:), etc etc etc
>
> hwever, this has not all been bad:
> see
> Models for a self-managed Internet
> F. P. Kelly
> http://www.statslab.cam.ac.uk/~frank/smi.html
> Paper presented at:
> Network Modelling in the 21st Century,
> Royal Society Discussion Meeting,
> London, December 1999, and published in:
> Philosophical Transactions of the Royal Society A358 (2000) 2335-2348.
> for some reasons why...
>
> and now we are still in core bandwidth glut world, but the core technology and access nets may all shift in how
> they work (lots of photonics in core and lots wireless at edge) we may need something that isnt like anyones vision
> in the last 30 years either side of the e2e v. hbh debates...
>
> I really do think there's a brick wall we are about to hit - there's huge pent up demand in end systems with
> nothing stopping them overloading the net except the limit on access link speed today - if you add up the 6M
> broadband links in the UK and take worst case assumptions, then the core ISPs and exchange point capacity is over
> by factors of roughly 5....if someone deployed fiber to the home at the rate they deployed cable tv coax, and then
> deployed just 100Mbps ether access over that, the core nets would be underprovisioned by about 2 orders of
> magnitude potentially in about 2 years; and no obvious upgrade path in pure technology , so paying attention
> to the architecture about now is probably quite a good idea
>
> the alternatives are ok in terms of all our jobs, but we will be fixing lots of stupid problems rather than off
> developing cool new stuff:)
>
> In missive <42179DB4.7090505 at attglobal.net>, Alex Cannara typed:
>
> >>Lordy, Lordy, since when is a threshold or timeout linear? If I drop 1% of a
> >>true fluid flow randomly, do I get 30% less out the other end of the pipe?
> >>One key to TCP's nonlinearity is its naive attempt to protect the network
> >>layer from congestion. The folks in the '80s who trembled with anger at
> >>Metcalfe's prediction of Internet collapse lived through some bad, near-miss
> >>scares, but instead of fixing IP and the network-layer systems, chose to make
> >>the transport layer the guardian of the net. This has always been a band aid,
> >>or kludge, depending on your upbringing, but it led to complacency and even
> >>religious fervor about "TCP", with cults even espousing foolery like "TCP
> >>Friendliness" and forclosing good ideas on doing a real fix for over a decade.
> >> Of course the Internet bureaucracy did deal with idiotic IPv4 addressing,
> >>over as many years, and did so well we have IPv6 (or we hope we never will
> >>have it)!
> >>
> >>{:o]
> >>
> >>Alex
> >>
> >>Saverio Mascolo wrote:
> >>> well this is not a technical answer! If you build a system made of linear
> >>> subsystems (i.e. gains, delays and integrators) how can you get a nonlinear
> >>> system?
> >>>
> >>> Saverio
> >>>
> >>>
> >>>>Well, only 15 years of modest network consulting for over 1000 modest
> >>>>companies from GM on down. :]
> >>>>
> >>>>Have VJ estimate how much delay is incurred by any current TCP under 1%
> >>>
> >>> random
> >>>
> >>>>packet loss; then 0.1%. Or, have him or anyone else, itemize the
> >>>
> >>> differences
> >>>
> >>>>among TCPs deployed by, say, the top 10 systems vendors.
> >>>>
> >>>>There've been many archived discussions of how TCP does & doesn't work as
> >>>
> >>> well
> >>>
> >>>>as it should, given all the years that have passed, in which continued
> >>>>protocol development could have, but did not, occur. Thus the Internet --
> >>>
> >>> a
> >>>
> >>>>study in insecurity, capacity co-option, performance mediocrity,
> >>>
> >>> engineering
> >>>
> >>>>bureaucracy... But, that's not what folks want to hear. Which is why the
> >>>>mediocrity continues and those of us in consulting & security have good
> >>>
> >>> jobs &
> >>>
> >>>>good profits. :]
> >>>>
> >>>>Alex
> >>>>
> >>>>Saverio Mascolo wrote:
> >>>>
> >>>>>why do you think TCP congestion control is not linear? I tend to agree
> >>>
> >>> with
> >>>
> >>>>>Van Jacobson when syas that a network is to a large extend a linear
> >>>
> >>> system
> >>>
> >>>>>made of integrators, delays and gains.
> >>>>>
> >>>>>Saverio
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Cannara" <cannara at attglobal.net>
> >>>>>To: <end2end-interest at postel.org>
> >>>>>Sent: Friday, February 18, 2005 6:12 AM
> >>>>>Subject: Re: [e2e] link between Kelly's control and TCP's AIMD
> >>>>>
> >>>>>
> >>>>>>And, without understanding/modelling TCP's nonlinear behaviors, it
> >>>
> >>> will
> >>>
> >>>>>only
> >>>>>
> >>>>>>serve for gross predictions.
> >>>>>>
> >>>>>>Alex
> >>>>>>
> >>>>>>Ted Faber wrote:
> >>>>>>
> >>>>>>>On Thu, Feb 17, 2005 at 01:31:08AM +0000, Damon Wischik wrote:
> >>>>>>>
> >>>>>>>>Roy Xu wrote:
> >>>>>>>>
> >>>>>>>>>I'm looking for a pointer to literatures that link the
> >>>>>>>>>TCP's (discrete) AIMD to Kelly's (continuous) control
> >>>
> >>> formulation.
> >>>
> >>>>>>>>Kelly's continuous-time formulation uses a differential equation
> >>>
> >>> model
> >>>
> >>>>>>>>(also called a fluid model) for TCP. You should look at the
> >>>
> >>> literature
> >>>
> >>>>>>>>which describes this fluid model, starting with
> >>>>>>>>
> >>>>>>>>"A Fluid-based Analysis of a Network of AQM Routers Supporting TCP
> >>>>>
> >>>>>Flows
> >>>>>
> >>>>>>>>with an Application to RED", V. Misra, W. Gong, D. Towsley,
> >>>
> >>> SIGCOMM
> >>>
> >>>>>2000.
> >>>>>
> >>>>>>>Fluid flow congestion control analysis goes beck to these guys at
> >>>
> >>> least:
> >>>
> >>>>>>>%A D. Mitra
> >>>>>>>%A T. Seery
> >>>>>>>%T Dynamic Adaptive Windows for High Speed Data Networks: Theory and
> >>>>>>>%Simulation
> >>>>>>>%J Proc. SIGCOMM Symposium on Communications Architectures and
> >>>
> >>> Protocols
> >>>
> >>>>>>>%P 30-29
> >>>>>>>%I ACM SIGCOMM
> >>>>>>>%C Philadelphia, PA
> >>>>>>>%D Sept 24-27, 1990
> >>>>>>>
> >>
>
> cheers
>
> jon
More information about the end2end-interest
mailing list