[aqm] Policy-oriented AQM Steering (was Re: Status of the GSP AQM?)

[Bless, Roland (TM)]

Hi all,

in our paper "Policy-oriented AQM Steering" that will be published
at Networking 2018 shortly, we used also plain GSP and
CoDel for comparison. Maybe this is convincing enough that GSP is
also worth to be considered as alternative. We especially found
it much easier to implement AQM Steering for GSP since GSP's
implementation is simpler than others.

The basic idea of AQM Steering is to modify the delay target
setpoint of the AQM in order to adapt to the current traffic
situation:
Depending on the traffic the same setpoint value can result either
in unnecessary large delays or under-utilization of the link.
Policy-oriented AQM Steering automatically adapts the target delay
setpoint to the current traffic situation, in order to fulfill a
given quality-of-service policy.
Such a policy consists of a utilization goal and an upper delay bound.
This improves AQM performance with varying traffic situations and makes
the impact of deploying an AQM predictable. A prototypical
implementation of AQM Steering for GSP showed its performance advantages
compared to static AQM variants at speeds of 10 Gbit/s and 1 Gbit/s.

The pre-published version can be accessed here
https://doc.tm.kit.edu/2018-kit-aqm-steering-authors-copy.pdf

Regards,
 Roland

Am 08.01.2018 um 17:17 schrieb Lautenschlaeger, Wolfram (Nokia -
DE/Stuttgart):
> Hi Roland,
> 
> Yes, of course, I am still interested in finishing the GSP draft.
> If you have new results on GSP, we could finally take the long pending 
> "independent opinion" hurdle, thank you.
> If there is still some interest in the tsvwg, we could make a trial. My 
> co-author Andrea Francini of the corresponding GSP paper 
> (http://ieeexplore.ieee.org/document/7483103/)  could contribute as well. 
> 
> Regards
> Wolfram
> 
> 
> -Original Message-
> From: Roland Bless [mailto:roland.bl...@kit.edu] 
> Sent: Thursday, December 14, 2017 10:36 PM
> To: aqm@ietf.org; Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart) 
> 
> Subject: Status of the GSP AQM?
> 
> Hi folks,
> 
> I was wondering what happened to the GSP AQM proposal (draft-lauten-aqm-gsp 
> see (https://tools.ietf.org/html/draft-lauten-aqm-gsp).
> Discussion seems to have ended after IETF 93 and we probably missed the point 
> of discussing WG adoption.
> IMHO this AQM should also be documented as RFC. It performs extremely well in 
> some settings (better than CoDel or PIE) and its implementation complexity is 
> also lower. Wolfram, are you interested in finishing this?
> Should we continue in tsvwg?

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Status of the GSP AQM?

[Bless, Roland (TM)]

Hi Wesley,

Am 14.12.2017 um 22:59 schrieb Wesley Eddy:
> I mentioned GSP as a possible work item, back when we were discussing
> rechartering, but apparently it was not compelling to the group at that
> time.
> 
> When we did the AQM algorithm adoption call ~2014, GSP appeared to be
> basically viable technically, but there wasn't evidence that multiple
> parties were interested in working with it enough to go forward (not
> just working the document, but implementing, simulating, testing,
> analyzing, deploying, etc).   There is a thread in the archives with
> subject "[aqm] adoption call: algorithm drafts".

Thanks for the pointer! At that point in time there was not enough
experience with it.

> I haven't noticed a change in activity around GSP since then, but
> apologize if I'm just ignorant of it!

That's right, maybe Wolfram was busy with other stuff.
Our group, however, worked with it at speeds of 1 Gbit/s
and also 10 Gbit/s and we can confirm that its performance is comparable
to - and w.r.t. loss desynchronization - even better than CoDel or PIE
in many of our tested scenarios. Since it's heading for just an
experimental status, the bar shouldn't be too high to get this finished.

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Questioning each PIE heuristic

[Bless, Roland (TM)]

Hi,

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> I'm not convinced I understand the definitions of "work conserving"
> and "non work conserving" in this context. A "work conserving"
> scheduling algorithm keeps an interface transmitting as long as there
> is data in the queue, while a non-work-conserving algorithm reduces
> the effective rate of the interface by spacing packets out. 

+1 (that's also the definition I use, so I'm lost here too)

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [tcpPrague] L4S status update

[Bless, Roland (TM)]

Hi Ingemar,

my point was that it's probably better to refrain from
building CC-specific behavior into network elements as the
CC algorithms may evolve faster and in more flexible ways
than we can foresee. Thus, it would be good to have a separation
(or coupling) scheme that actually doesn't depend on the
1/sqrt(p) dropping law.

Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S:
> As regards to comments around other new congestion control algorithms
> and that they may need adapted dropping likelihood relation between a
> classic queue and L4S queue. I have not tried out but I suspect that
> BBR may get an unfair treatment, at the same time it is possible that
> other delay based CCs may suffer.

It would be interesting to see what happens if BBR is sorted into
the L4S queue in comparison to what happens if BBR is sorted into
the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)).

> They question however if this is a major problem?, one may as well
> see this as an incentive to switch over to scalable congestion
> controls and L4S ? There is after all no requirement to stick to a
> particular congestion control no matter what. ?

Yes, and that's why I find that built-in coupling law too limiting.

> The question whether or not endpoint dependency should be built into
> the networks is of course  a valid question but given that the state
> of the art congestion controls like Reno and Cubic rely on a
> 1/sqrt(p) function then that is perhaps OK ?. There will for a
> foreseeable time come updated endpoint based congestion control
> algorithms that are optimized  for one thing or the other (I am
> guilty too :-). However if one can distinguish between two classes
> (classic and L4S) where classic belong to the 1/sqrt(p) family then I
> believe that it is possible to solve the problem. If we try find a
> solution where classic = "all sorts of non-scalable non-L4S dependent
> congestion controls" then I believe that we easily end up in big
> problems.

I'm not sure. Maybe we have a class of "queue-filling" CCs and
a class of low-delay targeted CCs.

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Bless, Roland (TM)]

Hi Jana,

Am 29.09.2016 um 18:29 schrieb Jana Iyengar:
> There are two issues in that email:
> 1. The importance of reentering state. This is clearly a matter for
> evaluation, and further evaluation will surely yield more results. We
> cannot and won't be perfect in this draft, but I encourage further
> evaluation and work that can perhaps even lead to a future update to
> this draft. We don't intend to address this point in the draft.

I think that wasn't the issue. The issue was that the text should
actually reflect the importance of reentering dropping state by
giving the explanations from the code snippet also in the text.
It's ok if you then also point out that this needs more experimentation
etc.

> 2. Consistency of drop_next_. We should be consistent, this was an
> oversight. We'll fix the algorithm to be consistent with the text.

Fine!

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Bless, Roland (TM)]

Hi Wes and all,

Am 14.09.2016 um 15:26 schrieb Wesley Eddy:
> Hi, for awhile, the CoDel draft was in working group last call. Some
> comments were received, and the authors made an update some time ago. 
> There hasn't been much follow-up discussion.  I assume this means the
> current draft meets people's expectations?  If not, now is a good time
> to shout, because I'm working on the shepherd write-up so that it can be
> submitted to the IESG soon.

No, still some issues that were raised here:
https://mailarchive.ietf.org/arch/msg/aqm/ENA1VZmcFVXCJWrMIbmey4wAYnw

that are not fixed yet.
I pointed that out at the mic within the AQM session @IETF96.
Andrew said that they need to do the changes and then resubmit.

Regards,
 Roland


___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] working group last call on CoDel drafts

[Bless, Roland (TM)]

Dear all,

we believe that the Codel specification
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ needs at least
one major clarification.

The following lines are present in the draft's pseudo-code, but are not
explained further anywhere in the document text, and moreover differ
from the Linux implementation [*], that the document also suggests as
reference implementation.

   // If min went above target close to when it last went
   // below, assume that the drop rate that controlled the
   // queue on the last cycle is a good starting point to
   // control it now. ('drop_next' will be at most 'interval'
   // later than the time of the last drop so 'now - drop_next'
   // is a good approximation of the time from the last drop
   // until now.)
*count_ = (count_ > 2 && now - drop_next_ < 8*interval_)? count_ - 2 : 1; *

This line makes sure, that when two dropping states are entered within a
short interval from each other, the variable /count/ is not reset (to
zero), but is rather changed somehow. In this document, /count/ is
decreased by two, while in the Linux version, /count/ is set to the
number of packets, that were dropped in the previous dropping state.

Based on the email-thread that was started from these messages ...
 http://www.ietf.org/mail-archive/web/aqm/current/msg00376.html
http://www.ietf.org/mail-archive/web/aqm/current/msg01250.html
http://www.ietf.org/mail-archive/web/aqm/current/msg01455.html

... one can infer, that:
1) the case where /count/ is not reset is not an exception, but rather a
common case (that we can confirm from our measurements),
2) several options for this behavior were described on the mailing list
some time ago,

Since it is the most common case, this part of the algorithm should be
explained in the specification.
If the two versions will continue to differ, both algorithms (and their
difference in behavior) should be explained,
but in order to avoid confusion for implementers/operators we believe
that specification of a single algorithm is preferable .

Regards,
  Roland and Polina

[*] https://github.com/torvalds/linux/blob/master/include/net/codel.h#L341

Am 02.12.2015 um 16:45 schrieb Wesley Eddy:
> These both have the intended status designated as "Informational".
> Similar to the questions asked for PIE, we/chairs need to understand
> if there's consensus on:
> - Are these specifications are clear and sufficient quality to publish?
> - Should the status of the RFCs be "Experimental", "Proposed
> Standard", or "Informational"?
>

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] TCP ACK Suppression

[Bless, Roland (TM)]

Hi,

Am 07.10.2015 um 09:42 schrieb LAUTENSCHLAEGER, Wolfram (Wolfram):
> Is this specialized upstream TCP ACK handling, particularly the
> prioritization a general recommendation in all access technologies? 
> Perhaps it should be, since otherwise up and downstream TCP flows interfere
> in a crazy queue oscillation that is typically misinterpreted by AQMs.
> Is this topic addressed in some RFC already?

Oh, I hope that this is an exception. Such kind of
optimizations may cause a lot of trouble since a link
layer device is interfering with transport layer semantics.
We all know that exactly these kinds of interference
eventually end up in problems with end-to-end transparency and
deployment of new protocol options. At least it interferes with
the ACK clocking expectation of some congestion control algorithms...

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] CoDel's control law that determines drop frequency

[Bless, Roland (TM)]

Hi,

Am 30.09.2015 um 15:02 schrieb Bob Briscoe:
> Yes, Toke's right - I was talking about how fast the control law moves,
> not the steady state.

Ok, talking past each other...I meant steady state of TCP flows and not
steady state of CoDel, i.e. CA phase not slow start. Sorry for the
confusion.

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] CoDel's control law that determines drop frequency

[Bless, Roland (TM)]

Hi,

Am 30.09.2015 um 13:52 schrieb Toke Høiland-Jørgensen:
> Polina Goltsman  writes:
> 
>>> Early on, Rong Pan showed that it takes CoDel ages to bring high load under
>>> control. I think this linear increase is the reason.
>>
>> Is there a link to this ?
> 
> I have an analysis of transient behaviour in my recent paper (section 6.2):
> http://www.sciencedirect.com/science/article/pii/S1389128615002479
> 
> PIE struggles with this too, BTW...

Thanks for the pointer, but I guess that's a different issue.
If I understood Bob correctly, he was referring to a steady state
situation with many flows (=high load?) in congestion avoidance phase.
But maybe Bob can clarify this...

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] PIE vs. RED

[Bless, Roland (TM)]

Hi,

while looking at the PIE presentation
http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-5.pdf,
slide 6 shows that RED is far away from the PIE
queuing delay. However, I'm not sure that this comparison is
really fair if looking at the choice of the parameters.
The buffer limit is set to 2000 packets, which is IMHO too large
for a BDP of 10Gbit/s * 100µs = 125000 bytes. Assuming your average
packet size of 1000 bytes we get 125 packets as buffer size.
Then Min_th = 25 packets and Max_th = 63 packets in contrast
to Min_th=400 packets if you use a buffer for 2000 packets.
For 25 packets you would also get a queuing delay of only
20µs for RED which is then close to the PIE target...
Was there a particular reason for using a 16x larger buffer
than required? Am I missing something here?

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] FQ-PIE kernel module implementation

[Bless, Roland (TM)]

Hi,

thanks for your analysis. Indeed, Polina came up with
a similar analysis for an unresponsive UDP flow and
a TCP flow. Flow queueing can achieve link share fairness
despite the presence of unresponsive flows, but is ineffective
if the AQM is applied to the aggregate and not to the individual
flow queue. Polina used the FQ-PIE implementation
to verify this behavior (post will follow).

Regards,
 Roland


Am 04.07.2015 um 22:12 schrieb Agarwal, Anil:
 Roland, Fred,
 
 Here is a simple example to illustrate the differences between FQ-AQM with 
 AQM per queue vs AQM per aggregate queue.
 
 Let's take 2 flows, each mapped to separate queues in a FQ-AQM system.
   Link rate = 100 Mbps
   Flow 1 rate = 50 Mbps, source rate does not go over 50 Mbps
   Flow 2 rate = 50 Mbps, adapts based on AQM.
 
 FQ-Codel, AQM per queue:
   Flow 1 delay is minimal
   Flow 1 packet drops = 0
   Flow 2 delay is close to target value
 
 FQ-Codel, AQM for aggregate queue:
   Does not work at all
   Packets are dequeued alternatively from queue 1 and queue 2
   Packets from queue 1 experience very small queuing delay
   Hence, CoDel does not enter dropping state, queue 2 is not controlled :(
 
 FQ-PIE, AQM per queue:
   Flow 1 delay is minimal
   Flow 1 packet drops = 0
   Flow 2 delay is close to target value
 
 FQ-PIE, AQM for aggregate queue:
   Flow 1 delay and queue 1 length are close to zero.
   Flow 2 delay is close to 2 * target_del :(
   qlen2 = target_del * aggregate_depart_rate
   Flow 1 experiences almost the same number of drops or ECNs as flow 2 :(
   Same drop probability and almost same packet rate for both flows
   (If flow 1 drops its rate because of packet drops or ECNs, the analysis 
 gets slightly more complicated).
 
 See if this makes sense.
 
 If the analysis is correct, then it illustrates that flow behaviors are quite 
 different
 between AQM per queue and AQM per aggregate queue schemes.
 In FQ-PIE for aggregate queue, 
   - The total number of queued bytes will slosh between 
 queues depending on the nature and data rates of the flows.
   - Flows with data rates within their fair share value will experience 
 non-zero packet drops (or ECN marks).
   - Flows that experience no queuing delay will increase queuing delay of 
 other flows.
   - In general, the queuing delay for any given flow will not be close to 
 target_delay and can be
 much higher



___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Any aqm evaluation at speeds =10Gbit/s?

[Bless, Roland (TM)]

Hi,

has anyone recently tested AQMs like Codel or PIE
at speeds of =10Gbit/s? If so, where are the results available?
Pointers greatly appreciated...

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

[Bless, Roland (TM)]

Hi,

On 13.05.2015 at 07:01 Fred Baker (fred) wrote:
 On May 12, 2015, at 9:06 PM, Simon Barber si...@superduper.net
 wrote:
 
 Where would be the best place to see if it would be possible to
 get agreement on a global low priority DSCP?
 
 I’d suggest
 
 https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines
 for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August
 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status:
 INFORMATIONAL)
 
 It refers to
 
 [QBSS] QBone Scavenger Service (QBSS) Definition, Internet2 
 Technical Report Proposed Service Definition, March 2001.
 
 (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and
 states that

While QBSS may have gotten more attention the original idea is here:
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00
from there it finally went to a PDB definition in RFC 3662 as you
already found out, because the DiffServ chairs didn't want it to be
defined as PHB.

 Within QBone, traffic marked with DSCP 001000 (binary) shall be 
 considered in the QBSS class and should be given the service
 described in this document.  Notice that while DSCP values
 generally have only local significance we are assigning global
 significance to this particular codepoint within QBone.  We refer
 to packets marked with DSCP 001000 as being marked with the QBSS
 code point”.
 
 
 That’s where we came up with recommending CS1 (001000) for the
 traffic class.

CS1 is maybe a problem because originally (rfc 2474) CS1 means better
priority than CS0. At that point in time of RFC3662 the discussion was
to use CS1, because also in 802.1p 1 means background. However,
this inconsistency makes it now hard to rely on any semantics of DSCP
CS1. IIRC the Diffserv chairs were opposed to spend another DSCP on LE
and therefore proposed to use an existing one. In retrospect, this
seems to have been a wrong decision given the problems of rtcweb and
so on these days.

 I’m pretty sure the latter ultimately resulted in an RFC, but for
 some reason I’m not finding it. The closest thing I see is

Yes, https://tools.ietf.org/html/rfc3662.

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] DOCSIS 3.1 support for AQM

[Bless, Roland (TM)]

Hi Greg,

Am 30.10.2013 21:13, schrieb Greg White:
 Cable modems are required to implement a variant of PIE (detailed in
 Annex M of MAC and Upper Layer Protocols Interface Specification
 http://www.cablelabs.com/specifications/CM-SP-MULPIv3.1-101-131029.pdf) as
 the default AQM.  Modem vendors are free to implement additional
 algorithms if they so choose.  CMTSs are required to implement an AQM
 meeting certain high-level criteria, but the choice of algorithm is left
 to the implementer.

Thanks for the information. I'd be interested in why you have chosen
PIE, e.g., instead of sfq-CoDel. Any pointers to evaluation
reports/results? Last time I saw a presentation on this it seemed
that CoDel was performing quite well.

Regards,
 Roland

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm