[e2e] interaction between TCP and rate limiting in routers

[Jon Crowcroft]

unless you figorue out what to do about shadow pricing for routes,
this is on a hiding to nowhere...

In message <Pine.GSO.4.40.0204021029330.13842-100000 at shiv.ecse.rpi.edu>, Shivkumar Kalyanaraman type
d:

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

 cheers

   jon