Re: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada

[Ingemar Johansson S <[e-mail]>]

Hi
Not sure that we are in full agreement, it is possible that I misunderstand.
The estimation of marking ratio in section 5.1.2 in the NADA draft indicates a scalable reaction (read L4S). 

As I understand it, one cannot assume that classic ECN marking makes it possible to use a scalable response. What is possible to do is to use ECN marking events (one or more ECN marked packets in one window or RTT) as a signal to reduce the sending rate for instance 50% or whatever is deemed appropriate (see e.g. https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-01 ). 

Agree that we can leave L4S out of scope for the time being.

/Ingemar


> -----Original Message-----
> From: Anna Brunstrom [mailto:[e-mail]]
> Sent: den 26 juli 2017 03:06
> To: Ingemar Johansson S <[e-mail]>; Xiaoqing
> Zhu (xiaoqzhu) <[e-mail]>; Flohr, Julius <julius.flohr@uni-
> due.de>; Sergio Mena de la Cruz (semena) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada
> 
> Hi Ingemar,
> 
> I think this is actually even more related to the feedback than the marking,
> the "classic" feedback provided by TCP does not tell you how many marked
> packets you have received. But as the RTCP feedback gives you per packet
> information I think there will be no difference from when you have an AQM
> with loss in this case?
> 
> L4S will give you a different marking, but I think that should be left out of
> scope at the moment and treating lost and marked packets the same in
> accordance with RFC 6679 is fine.
> 
> BR,
> Anna (as an individual)
> 
> 
> On 2017-07-25 09:22, Ingemar Johansson S wrote:
> > Hi
> > An errata...
> >
> > Referring to "classic" AQMs like CoDel "It is AFAIK possible to
> > accurately indicate the degree of congestion" should read "It is AFAIK
> > not possible to accurately indicate the degree of congestion"
> >
> > /Ingemar
> >
> >> -----Original Message-----
> >> From: Ingemar Johansson S
> >> Sent: den 20 juli 2017 21:55
> >> To: 'Xiaoqing Zhu (xiaoqzhu)' <[e-mail]>; Flohr, Julius
> >> <[e-mail]>; Sergio Mena de la Cruz (semena)
> >> <[e-mail]>
> >> Cc: Anna Brunstrom <[e-mail]>; [e-mail];
> >> draft-ietf- [e-mail]
> >> Subject: RE: [rmcat] Still looking for reviews of
> >> draft-ietf-rmcat-nada
> >>
> >> Hi Xiaoqing + others
> >>
> >> To your ECN question... This is tricky, if I understand things right
> >> you tie NADA to a specific ECN marking algorithm. For instance CoDel
> >> will display a completely different ECN marking behavior. The snag is
> >> that with classic ECN marking like this you can only indicate the
> >> existence of congestion. It is AFAIK possible to accurately indicate the
> degree of congestion.
> >> L4S is a different story as it allows to indicate the degree of congestion.
> >>
> >> /Ingemar
> >>
> >>
> >>> -----Original Message-----
> >>> From: Xiaoqing Zhu (xiaoqzhu) [mailto:[e-mail]]
> >>> Sent: den 20 juli 2017 19:48
> >>> To: Flohr, Julius <[e-mail]>; Sergio Mena de la Cruz
> >>> (semena) <[e-mail]>
> >>> Cc: Anna Brunstrom <[e-mail]>; Ingemar Johansson S
> >>> <[e-mail]>; [e-mail];
> >>> draft-ietf-rmcat- [e-mail]
> >>> Subject: Re: [rmcat] Still looking for reviews of
> >>> draft-ietf-rmcat-nada
> >>>
> >>> Catching up on this thread.
> >>>
> >>> Thanks much to Julius, Ingmar, and Safiqul for reviewing this draft
> >>> and providing your input.
> >>>
> >>> Regarding Ingmar's comments:
> >>>
> >>> * Page 8, computation of d_tilde and the risk of being locked in the
> >>> loss- based mode due to non-linear warping:  fully agree that this
> >>> is a limitation of the algorithm we should acknowledge in the draft.
> >>> In the meanwhile would like to work with Julius to look into
> >>> specific example failure cases, and hopefully derive further
> >>> insights on how to better tune the algorithm parameters.  Will
> >>> update both our ns3-rmcat implementation and NADA draft after that
> investigation.
> >>>
> >>> * Section 5.1.2 : Estimation of p_mark : as I understand your
> >>> comments point to the fact that different ECN marking behaviors may
> >>> occur and some (e.g.,
> >>> L4S) may not interact well with NADA.  It is true that we have not
> >>> tested NADA extensively against different variants of ECN markings
> >>> --- the one's we've tried before are RED (marking instead of dropping).
> >>> One way to help clarify that will be to point to our Appendix A.2 as
> >>> the specific ECN marking behavior we expect, in Sec. 5.1.2.  Do you
> >>> think that will address your concern?
> >>>
> >>> And, thanks to Julius for sharing with us issues you've observed in
> >>> your implementation efforts.  We've set up a separate email thread
> >>> to meet up remotely and go over that in greater technical details.
> >>>
> >>> Question back to the Chairs:  our plan now is to update both our
> >>> draft (to address both sets of Ingmar's comments) and corresponding
> >>> ns3
> >>> open- source implementation, within a month.  Procedure-wise, are we
> >>> expecting the updated version (-05) to go through WGLC again at that
> >>> point?  Just trying to understand what to expect next.
> >>>
> >>> Thanks,
> >>> Xiaoqing
> >>>
> >>>
> >>>
> >>> ________________________________________
> >>> From: Flohr, Julius <[e-mail]>
> >>> Sent: Wednesday, July 19, 2017 6:19 AM
> >>> To: Sergio Mena de la Cruz (semena)
> >>> Cc: Anna Brunstrom; Ingemar Johansson S; [e-mail];
> >>> draft-ietf-rmcat- [e-mail]
> >>> Subject: Re: [rmcat] Still looking for reviews of
> >>> draft-ietf-rmcat-nada
> >>>
> >>> Hi,
> >>>
> >>>> On 19. Jul 2017, at 09:01, Sergio Mena <[e-mail]> wrote:
> >>>>
> >>>>
> >>>> As for Julius's tests, we thank Julius for the effort put into it,
> >>>> and would like
> >>> to see how his results compare to our latest ones (see Slides
> >>> presented by Xiaoqing in April's RMCAT interim).
> >>> I haven't done too much testing, but as far as I can tell there is
> >>> an issue when the bottleneck bandwidth is smaller than RMAX:
> >>> If you have a competition scenario between NADA and a loss based
> >>> flow, it seems that nada gets stuck in the competitive mode because
> >>> itself creates queueing delay that is larger than QTH.
> >>>
> >>> I actually made a little mistake when I said the problem has gotten
> >>> worse compared to the last version of the draft. The issue actually
> >>> has been introduced in version 03 with the introduction of TEXPLOSS.
> >>> Before, the draft was very unclear and stated that one should warp
> >>> the congestion signal IFF packet loss is present, but without stating a
> time span.
> >>>
> >>> Therefore the implementation just used the knowledge it had from the
> >>> recent observation window LOGWIN (500 ms). That worked really well
> >>> because it helped the algorithm to return to the normal mode of
> >>> operation more easily, because after that timespan it would stop
> >>> warping regardless whether there is lots of queueing delay present or
> not.
> >>>
> >>> I don't know if this is an issue with my implementation or if there
> >>> is an actual issue with the algorithm, but this is what I have observed.
> >>>
> >>> I'll contact Xiaoqing and Sergio directly so we can work together on
> >>> this issue and post our findings to this mailing list directly.
> >>>
> >>> Regards,
> >>>
> >>> Julius
> >>>
> >>>
> >>> =====================================
> >>> Julius Flohr, M.Sc.
> >>> University of Duisburg-Essen
> >>> Computer Networking Technology Group
> >>>
> >>> Room SL-408
> >>> Schützenbahn 70
> >>> D-45326 Essen/Germany
> >>>
> >>> E-Mail:  [e-mail]
> >>> Phone: [phone]
> >>> Fax:     [phone]
> >>> =====================================
> >