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

Henk Smit <henk.ietf@xs4all.nl> Mon, 04 May 2020 10:05 UTC

Return-Path: <henk.ietf@xs4all.nl>
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 C28543A07FB for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 03:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xs4all.nl
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 7RCP1UnxV3Gs for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 03:05:28 -0700 (PDT)
Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 DE58A3A0786 for <lsr@ietf.org>; Mon, 4 May 2020 03:05:25 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud7.xs4all.net with ESMTPA id VXyWj6JPOtKAsVXyWjN9sb; Mon, 04 May 2020 12:05:24 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1588586724; bh=Ha4yOSL7TuGZY4fjVcguiEbpW/Cw8lhnFtMPzy0WhfY=; h=MIME-Version:Content-Type:Date:From:To:Subject:Message-ID:From: Subject; b=I/osycbO2fvn8CJ4w5YmbJqreZ/TNWfPetWKJX8bL+a4WkrSNQncheQToqFpe77aB 33iuwqwCklIOC1y/QQm32TMGH4G6+ha0f7FwgFl99T4EKbUPaIU8MkI4+Bbi9n5vkZ TczfEs1RSfEeAZzBCway1GavDRHN5MXDcZDaugCjF+TkTpS1KoJp8sln84uXSgMoeU 0O1FeKYp0vqwcu6mNaeGayRF8uL5mZeCPitQWtkXu5CgT5zY8GSWkB7Evn+/qQ5afi hZY6aLUPZdiWEH+2hFRQWT9acBt8AXgiZJpwEsCEJA25Quur00xobP9GOsaVDwFYfE tecqV9pAe+Qig==
Received: from knint.xs4all.nl ([83.162.203.154]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 May 2020 12:05:24 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 04 May 2020 12:05:24 +0200
From: Henk Smit <henk.ietf@xs4all.nl>
To: Mitchell Erblich <erblichs@earthlink.net>
Cc: tony.li@tony.li, lsr@ietf.org
In-Reply-To: <77437CE8-E31A-425E-8D6C-930DA5E8861D@earthlink.net>
References: <07927ff234a0eb40738e63c36a356df5@xs4all.nl> <9EFBCFAD-1CD6-4E58-895E-11C48654C1A2@earthlink.net> <D6C211CF-FD4F-44FF-B3AC-B2DE4FBFED08@tony.li> <77437CE8-E31A-425E-8D6C-930DA5E8861D@earthlink.net>
Message-ID: <c5356d00e2a8cba43b4c0157846ab467@xs4all.nl>
X-Sender: henk.ietf@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfKr9tko4qHuSJXRALT7/rBdOPMdeK8GaUPgC/KaIK9DpPYdW3cIUhtrhWHIqV9MXmlMwIRo3te7c3X12PnrVR/xZcuV+dC3nacrc+gjK8E+dYMWk/0K3 Gpt0Q8dz7wI6ngPoZSFT6ykYGQYpjZQ2nrXBf7I5nselMCLa+4y0fv5H2lE8QxcJOMLe6O2+357ha2fWgluzbORWOPC/jlC5I0R759R4pfcwjkeoqlKanw18 qAhkwehzG4WjEc5NAYae4P43NpsYI2t1FZiaHTt/Jy0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/bMMO8vQyhJHZ8ZdNk1wGXVXPs8s>
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 10:05:36 -0000

Mitchel wrote:
> IS-IS has two levels of neighbors via hello level 1s (LSAs) and hello
> level  2s :, so immediate is somewhat relative..

As Tony said, Level-2 neighbors are still directly adjacent.
There might be layer-2 switches between them.
But there are never layer-3 routers between 2 adjacent level-2 
neighbors.

Les's point is that interfaces, linecards, and the interface
between the data-plane and the control-plane can all be seen
as points between 2 ISIS instances/process on two different
routers, where ISIS messages might be dropped. And that
therefor you need congestion-control (in stead of, or added
to) receiver-side flow-control.

> Sorry, I disagree, Link capacity is always an issue..

Note, we're not trying to find the maximum number of LSPs
we can transmit. We just want to improve the speed a bit.
 From 33 LSPs/sec today to 10k LSPs/sec or something in
that order. There's no need to send 10 million LSPs/sec.

Suppose the average LSP is 500 bytes.
Suppose a router sends 10k LSPs per second.
I think if ISISes can send 10k LSPs/sec, we've solved the problem
for 99.99% of networks.

10k LSPs is 5 000 000 bytes. Is 40 000 000 bits. Is 40 Mbps.
So a continuous stream of 10k LSPs/sec takes 40 Mbps to transmit.

For LSP-flooding, bandwidth itself is never the problem.

henk.