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

Henk Smit <> Mon, 04 May 2020 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C28543A07FB for <>; Mon, 4 May 2020 03:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7RCP1UnxV3Gs for <>; Mon, 4 May 2020 03:05:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE58A3A0786 for <>; Mon, 4 May 2020 03:05:25 -0700 (PDT)
Received: from ([IPv6:2001:888:0:22:194:109:20:213]) by with ESMTPA id VXyWj6JPOtKAsVXyWjN9sb; Mon, 04 May 2020 12:05:24 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ([]) by 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 <>
To: Mitchell Erblich <>
In-Reply-To: <>
References: <> <> <> <>
Message-ID: <>
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfKr9tko4qHuSJXRALT7/rBdOPMdeK8GaUPgC/KaIK9DpPYdW3cIUhtrhWHIqV9MXmlMwIRo3te7c3X12PnrVR/xZcuV+dC3nacrc+gjK8E+dYMWk/0K3 Gpt0Q8dz7wI6ngPoZSFT6ykYGQYpjZQ2nrXBf7I5nselMCLa+4y0fv5H2lE8QxcJOMLe6O2+357ha2fWgluzbORWOPC/jlC5I0R759R4pfcwjkeoqlKanw18 qAhkwehzG4WjEc5NAYae4P43NpsYI2t1FZiaHTt/Jy0=
Archived-At: <>
Subject: Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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.