[Lsr] Congestion (flow) control thoughts.

Christian Hopps <chopps@chopps.org> Wed, 29 April 2020 12:24 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B573A0E12 for <lsr@ietfa.amsl.com>; Wed, 29 Apr 2020 05:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 SwCQu_-ZHEPX for <lsr@ietfa.amsl.com>; Wed, 29 Apr 2020 05:24:17 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id AB9523A0E11 for <lsr@ietf.org>; Wed, 29 Apr 2020 05:24:11 -0700 (PDT)
Received: from stubbs.int.chopps.org.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A0325610DE; Wed, 29 Apr 2020 12:24:10 +0000 (UTC)
User-agent: mu4e 1.4.1; emacs 26.3
From: Christian Hopps <chopps@chopps.org>
To: lsr@ietf.org
Cc: chopps@chopps.org
Date: Wed, 29 Apr 2020 08:24:09 -0400
Message-ID: <sa6r1w6h446.fsf@stubbs.int.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/X3Ma-9G1OXsFxFiebXr83Lz7fLM>
Subject: [Lsr] Congestion (flow) control thoughts.
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2020 12:24:21 -0000

[As WG member]

I like the start these drafts are making, I have a few thoughts.

- I think its worthwhile work and as a WG we should end up adopting a draft or drafts that try to solve the problem.
- Congestion control is hard, and a very well studied problem, as such whatever we end up should reference prior-art to justify it's claims.
- Data, whatever solution we end up with needs to have data to back up it's claims.

** draft-ginsberg-lsr-isis-flooding-scale

Having just recently offered a, "CC algorithm is local so we aren't specifying it", in some unrelated work, I discovered (correctly so) that it was not sufficient (see [*] for the resulting changes if curious). One needs to provide (doesn't need to be normative) a working algorithm to prove that the protocol is providing enough information to the transmitter to actually implement a viable CC algorithm.

Now draft-ginsberg does suggest an algorithm, however only for P2P. We need to address LAN as well. This also needs references on how this algorithm relates to existing studied work, and perhaps most importantly some data showing that it actually works.

Without this it will almost for sure not clear the IESG (in particular Transport AD review), and rightly so. :)

** draft-decraene-lsr-isis-flooding-speed-03

I read this draft as providing feedback to transmitters on ways to modify the parameters of their CC algorithm. It doesn't actually seem in conflict with draft-ginsberg (or doesn't need to be) to me. I believe it's following the path of least resistance in utilizing existing IS-IS parameters. I wonder if we could be more adventurous here.

** Both

Both drafts mention trying to increase the ACK rate. I think we need to look deeply into this, as this is critical information for CC algorithms. It very well could be that we do not need protocol changes as the protocol provides an ACK (or NACK for LANs), but I also don't think changes or additions should be verboten either if they could provide significant improvements.

In the algorithms we propose or envision we need to be considering the affect of larger RTT on the algorithm for slow or long distant links (radios, satellites, long-haul fibers, etc).

Thanks,
Chris.
[As WG member]

[*] - https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01#section-3
      https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01#appendix-B),