[e2e] interaction between TCP and rate limiting in routers

[Saverio Mascolo]

Thanks Shiv. I guess Shiv  is referring to recent work on TCP Westwood.

TCP Westwood proposes an e2e estimation of the bandwdith available to a TCP
connection in order to adaptively set congestion window and slow start
threshold after a congestion episode. In this way window shrinking is no
more a "blind" by half window reduction as it is in the Additive Increase
Multiplicative Decrease paradigm but it is an adaptive decrease that takes
into account the estimated available bandwdith.

A list of recent papers can be found at
http://www-ictserv.poliba.it/mascolo/recent_papers/recent_papers.htm.

In particular the paper
"TCP Westwood and Easy RED to Improve Fairness in High-Speed Networks",
Seventh International Workshop on Protocols For High-Speed Networks
(PfHSN'2002), April 22 - 24, 2002 Berlin, Germany

shows that the steady state throughput of westwood is very close to the
available bandwidth,



that is, edge routers could enforce an "available bandwidth" to TCP westwood
senders.

Saverio Mascolo
-----------
Saverio Mascolo, Ph.D
Associate Professor
Dipartimento di Elettrotecnica ed Elettronica, Politecnico di Bari



----- Original Message -----
From: "Shivkumar Kalyanaraman" <shivkuma at ecse.rpi.edu>
To: "Antonio Jose Elizondo" <ajea at tid.es>
Cc: <JFellows at coppermountain.com>; <end2end-interest at postel.org>
Sent: Tuesday, April 02, 2002 6:18 PM
Subject: Re: [e2e] interaction between TCP and rate limiting in routers


> severio mascolo has been looking at this issue recently.
>
> -Shiv
> ===
> Shivkumar Kalyanaraman
> Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
>
>
> On Tue, 2 Apr 2002, Antonio Jose Elizondo wrote:
>
> > Sorry, but I read, in the original question of Jonathan, "non-invasive
(not involving
> > on-the-fly modification of TCP headers) implementations of rate
limiters" , and I think
> > that TCP Rate control is "invasive".
> >
> > Best regards,
> >             Antonio J. Elizondo
> >
> > Shivkumar Kalyanaraman wrote:
> >
> > > Check out packeteer.com which has been doing this since 1995.
> > >
> > > We wrote a paper with them in 2000 (TCP Rate control). See:
> > > http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-2000.html
> > > or
> > >
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#tcp
> > > and references therein.
> > >
> > > best
> > > -Shiv
> > > ===
> > > Shivkumar Kalyanaraman
> > > Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute
(RPI)
> > >
> > > On Tue, 2 Apr 2002, Antonio Jose Elizondo wrote:
> > >
> > > > Hi, I am also a lurker on this list, and also read it from time to
(much) time.
> > > >
> > > > I presented a paper on "Capped Leaky Buckets" in ITC17 (2001). The
goal of this
> > > > bucket consists of providing a configured rate to each TCP flow.
> > > >
> > > > I've looked for the ITC17 proceedings in the web, but it seems that
they are not
> > > > published. However, you can find a previous work in the web, where
capped leaky
> > > > buckets are introduced:
> > > >
http://www.eurescom.de/~pub-deliverables/p1000-series/p1006/TI_5/P1006TI5_me
rged.pdf
> > > >
> > > > If anybody wants the most recent paper, the ITC17 version, please
let me know.
> > > >
> > > > Regards,
> > > >            Antonio J. Elizondo
> > > >
> > > > JFellows at coppermountain.com wrote:
> > > >
> > > > > I'm a long time lurker on this list, but would like to now raise
an issue
> > > > > that I suspect is old hat to many of the members of this list.
> > > > >
> > > > > I'm searching for the current best practice for implementing per
flow or per
> > > > > subscriber rate limits in edge routers.  This is becoming a common
request
> > > > > from consumer oriented ISPs in both the cable and DSL markets.
I've done
> > > > > the Google search and read a half dozen papers that touch on this
subject.
> > > > > Many of the published papers refer to the classic 'sawtooth'
behaviour of
> > > > > TCP in this configuration.   Some suggest that, in order to avoid
multiple
> > > > > consecutive discards, the token bucket that implements the rate
limiter
> > > > > should have a depth at least equal to the RTT*configured rate.
> > > > >
> > > > > Are there any non-invasive (not involving on-the-fly modification
of TCP
> > > > > headers) implementations of rate limiters that allow TCP to run
fairly
> > > > > smoothly at the configured rate?
> > > > >
> > > > > Jonathan
> > > >
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 751 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20020402/daad3098/attachment.gif