On Jun 23, 2014, at 6:32 AM, Scheffenegger, Richard wrote:
>
>
> Hi Fred,
>
> thank you for writing this down; one aspect that gets referred to, but not
> made completely explicit in sections 3.2 and 3.3 is the interaction of the
> AQM / Queue signals with the transport control loop.
>
> I
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Active Queue Management and Packet Scheduling
Working Group of the IETF.
Title : IETF Recommendations Regarding Active Queue Management
Authors : Fr
I've just uploaded a new revision that implements (we hope) the text
promised in:
http://www.ietf.org/mail-archive/web/aqm/current/msg00663.html
The complete diff following end of the the WGLC can be seen here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-aqm-recommendation-03&difftype=--html&su
Per the discussion in the telecon today about references for global
synchronization and lock-out, I think some excellent classic ones are:
Global Synchronization:
Zhang & Clark, "Oscillating Behavior of Network Traffic: A Case Study
Simulation", 1990
http://groups.csail.mit.edu/ana/Publications/Z
On Tue, Jun 24, 2014 at 11:27 AM, Wesley Eddy wrote:
> Per the discussion in the telecon today about references for global
> synchronization and lock-out, I think some excellent classic ones are:
>
> Global Synchronization:
>
> Zhang & Clark, "Oscillating Behavior of Network Traffic: A Case Study
Yup, this is what my experiments are showing. I'm not doing head/tail drop,
but, I am dropping/marking at the device before and after the bloated device.
That would be counterclockwise or clockwise of the bloated (slow and
overqueued) device. This is essentially the same thing.
What I am obs
On Jun 24, 2014, at 12:45 PM, Daniel Havey wrote:
> So IMHO it really doesn't matter except in the weird corner case where a a
> running flow has already bloated the queue and then we switch on the AQM.
That actually has me a little worried with the 100 ms delay built into codel.
Imagine, if
So far in my observations (admittedly a very small sample size) it's more of an
annoyance than a problem. We get an unwanted congestion event and lose a
little bandwidth, but, after that the queue is drained and can begin building
up again.
But yeah, I see your concern. There may be scenarios
On Tue, Jun 24, 2014 at 1:01 PM, Fred Baker (fred) wrote:
>
> On Jun 24, 2014, at 12:45 PM, Daniel Havey wrote:
>
>> So IMHO it really doesn't matter except in the weird corner case where a a
>> running flow has already bloated the queue and then we switch on the AQM.
Hmm? In practice, changing
On Jun 24, 2014, at 1:33 PM, Daniel Havey wrote:
> There may be scenarios where the interaction of the interval, the RTT and the
> bandwidth cause this to happen recurringly constantly underflowing the
> bandwidth.
To be honest, the real concern is very long delay paths, and it applies to AQM
On Tue, Jun 24, 2014 at 1:48 PM, Fred Baker (fred) wrote:
>
> On Jun 24, 2014, at 1:33 PM, Daniel Havey wrote:
>
>> There may be scenarios where the interaction of the interval, the RTT and
>> the bandwidth cause this to happen recurringly constantly underflowing the
>> bandwidth.
>
> To be hon
11 matches
Mail list logo
