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 >>>>> ===================================== >>> >
- [rmcat] RMCAT WGLC: draft-ietf-rmcat-nada-04 - en… Anna Brunstrom
- [rmcat] Still looking for reviews of draft-ietf-r… Anna Brunstrom
- Re: [rmcat] Still looking for reviews of draft-ie… Flohr, Julius
- Re: [rmcat] Still looking for reviews of draft-ie… Ingemar Johansson S
- Re: [rmcat] Still looking for reviews of draft-ie… Flohr, Julius
- Re: [rmcat] Still looking for reviews of draft-ie… Safiqul Islam
- Re: [rmcat] Still looking for reviews of draft-ie… Anna Brunstrom
- Re: [rmcat] Still looking for reviews of draft-ie… Sergio Mena
- Re: [rmcat] Still looking for reviews of draft-ie… Flohr, Julius
- Re: [rmcat] Still looking for reviews of draft-ie… Xiaoqing Zhu (xiaoqzhu)
- Re: [rmcat] Still looking for reviews of draft-ie… Ingemar Johansson S
- Re: [rmcat] Still looking for reviews of draft-ie… Ingemar Johansson S
- Re: [rmcat] Still looking for reviews of draft-ie… Anna Brunstrom
- Re: [rmcat] Still looking for reviews of draft-ie… Anna Brunstrom
- Re: [rmcat] Still looking for reviews of draft-ie… Ingemar Johansson S
- Re: [rmcat] Still looking for reviews of draft-ie… Michael Welzl