Subject: Re: [aqm] CoDel: After much ado ...

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 5 Oct 2017 13:25:51 +0200

Hi Jana,

thanks see below.

> Am 30.09.2017 um 03:01 schrieb Jana Iyengar <[email-masked]>:
> 
> Mirja,
> 
> Thanks for you review -- apologies for not addressing everything. I had left a few things out as not necessary to change the draft, but we've now made the following changes in draft-ietf-aqm-codel-09.
> 
> 1) Did you also check the sec-art and gen-art review. Both, as well as some ADs, suggested to (better) define such terms as Sojourn time, estimator, or Interval. Would it make sense to add something to the terminology section, or did you decide this is not needed?
> 
> We've added these definitons now in Section 2.

Thanks!

>  
> 2) Did you see Alia’s comments on mircoflows? I think it is true that in some cases you may also want to use additional information like the flow label or DSCP and not just the 5-tuple, while the text explicitly talks about 5-tuples. Do you want to add something here, or did you on purpose decide to only restrict to 5-tuples? I thinks this may be an unnecessary restriction and probably was not meant to be one.
> 
> We fixed the draft to remove mentions of 5-tuples. (This was already done in -08.)

Okay. I was wondering if you want to explain more explicitly what flow means, by e.g. saying something like it can be not only a 5-tuple but e.g. could also include DSCP but that is implementation dependent…?

>  
> 3) Did you see this comment from Ekr:
> "Following up on the above point, you must be able to
>   drop packets when the queue is entirely full, but S
>   4.4 doesn't seem to contemplate this. What is the impact
>   of this? You just drop and ignore?“
> Can you explain how this was addressed? Maybe I just missed that but it seems important.
> 
> There's nothing to be done if a packet arrives at a full buffer besides dropping it... we've added a sentence now that says "Packets arriving at a full buffer SHOULD be dropped." Hopefully that should clarify things.

The point here was rather the question if you count these as drop or not in your algorithm. I believe you don’t count them but only those packets that actually get dropped by CoDel directly, right? 

However, I don’t think using normative language in the sentences you’ve added makes sense because, as you say, drop is the only thing you can do. I guess you’d need to say something like this instead:

"Packets arriving at a full buffer will be dropped. These packets are not counted for the calculation of the CoDel algorithm.“

Or something similar…

Please let me know what you think and either update the draft, or we can also just add an RFC Editor not if that’s easier…

Mirja

> 
> Hope this covers everything that's pending -- let me know if I've missed anything.
> 
> (I received jim-jam biscuits/cookies from Jim Gettys which helped with this round -- thanks Jim :-))
> 
> 
> - jana
> 
> Thanks!
> Mirja
> 
> 
> 
> 
> > Am 12.09.2017 um 02:27 schrieb Jana Iyengar <[email-masked]>:
> >
> > ... draft-ietf-aqm-codel-08 is finally posted. This new version addresses all IESG comments during IESG review, in addition to review comments by Patrick Timmons and Yoav Nir. We thank everyone for their help with reviews.
> >
> > Most importantly, I want to personally thank the fq_codel authors for sending me Yerba Mate, Dave Taht for sending me delicious freshly-baked cookies, and Paul McKenney for sending me a ton of organic green tea to help me move on the document. I will say that you all managed to do something nobody has managed so far: you successfully shamed me into getting this work done.
> >
> > I also received bungee cords from the fq_codel authors to tie myself to my chair with, which I put to good use: I would like to share here evidence of my atonement. (Cookies are not in the picture, because they were delicious. Thanks, Dave!)
> >
> > - jana
> >
> > (P.S.: I now look forward to receiving thank you gifts. Oh, and I'm caffeine-free and vegetarian, just in case.)
> >
> 
>

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 13 Oct 2017 23:31:25 -0700

Hi Mirja,

I've posted -10 of the draft
<https://tools.ietf.org/html/draft-ietf-aqm-codel-10>, see more below.

> > 2) Did you see Alia’s comments on mircoflows? I think it is true that in
> some cases you may also want to use additional information like the flow
> label or DSCP and not just the 5-tuple, while the text explicitly talks
> about 5-tuples. Do you want to add something here, or did you on purpose
> decide to only restrict to 5-tuples? I thinks this may be an unnecessary
> restriction and probably was not meant to be one.
> >
> Okay. I was wondering if you want to explain more explicitly what flow
> means, by e.g. saying something like it can be not only a 5-tuple but e.g.
> could also include DSCP but that is implementation dependent…?

I really do not want to get into defining a flow; I think this works for
any definition of flow, since that's ultimately implementation dependent.
Any implementation can (as they do) assume whatever they want in terms of
defining a flow.

> > There's nothing to be done if a packet arrives at a full buffer besides
> dropping it... we've added a sentence now that says "Packets arriving at a
> full buffer SHOULD be dropped." Hopefully that should clarify things.
>
> The point here was rather the question if you count these as drop or not
> in your algorithm. I believe you don’t count them but only those packets
> that actually get dropped by CoDel directly, right?
>
> However, I don’t think using normative language in the sentences you’ve
> added makes sense because, as you say, drop is the only thing you can do. I
> guess you’d need to say something like this instead:
>
> "Packets arriving at a full buffer will be dropped. These packets are not
> counted for the calculation of the CoDel algorithm.“
>
> Or something similar…
>

I've removed normative language (Dave Taht also didn't like it) and
replaced it with some text about how it's not really used for CoDel
computations. I've also moved it to later in the draft where it fits
better.

I've also taken in some other editorial nits that I received from Lixia
Zhang in the meanwhile (Thanks, Lixia!).

Thanks all!
- jana

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 16 Oct 2017 10:42:54 +0200

Thanks! Will approve now! Finally! Yeah!

> Am 14.10.2017 um 08:31 schrieb Jana Iyengar <[email-masked]>:
> 
> Hi Mirja,
> 
> I've posted -10 of the draft, see more below.
>  
> I really do not want to get into defining a flow; I think this works for any definition of flow, since that's ultimately implementation dependent. Any implementation can (as they do) assume whatever they want in terms of defining a flow.
>  
> I've removed normative language (Dave Taht also didn't like it) and replaced it with some text about how it's not really used for CoDel computations. I've also moved it to later in the draft where it fits better. 
> 
> I've also taken in some other editorial nits that I received from Lixia Zhang in the meanwhile (Thanks, Lixia!). 
> 
> Thanks all!
> - jana

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 16 Oct 2017 11:29:22 +0200

> Thanks! Will approve now! Finally! Yeah!

And there was much rejoicing! Wooh! :)

-Toke

---

From: Andrew Mcgregor <[email-masked]>
Date: Mon, 16 Oct 2017 22:50:16 +1100

Win!

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: Dave Taht <[email-masked]>
Date: Mon, 16 Oct 2017 12:55:09 -0700

w00t!