[e2e] Do we have buffer bloat on edge routers or on core routers?

[Alexandre Grojsgold]

On 28-03-2013 17:31, Daniel Havey wrote:
> Having just finished my proposal and regained the ability to think about stuff, I'm going to agree with Oliver.
>
> I have no studies and I have no evidence.  However, I have a nice analysis ;^)  The ISP's edge router has a rate limiter because they want to sell us bandwidth.  However, they also don't want to drop those packets because they already did all the work of getting them to the edge router.
>
> This is a very likely place for bloat.

I don't know ... if the "excessive" packets are part of a long living  
flow (large file xfer, voice conference, etc...) the ISP would rather 
drop a few packets early, and doing so signal the source that it must 
packet rate, than allow a big buffer to grow and mess up all flows.

>
> Hmmmm, actually I do have a study:
> End-to-end Detection of ISP Traffic Shaping using Active and Passive Methods, Partha Kanuparthy and Constantine Dovrolis
>
> This is a large study with lots and lots of users all over the place.  Check the paper for details, but, it indicates that token buckets are prevalent.  If this is true, it is easy to imagine that the ISP's are configuring the queues on their edge routers so that they don't drop packets easily.
>
> ...Daniel
>
> --- On Thu, 3/28/13, Oliver Hohlfeld <oliver at net.t-labs.tu-berlin.de> wrote:
>
>> From: Oliver Hohlfeld <oliver at net.t-labs.tu-berlin.de>
>> Subject: Re: [e2e] Do we have buffer bloat on edge routers or on core routers?
>> To: end2end-interest at postel.org
>> Date: Thursday, March 28, 2013, 11:38 AM
>> Hi,
>>
>>> Perhaps my question is a stupid one, however, can
>> someone help me here?
>>
>> While there is a lack of evidence, I tend to believe the
>> answer
>> is no for most networks.
>>
>> Let me briefly elaborate on this issue. It is hard to
>> provide a
>> definite answer due to the multitude of possible devices
>> and
>> configurations. I tried conducting a survey of typical
>> hardware
>> combinations and talk to more operators, but had to give up
>> at some
>> point.
>>
>> Signs of buffer bloat:
>> - I remember having read reports of queuing delays of up to
>>    one second in the Level 3 network. Unfortunately, I
>> can't
>>    find the reference any more.
>>
>> Contra buffer bloat:
>> - By working with a tier-1 network, I never found evidence
>> for potential
>>    buffer bloat in their core and aggregation network
>> (might be
>>    different for other networks). The aggregation
>> network has been put
>>    under load and none of the devices showed excessive
>> queuing. In
>>    fact, queuing delays were minimal.
>>    In the core, the buffers are "reasonably" sized and
>> don't allow for
>>    excessive queuing.
>>
>> - Typical buffer sizes are around 100ms. Juniper "M-Series"
>> routers
>>    are at 200ms.
>>
>> - While it is theoretically possible to have bloated buffers
>> in the
>>    core, affording excessive buffering is getting more
>> expensive /
>>    infeasible with increasing line card speed (e.g.,
>> 100GE).
>>
>> - The switching infrastructure in the aggregation network
>> is
>>    typically not equipped with a lot of buffer space.
>>
>> In conclusion, from what I have seen so far, I believe that
>> buffer
>> bloat is mostly a problem at the edge.
>>
>> Oliver
>>
>


-- 

	Laboratório Nacional de Computação Científica http://www.lncc.br 
<http://www.lncc.br/>
*Alexandre L. Grojsgold*
(24) 2233-6003 / (21) 8011-5593 / (21) 2275-9945 r:15


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130330/e01ad3b6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/jpeg
Size: 3096 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130330/e01ad3b6/graphics1.jpe