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

Michael Welzl <michawe@ifi.uio.no> Sat, 05 August 2017 11:56 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0695E12ECB7; Sat, 5 Aug 2017 04:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX9KDuBx1VNe; Sat, 5 Aug 2017 04:56:20 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E24C131C9E; Sat, 5 Aug 2017 04:56:12 -0700 (PDT)
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1ddxge-0002qk-4C; Sat, 05 Aug 2017 13:56:08 +0200
Received: from 21-50-11.connect.netcom.no ([176.11.50.21] helo=[172.20.10.3]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1ddxgd-000FJW-0E; Sat, 05 Aug 2017 13:56:08 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <DB4PR07MB3488B573F1DE638EF6BE28FC2B70@DB4PR07MB348.eurprd07.prod.outlook.com>
Date: Sat, 05 Aug 2017 13:56:35 +0200
Cc: Anna Brunstrom <anna.brunstrom@kau.se>, "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>, "Flohr, Julius" <julius.flohr@uni-due.de>, "Sergio Mena de la Cruz (semena)" <semena@cisco.com>, "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-nada@ietf.org" <draft-ietf-rmcat-nada@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D174F4F-520C-466B-93B3-D0102B685157@ifi.uio.no>
References: <7c5453a5-65f6-6f74-6214-346469c8abce@kau.se> <c8d9ec64-c332-fa8d-dd20-3dd307aabb97@kau.se> <DB4PR07MB348F7D8702DC16028081554C2D70@DB4PR07MB348.eurprd07.prod.outlook.com> <62513FF8-0A36-45FC-878C-7D03A1772A2A@uni-due.de> <6ca96a44-0ca2-2704-41f6-3eaeaf35afa7@kau.se> <aa200a17-1d8c-9570-2b51-364a08a131a6@cisco.com> <830396B0-DCDB-42F3-BAF7-EE122CA123D1@uni-due.de> <1500572924701.63015@cisco.com> <DB4PR07MB348D79F58A6246C1F6757D4C2A70@DB4PR07MB348.eurprd07.prod.outlook.com> <DB4PR07MB348F1F88488E3168E696432C2B80@DB4PR07MB348.eurprd07.prod.outlook.com> <f28bac82-f921-b40d-7a1a-6a6656a8f6f4@kau.se> <DB4PR07MB3488B573F1DE638EF6BE28FC2B70@DB4PR07MB348.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3273)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 176.11.50.21 is neither permitted nor denied by domain of ifi.uio.no) client-ip=176.11.50.21; envelope-from=michawe@ifi.uio.no; helo=[172.20.10.3];
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 56514 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.082, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 9BC748427755E701CB00E9370C32A3012CC0397D
X-UiO-SPAM-Test: remote_host: 176.11.50.21 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5 max/h 1 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/YHqK4jtrdOaZTV-E97tRJqZEhNY>
Subject: Re: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Aug 2017 11:56:25 -0000

+1, of course  :-)
i (naturally) liked seeing this in SCREAM, and I do think the logic of ABE (draft-ietf-tcpm-alternativebackoff-ecn) applies to all RMCAT controls  (why wouldn’t it?).

So, thanks Ingemar for pointing this out!

Cheers,
Michael


> On Aug 5, 2017, at 12:06 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> 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:anna.brunstrom@kau.se]
>> Sent: den 26 juli 2017 03:06
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Xiaoqing
>> Zhu (xiaoqzhu) <xiaoqzhu@cisco.com>; Flohr, Julius <julius.flohr@uni-
>> due.de>; Sergio Mena de la Cruz (semena) <semena@cisco.com>
>> Cc: rmcat@ietf.org; draft-ietf-rmcat-nada@ietf.org
>> 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)' <xiaoqzhu@cisco.com>; Flohr, Julius
>>>> <julius.flohr@uni-due.de>; Sergio Mena de la Cruz (semena)
>>>> <semena@cisco.com>
>>>> Cc: Anna Brunstrom <anna.brunstrom@kau.se>; rmcat@ietf.org;
>>>> draft-ietf- rmcat-nada@ietf.org
>>>> 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:xiaoqzhu@cisco.com]
>>>>> Sent: den 20 juli 2017 19:48
>>>>> To: Flohr, Julius <julius.flohr@uni-due.de>; Sergio Mena de la Cruz
>>>>> (semena) <semena@cisco.com>
>>>>> Cc: Anna Brunstrom <anna.brunstrom@kau.se>; Ingemar Johansson S
>>>>> <ingemar.s.johansson@ericsson.com>; rmcat@ietf.org;
>>>>> draft-ietf-rmcat- nada@ietf.org
>>>>> 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 <julius.flohr@uni-due.de>
>>>>> Sent: Wednesday, July 19, 2017 6:19 AM
>>>>> To: Sergio Mena de la Cruz (semena)
>>>>> Cc: Anna Brunstrom; Ingemar Johansson S; rmcat@ietf.org;
>>>>> draft-ietf-rmcat- nada@ietf.org
>>>>> Subject: Re: [rmcat] Still looking for reviews of
>>>>> draft-ietf-rmcat-nada
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On 19. Jul 2017, at 09:01, Sergio Mena <semena@cisco.com> 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:  julius.flohr@uni-due.de
>>>>> Phone: +49-201-183-7667
>>>>> Fax:     +49-201-183-7673
>>>>> =====================================
>>> 
>