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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 25 July 2017 07:22 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 D9A66131822; Tue, 25 Jul 2017 00:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 CtmfmZS4Fl38; Tue, 25 Jul 2017 00:22:56 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 9C21D13188F; Tue, 25 Jul 2017 00:22:55 -0700 (PDT)
X-AuditID: c1b4fb2d-857ff70000005f66-90-5976f1cdf981
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.BD.24422.DC1F6795; Tue, 25 Jul 2017 09:22:53 +0200 (CEST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 25 Jul 2017 09:22:53 +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=J1dE5r5NsYseMZympAXScCKjJVUFOZZ0R51tlE8t5Pk=; b=m7uhKZnPEtaKaCN9dqEg1TfIwIjUOXMoPbysumjDZtXtkdZb6L22opTSYv6/0WOf5unNGJ6n0fbnQgfV5KjSnWvvkXz9kghif4hvrYiFfFy22KlubWV5QEiAtLfzDL6774gzXWxsoPY9mzhS+UpgXe7APVLVL08eQBz9KeEh220=
Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0671.eurprd07.prod.outlook.com (10.141.44.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Tue, 25 Jul 2017 07:22:51 +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.011; Tue, 25 Jul 2017 07:22:51 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
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" <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: AQHS8dNhy65fQ5vDK0m2BUYcYMBYhKJDji0ggBXWXwCAAN95AIAAkgMAgABIEQCAAf71gIAAG9PwgAcQYeA=
Date: Tue, 25 Jul 2017 07:22:51 +0000
Message-ID: <DB4PR07MB348F1F88488E3168E696432C2B80@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>
In-Reply-To: <DB4PR07MB348D79F58A6246C1F6757D4C2A70@DB4PR07MB348.eurprd07.prod.outlook.com>
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; DB4PR07MB0671; 7:tvd2Y5u0Lnt+Tm2ol1Z5ddq5DgX0JgtEXNHWMrKklXHReJ22nqfJqJKm3I3vXZX41ywilWQcofGjL2nQMz/I0kHcttSakJQz1RLGJ1jcfHcNM3+WWsZNcGyeydu83dR5rmD/kocsLCfcq9Iqmb8kx30G44nWnto1+vJsZyT161lDBBiP6HmpsVu4xvXkpbT61+EyIioga7GHNAKY9JtOzJivlETiu704ZzlzZKyv2xNTQcYkFgDnmllvH98IDJkMhTRSnLeHxJHhv0lGGdInUrmIlHHC6YAUuBypTjCjc6l0tzvT1jwPVAGbAKeCbeIPVCk1+x9Fb0rMD1DEl6vUpqn5JlvtAxB+bgPifSRKLq6ca8aljHfSun8J5+hamGgYRXfswUgPFddR9Rg9RaR76qHVsx08jcFj8ty6pGLwlH06pYMToUpXqoS0B3qkuCn2J/i+RH9xWkb6eZYl9dm3KFFCnWqN/dRx/wKnW4avCgWGbGR35ujTX1eJf17wfYXqIcMlMMGeNXouz0yzLkMQxEqinhwVGgyazwoBMdf8fmNNIo6pojDckY+pqdW5fS4RT68M3lnLvYI9GMJiJ4Qg05XOi0PsgkWVGcBePj3d3fO9wYfZbE4HFMPoLXLUH1YTFN4JeabIUzFKdjEOJH/bSbFc3cMv+FnIawN6eLQZgIIvm0msCjpCp4r2brjEdky2G077zkhKRjfPNOXz0iSlxT17nui0dkIMyBmbJ91kNIKXICYl7c12xUTkRwHi+e4U8wJb59+EdZzoCJrcCNlr6kyiHsL4Kp2JNzs+C3dXOMA=
x-ms-office365-filtering-correlation-id: af56a432-1543-4dac-f752-08d4d32df597
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB0671;
x-ms-traffictypediagnostic: DB4PR07MB0671:
x-exchange-antispam-report-test: UriScan:(37575265505322)(35073007944872)(95692535739014)(148717330147763);
x-microsoft-antispam-prvs: <DB4PR07MB06716D7DD1D0E27A9E08B6ECC2B80@DB4PR07MB0671.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)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB0671; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB0671;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(189002)(252514010)(13464003)(199003)(24454002)(377454003)(53936002)(8676002)(106356001)(8936002)(4326008)(101416001)(74316002)(93886004)(81166006)(81156014)(2950100002)(229853002)(102836003)(3660700001)(3846002)(2906002)(6116002)(189998001)(3280700002)(305945005)(7736002)(97736004)(68736007)(53546010)(5250100002)(6506006)(86362001)(105586002)(5660300001)(2900100001)(6246003)(38730400002)(99286003)(478600001)(55016002)(54906002)(7696004)(9686003)(66066001)(6436002)(33656002)(54356999)(76176999)(230783001)(50986999)(14454004)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0671; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2017 07:22:51.2511 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0671
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUhUURjHOXfzKk0cN/wwJZwQydQse5hAZAyieaiMHkotqEmvOrk2d9Q0 iTH1oREtwzL1wWXUsDEjkWxx66YyWqZp4JZrppWaC+WCqDlzFXr7/b///zvnOx+HJW30tCOr itFw6hhllJSxovID63w8OxcTgryNS54y42ovKesu/U7LnkwlywwDC4ysKm/ZQjaTXkHIGUXu +gtaUVa2Rig2ujMYRar2NXGOCrbyDeWiVAmc+rDfVauI+a56Km7O+2Zpua0WpbnpEMsCPgbZ aX46ZMXa4BYEz/TPLURhRFA9t0iZBIWzSGj7XEiITh4BI9mfdsQ4At1iBqNDliyDfaFSWEEm ww7nIUjtXadNgsQPEDT8abIwpWzxKShemzB32GEFbAkdhMjXoKA/E5mYwq4w1JxvzktwMPyt aqLE65ZJGK1cZUyjW+JLMPvezZRB2BlGV0YoE5PYAQYni8xnAsZQVt9FimwPP79t0mI+BJYG smhxAy7QkpsoRpyhpyjT/ADAYwy0bhgpMXMG9F0pYn2CgBbdLC02uG/XWxiRI+FHyTTaZcOb 6Z2DBBpKX9ZQouEEFe0CKRpVDCykG+j7yKPgv8FF9oL+h7mMyIegomSGLDAvwxra8yepYkQ9 RfY8x/PR4Ud9vDi1KoTnY2O8YjhNDdr+Ou9q1z1fIcOMv4Awi6R7JF6jCUE2tDKBT4oWELCk 1E7iMbxdkoQqk5I5dewVdXwUxwtoH0tJHSTyxu5AGxyu1HCRHBfHqXddgrV01KJHbomBqhrF 47OCa+BHISN68+LxUC7sgxNj2xV2efhAjt91f22Awfp2qf6rILvLZVc6xucMnQzQ9Nj5bZ3P qj3tcUM+31g+9iUl0lhyobDOt2Fa6zw47tDRV12zkatxnOqM3+hzuVfyiyg++Lb+1mRbs/zO Xvb3fofs4BONSF/VKqX4COURd1LNK/8BC4/p9zYDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/KOtyl8tFz8s8I5ro1fUZel-GjLk>
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: Tue, 25 Jul 2017 07:22:59 -0000

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
> > =====================================