Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

tony.li@tony.li Mon, 04 May 2020 06:12 UTC

Return-Path: <tony1athome@gmail.com>
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 B1C463A0CCC for <lsr@ietfa.amsl.com>; Sun, 3 May 2020 23:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0ecRoHi4dtJB for <lsr@ietfa.amsl.com>; Sun, 3 May 2020 23:12:12 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C73C3A0CC9 for <lsr@ietf.org>; Sun, 3 May 2020 23:12:12 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id x77so5061614pfc.0 for <lsr@ietf.org>; Sun, 03 May 2020 23:12:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Dp4q8UvSXlAyceRCWoAxmPTArm7CJ+ERvp+1Pb7eMu0=; b=m5Nyx/EjhcnUFaB52Oy0zEIxGS0yF/mcTResP8nbcvUtlB+NU/5QPxugv3B/2t8iGa 7gOELyi6HochhbdYlZOtW97mslxIa58KAVCWgshDv4ZlHBJnJEsmNHYHYl3nf8ae+Aw5 KBu1aHxgIU+A8up4UewJOmexQ8Dx9HhlyG4FqCVT4Yr9au2GP/43L3yD76tAruf+14w4 9gM58rCBFOLG/6wuYsGqzfIHRTvNiFK5r4Ud0ZQTqLQ4f/KBlD6wWR/dBYYw+A6PeB+N 40RdVFLkol11d2DVVy9aXJfAppxB/V8pvUR3DAeQ8/oIYjnZfzncacGu2gxwZ1aZN6dC LDdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Dp4q8UvSXlAyceRCWoAxmPTArm7CJ+ERvp+1Pb7eMu0=; b=a0a27+8ZbgwDvOwp8kqZ1VqIa7Ulc+SYV2Bq/MwtaHXJxcGIZQGCtVpFmxdBgYJXWq KKw2Maiw0bxfAgStsIRki9cIkNTTclaNN4CZ8qxBAo7sQ9+tl6wOhXnTH4xq0AOKfXQC sDrzm9l50RmvDZ1QtxDe9UayD49pSEaLayNPTNd0vWrJdVJfqDPTYiMhVP3yHAR5D1t7 TbKuqX0+ZeNC1QYL5PcIFFRV0wYk/7ONb291HKMMNAAVjkwyCZlE5r1mSIIfgMbvDYh/ XVq9Q0A24yYu/if99uGfkfFf1lDhTgb5tKaxkrJ7X/EgQPOJn9oUGwUogg0IP07v4QBC iXiA==
X-Gm-Message-State: AGi0PuZ7AjNaN7Wc25ZEa3o7z6OPQR0fM5VmC1WEGETb0eRPlIzh9gdz 0kl4jyO9SkcmVdT6npFFkUk=
X-Google-Smtp-Source: APiQypIZzE9p66jgagYN+rwgqyBAZu82EjBN0XgMuWFwAMgFIC6OUpNEsVvsV3j2L4kzk9RqneSBhQ==
X-Received: by 2002:a62:9211:: with SMTP id o17mr16061221pfd.234.1588572731625; Sun, 03 May 2020 23:12:11 -0700 (PDT)
Received: from [10.95.81.189] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id y63sm8079609pfg.138.2020.05.03.23.12.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2020 23:12:10 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: tony.li@tony.li
In-Reply-To: <9EFBCFAD-1CD6-4E58-895E-11C48654C1A2@earthlink.net>
Date: Sun, 3 May 2020 23:12:08 -0700
Cc: Henk Smit <henk.ietf@xs4all.nl>, lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6C211CF-FD4F-44FF-B3AC-B2DE4FBFED08@tony.li>
References: <07927ff234a0eb40738e63c36a356df5@xs4all.nl> <9EFBCFAD-1CD6-4E58-895E-11C48654C1A2@earthlink.net>
To: Mitchell Erblich <erblichs@earthlink.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5HtBL3cgbjBOQMF2cpLwmDd6dEU>
Subject: Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough
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: Mon, 04 May 2020 06:12:14 -0000

Mitchell,

> 			I think we/you are looking at two different problems: 1) a hop count of 1 or maybe two between the two end points 2) and the multiple / many hop count between the two end points.


IS-IS adjacencies are always between immediate L3 neighbors, ignoring strange things like tunneling.


> 			Thus, I think that your issue is mostly the #2 problem and the problem that most CA algorithms IMO always try to increase capacity and thus at some point must exceed capacity. TCP must find a range of capacity per flow (assuming a consistent a number of packets per sec). However, what is maybe missed (I missed it in the document) is the ability not to overshoot the TCP threshold point and trigger multiple initial congestion events in/exiting the slow-start phase.


Modern router designs have interface bandwidths from 10-400Gb/s.  The CPU would be hard pressed to supply 1Gb/s, therefore for most of the circumstances that we’re concerned about, the link capacity is never the issue.

Tony