[e2e] interaction between TCP and rate limiting in routers

[Shivkumar Kalyanaraman]

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_merged.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
> > >
>