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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Sat, 05 August 2017 10:06 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
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 ABED912EC13; Sat, 5 Aug 2017 03:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 KGgs0EY3FFzX; Sat, 5 Aug 2017 03:06:06 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 F3027131C9E; Sat, 5 Aug 2017 03:06:04 -0700 (PDT)
X-AuditID: c1b4fb25-607ff70000001eeb-70-5985988a81cf
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 06.68.07915.A8895895; Sat, 5 Aug 2017 12:06:03 +0200 (CEST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sat, 5 Aug 2017 12:06:02 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xJ7A9jetIuBz+PHXoDkvFPZizXYEkfAxRoNqfsQSOoc=; b=BedcLddo4coQP4ipZm1Y2LCY1YfKCzIqjYNcRrtDqJOFLrN+b29b0QdRVxUliS5Ct0bMFE+Uqdt5Klf/aik3liVZFw/5KweUIF8V2M9/xLhlnvZ8G9tteFYlB/N79Z6Pwua+HbxGeWniHvrRJNydZjy63efa0hOBP5iUqp1zBhM=
Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0656.eurprd07.prod.outlook.com (10.141.44.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Sat, 5 Aug 2017 10:06:01 +0000
Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::8189:db45:e10d:bbc0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::8189:db45:e10d:bbc0%16]) with mapi id 15.01.1304.025; Sat, 5 Aug 2017 10:06:01 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: 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>
CC: "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-nada@ietf.org" <draft-ietf-rmcat-nada@ietf.org>
Thread-Topic: [rmcat] Still looking for reviews of draft-ietf-rmcat-nada
Thread-Index: AQHS8dNhy65fQ5vDK0m2BUYcYMBYhKJDji0ggBXWXwCAAN95AIAAkgMAgABIEQCAAf71gIAAG9PwgAcQYeCAASm6gIAQSydw
Date: Sat, 5 Aug 2017 10:06:00 +0000
Message-ID: <DB4PR07MB3488B573F1DE638EF6BE28FC2B70@DB4PR07MB348.eurprd07.prod.outlook.com>
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>
In-Reply-To: <f28bac82-f921-b40d-7a1a-6a6656a8f6f4@kau.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [213.113.27.92]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB4PR07MB0656; 6:4SU9WJZGO3aX4MWNjS0lNXNZ/CMzs/2npcZtk9r57LPEYo+o8gJnBYWXAJKE+U76WO8Lm3N8aK5IZUHyh3QZ+RdEpfvI4y6xERVqdppK3dA6JXFDTOBKnIZqeidMo8n+ECN/DML5vMVen0iZRUBmh5O8Yiai3+df2HKIl8yPnuzMrWjvOSkxNeZeN1J+J3bSbCDmyDOnEcf3G3H3k5oBWpafIs6pSAN68xpKVjhAXOrrEiJMVJOlk+6/81LX+JiOIxQuRyvjSiaE6F1uywLAJs5YwpEtkORANst4JiUAfbl7ejNyPd7gW9wzOFAEXY2LHnifP7WquFpo2JbT4o77ig==; 5:EQQsh0dDzvz33aBcU686GrLrQagLy70IVm2A2UYo0tubKUNA50Q+itOf04ZiDdeswziewGR3UWHDoNmryPzAsjdBEc6Ao6IMmhThfnWYcnJwZ+6LxQQMqLMUnA8rXRRAx1vMBq9Vrtm44c3KgkrXdw==; 24:pPYJ128rnBVR3kIpTtzGbLxWQ9lRBkRv96IhcsjU98F4W30cFKw/AL8niFdxvXJI5zHyZwWRTkXDCRiirz+ghE6XhNhUpbKoJ/wZvOkA1PY=; 7:AiQF2muSCpkad/RLBPV1bwYBN3IT/4oDXetiTL7BtRRBjECX+nekQC2cqB+YM2NgSmFYfQMsVDAWSaxdnebnwGacM8oceDtbghBvm4O4jAypp0W8h4BbiCPWyVN0KyQYkMrDuPpfQO7KskXqPP8wnb5y85tuBBpbnqNH6kJp6Yp2WdbsUNPiIowpxdqtTpuCqwkT85Tq7xhhKaSxG0mO5M6OVvJDf9PttkUE2gpRd+k=
x-ms-office365-filtering-correlation-id: dadc7b68-531f-4509-fb39-08d4dbe99349
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0656;
x-ms-traffictypediagnostic: DB4PR07MB0656:
x-exchange-antispam-report-test: UriScan:(37575265505322)(35073007944872)(95692535739014)(148717330147763);
x-microsoft-antispam-prvs: <DB4PR07MB06565CF7AA8143DB3F66DF26C2B70@DB4PR07MB0656.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0656; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0656;
x-forefront-prvs: 0390DB4BDA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39850400002)(39400400002)(39840400002)(39450400003)(39410400002)(377424004)(24454002)(51444003)(199003)(252514010)(13464003)(377454003)(189002)(86362001)(189998001)(9686003)(6306002)(97736004)(33656002)(106356001)(55016002)(229853002)(54356999)(54906002)(2950100002)(101416001)(99286003)(105586002)(966005)(50986999)(76176999)(2900100001)(53546010)(14454004)(478600001)(25786009)(4326008)(6436002)(7736002)(3660700001)(305945005)(81166006)(230783001)(81156014)(7696004)(8676002)(38730400002)(5660300001)(74316002)(3280700002)(2906002)(3846002)(93886004)(8936002)(5250100002)(6116002)(102836003)(53936002)(6506006)(6246003)(68736007)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0656; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2017 10:06:00.9638 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0656
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHO+9tr5flaSk+aEKu/KCYWmmMkFIJWkHghyQdVC590TWdspmp UF5KM2VZeFdEHctbgWiBpWa2tMzQlkZpYN5m2kUwFS9Y1rZXoW+/5///n+c8z+GwpEhHu7AK VRKnVsnjxIwtVR7e5n4gvyw7wi+zgZT0rQ2TEqNuhpbUf02TPBhdYCQPS1cEkh8364ggRlq0 0UJL9fp1QvrHmM1IMzOeEqGUzDYwmotTJHNq32ORtrH3tSOCxIZzKROvXDJQblgesmEB+0P/ +3kyD9myItyDYK1qnuKL1wiaZietBYW1JOiGirdiJQR8GByg+WICwccOk8DSjMGB0GhYRRbD ET9HMFCcy1gMEl+GoukWysK78UmoWZ+y6o5YCn8N/QTPKsja1NMWpvB+qCv9jiwsxDLIuFNv 1UV4nYKljusWtsFHoa1uytoTYTcYX/1C8Xc5w2dTNcFvh0Hf+Y7k2Qm+TW/SfD4KFke1ZmbN ujv0FF3lI24wVJ1vnR9wjgC0+hGGN85AZ1UhwxtTBBhnxraaesFqzW+KZyXM1c4ivqkSeldi +LyBhtWG7cwe+DW3TPPGEAOlYzrqLvKu+G/wCvN5EntCc7svL7tDUf6koML6FrvgTbmJqkFU E3LScJpL8TGHDvtwakWURpOg8lFxSa3I/HNePN7weIKGfwYbEGaR2F4Yci07QkTLkzWp8QYE LCl2FIYVmiVhtDw1jVMnXFRfieM0BuTKUmJnYXCXMVyEY+RJnJLjEjn1tkuwNuaP45fTeMJb n2WvsFcO6stKKmNvdy8SISl9bxcrP5kyy3ccj5SlJ7h6hPbUFwfRp7S9e6t80iftRro497Ph 5l1N7Q43WgoCapf3LUnD7MZ3dhiVzc1qgTIhGmXaL1Q8GvYPuNXgKTt/ZNFl3Fn+svXehfCW ZUVgl+B0t3PBsxiZg5jSxMoPepFqjfwfJozL9TUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/AK_G916Tbhuqi0YCFdsxFbPAchw>
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 10:06:10 -0000

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>om>; Xiaoqing
> Zhu (xiaoqzhu) <xiaoqzhu@cisco.com>om>; 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>om>; Flohr, Julius
> >> <julius.flohr@uni-due.de>de>; Sergio Mena de la Cruz (semena)
> >> <semena@cisco.com>
> >> Cc: Anna Brunstrom <anna.brunstrom@kau.se>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>de>; Sergio Mena de la Cruz
> >>> (semena) <semena@cisco.com>
> >>> Cc: Anna Brunstrom <anna.brunstrom@kau.se>se>; Ingemar Johansson S
> >>> <ingemar.s.johansson@ericsson.com>om>; 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
> >>> =====================================
> >