[Bloat] The bigger picture: what components are used together to fight bloat

[Bloat] The bigger picture: what components are used together to fight bloat

[Forums1000]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

I hope I can get a bit more information on what comprises the total
solution. But knitting it together proves a bit hard (for me at least).
Without this, it is hard to follow the discussions on the list. Has anyone
made a summary of how all of this works together?

So:

1. In order to move the bottleneck to a device under our administrative
control, we need to shape traffic (we need to become the bottleneck).
2. Next, we have the AQM-algorithms that manage the (or a) queue.
3. And then there are still issues with multiple flows and with UDP?

From what I understand, we need to shape traffic, and then drop packets
taking into account that the most aggressive flow (the flow that
contributes the most to filling a buffer), is the flow that will get the
most packets dropped. This to prevent the aggressive flow from impacting
flows that behave better.

Now for UDP, is the problem here that we cannot identify flows, and hence,
only have one queue for UDP whereas for TCP we can have multiple?

Any good resources are more than welcome:-)!

Thanks,
Jeroen

[-- Attachment #2: Type: text/html, Size: 1203 bytes --]

Re: [Bloat] The bigger picture: what components are used together to fight bloat

[Kevin Gross]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Not quite UDP, but RTP congestion avoidance is being worked on in the IETF.
Please join us - http://datatracker.ietf.org/wg/rmcat/charter/

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Thu, May 2, 2013 at 5:44 AM, Forums1000 <forums1000@gmail.com> wrote:

> I hope I can get a bit more information on what comprises the total
> solution. But knitting it together proves a bit hard (for me at least).
> Without this, it is hard to follow the discussions on the list. Has anyone
> made a summary of how all of this works together?
>
> So:
>
> 1. In order to move the bottleneck to a device under our administrative
> control, we need to shape traffic (we need to become the bottleneck).
> 2. Next, we have the AQM-algorithms that manage the (or a) queue.
> 3. And then there are still issues with multiple flows and with UDP?
>
> From what I understand, we need to shape traffic, and then drop packets
> taking into account that the most aggressive flow (the flow that
> contributes the most to filling a buffer), is the flow that will get the
> most packets dropped. This to prevent the aggressive flow from impacting
> flows that behave better.
>
> Now for UDP, is the problem here that we cannot identify flows, and hence,
> only have one queue for UDP whereas for TCP we can have multiple?
>
> Any good resources are more than welcome:-)!
>
> Thanks,
> Jeroen
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

Re: [Bloat] The bigger picture: what components are used together to fight bloat

[Dave Taht]

On Thu, May 2, 2013 at 4:44 AM, Forums1000 <forums1000@gmail.com> wrote:
> I hope I can get a bit more information on what comprises the total
> solution. But knitting it together proves a bit hard (for me at least).
> Without this, it is hard to follow the discussions on the list. Has anyone
> made a summary of how all of this works together?
>
> So:
>
> 1. In order to move the bottleneck to a device under our administrative
> control, we need to shape traffic (we need to become the bottleneck).

Or the algorithms need to be running on the bottleneck device.

> 2. Next, we have the AQM-algorithms that manage the (or a) queue.
> 3. And then there are still issues with multiple flows and with UDP?
>
> From what I understand, we need to shape traffic, and then drop packets
> taking into account that the most aggressive flow (the flow that contributes
> the most to filling a buffer), is the flow that will get the most packets
> dropped. This to prevent the aggressive flow from impacting flows that
> behave better.

There are often many aggressive flows and it doesn't help to just
shoot at one or drop a ton of packets from one, inside of an RTT.

>
> Now for UDP, is the problem here that we cannot identify flows, and hence,
> only have one queue for UDP whereas for TCP we can have multiple?

Not true. Using a 5 tuple for udp works as well as it does for tcp.

> Any good resources are more than welcome:-)!

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

>
> Thanks,
> Jeroen
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html