From nobody Thu Feb 18 05:02:58 2021 Return-Path: X-Original-To: nwcrg@ietfa.amsl.com Delivered-To: nwcrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A13A11D8; Thu, 18 Feb 2021 05:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ii6itIBYCOdT; Thu, 18 Feb 2021 05:02:50 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 474153A11D6; Thu, 18 Feb 2021 05:02:49 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1lCixC-0007Xn-GG; Thu, 18 Feb 2021 14:02:46 +0100 Received: from ti0182q160-3425.bb.online.no ([62.249.177.137] helo=[192.168.1.7]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1lCixB-0001qI-Ia; Thu, 18 Feb 2021 14:02:46 +0100 From: Michael Welzl Message-Id: <6AAD8EE9-165A-4DE8-A948-85B9F0331819@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_40185E62-B19C-47E6-8C99-03877A075AD4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 14:02:44 +0100 In-Reply-To: Cc: roca , iccrg IRTF list , Kuhn Nicolas , "nwcrg@irtf.org" To: Marie-Jose Montpetit References: <161346137865.25827.8548083280026753510@ietfa.amsl.com> <1C77F32B-9B7F-4892-9E44-BF6CA7CA8595@inria.fr> <10191065-AEEE-4BE8-A481-3A7C1F1621FA@ifi.uio.no> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 62.249.177.137 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.249.177.137; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.034, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 5F6A0E51F5F21A4CCE93E6BD6EF5F2F0BB1892B3 Archived-At: Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt X-BeenThere: nwcrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IRTF Network Coding Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 13:02:53 -0000 --Apple-Mail=_40185E62-B19C-47E6-8C99-03877A075AD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Cutting some clutter: >>> - My experience with NC is that the most gains are in low loss = networks (far from network capacity) - where in fact CC protocols over = react- is there research on appropriate metrics? >>=20 >> *low* loss, far from network capacity? Why would a CC mechanism = over-react? When it=E2=80=99s far from the capacity, there=E2=80=99s = nothing to react upon=E2=80=A6 did you mean that they are too cautious = and flows terminate before even reaching the capacity limit? I can = imagine this being an interesting scenario for coding indeed, but I=E2=80=99= d like to understand if this is what you meant. >=20 > What I meant is that the greatest descent due to errors in TCP occurs = under very low =E2=80=9Cperceived=E2=80=9D loss conditions (like less = than 1%). >=20 I=E2=80=99m sorry, I=E2=80=99ll have to ask for more clarification, = I=E2=80=99m afraid. With =E2=80=9Cperceived=E2=80=9D, surely you mean = loss that=E2=80=99s perceived at the transport layer? Low loss leads to = the greatest descent there? What is it that you have in mind - = situations where the cwnd has grown to be very large (because loss is = low), and then, when loss happens, it=E2=80=99s devastating (because, = e.g., halving it is a huge effect)? I could agree with that. > This is where the coding =E2=80=9Cgains=E2=80=9D are the most = important. Also some temporary =E2=80=9Cperceived=E2=80=9D congestion = (when there is in fact still capacity) can have longer term effect if = the CC is very conservative (and yes someone will tell me it=E2=80=99s = not fully the case anymore). All of this to say that the draft should be = clearer on the type of research that is needed again when the = performance is impacted 2 conflicting control loops. >=20 I don=E2=80=99t fully subscribe to this =E2=80=9C2 conflicting control = loops=E2=80=9D view. It depends on the scenario, I guess. E.g., if = congestion control operates on unreliable data transfer, and FEC = operates on top, repairing losses, then these are quite separate = functions, doing separate things, not conflicting. Anyway, it=E2=80=99s fair that you ask for more clarity in the draft, = but that=E2=80=99s why I=E2=80=99m trying to really understand your = concrete questions or concerns. Cheers, Michael --Apple-Mail=_40185E62-B19C-47E6-8C99-03877A075AD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Cutting= some clutter:


- My experience with NC is = that the most gains are in low loss networks (far from network capacity) = - where in fact CC protocols over react- is there research on = appropriate metrics?

*low* loss, far from = network capacity? Why would a CC mechanism over-react? When it=E2=80=99s = far from the capacity, there=E2=80=99s nothing to react upon=E2=80=A6 = did you mean that they are too cautious and flows terminate before even = reaching the capacity limit?  I can imagine this being an = interesting scenario for coding indeed, but I=E2=80=99d like to = understand if this is what you = meant.

What I meant is that the greatest descent due to = errors in TCP occurs under very low =E2=80=9Cperceived=E2=80=9D loss = conditions (like less than 1%).

I=E2=80=99m sorry, = I=E2=80=99ll have to ask for more clarification, I=E2=80=99m afraid. = With =E2=80=9Cperceived=E2=80=9D, surely you mean loss that=E2=80=99s = perceived at the transport layer? Low loss leads to the greatest descent = there? What is it that you have in mind - situations where the cwnd has = grown to be very large (because loss is low), and then, when loss = happens, it=E2=80=99s devastating (because, e.g., halving it is a huge = effect)?  I could agree with that.

This is where the coding =E2=80=9Cgains=E2=80=9D are = the most important. Also some temporary =E2=80=9Cperceived=E2=80=9D = congestion (when there is in fact still capacity) can have longer term = effect if the CC is very conservative (and yes someone will tell me = it=E2=80=99s not fully the case anymore). All of this to say that the = draft should be clearer on the type of research that is needed again = when the performance is impacted 2 conflicting control = loops.

I don=E2=80=99t fully subscribe to this = =E2=80=9C2 conflicting control loops=E2=80=9D view. It depends on the = scenario, I guess. E.g., if congestion control operates on unreliable = data transfer, and FEC operates on top, repairing losses, then these are = quite separate functions, doing separate things, not = conflicting.

Anyway, it=E2=80=99s fair that you ask for more clarity in = the draft, but that=E2=80=99s why I=E2=80=99m trying to really = understand your concrete questions or concerns.

Cheers,
Michael

= --Apple-Mail=_40185E62-B19C-47E6-8C99-03877A075AD4--