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

Henk Smit <henk.ietf@xs4all.nl> Mon, 04 May 2020 09:47 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 74C1B3A0762 for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 02:47:40 -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 W2tumftjhMlk for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 02:47:38 -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 2AACB3A074E for <lsr@ietf.org>; Mon, 4 May 2020 02:47:37 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud7.xs4all.net with ESMTPA id VXhGj6ASotKAsVXhGjN3zA; Mon, 04 May 2020 11:47:35 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=s1; t=1588585655; bh=FNvTGFQTeCWDUp+B0NZSuyy7BfRUbh6N+6xsnF+E8ng=; h=MIME-Version:Content-Type:Date:From:To:Subject:Message-ID:From: Subject; b=Jj5jX0Zx8nUfVdtTGtnyJOzqtUuQAOxGFGXMFap3byTXru7mA6RjBibQSTjP7DatZ E8FZbDNbat5bXPf+ko2GFdPWhbE/GwVD2opvAKpB3zWZdNz0mQp10eFBn8jE3X40So S1h3rLoJfpWOGmyIR6M/DfMm32W/JSjT7POq+4dM6NR5/E7BzlgBwW7Hd/4j1v495H wQ4k8mEi42iFvg0n9JfuMFICN5FS2jW4pYNOWLxa97BWG6M0CPq0f+xvvD5kXYRSAN HGqPB8tHlKAmmQn0MjU11zxdSoiA/JtwkWdML8zF6cKHQU+IJHg20CXr/eSisKMlCL py/Ip41/sq6Gg==
Received: from knint.xs4all.nl ([83.162.203.154]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 04 May 2020 11:47:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 04 May 2020 11:47:34 +0200
From: Henk Smit <henk.ietf@xs4all.nl>
To: Christian Hopps <chopps@chopps.org>
Cc: lsr@ietf.org
In-Reply-To: <22AA7F36-9EAD-4EC0-958B-2DC1A4C55DC8@chopps.org>
References: <07927ff234a0eb40738e63c36a356df5@xs4all.nl> <22AA7F36-9EAD-4EC0-958B-2DC1A4C55DC8@chopps.org>
Message-ID: <82fdb997da5c9f181deb3a01e90e78f8@xs4all.nl>
X-Sender: henk.ietf@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfDnjm+6mpN/usQpO2O45is8mLS7P2JBOzh63Srodg39AthJGriIaI7ZewGZYvK4KK9aJSA40NIJhWks2goDB26zCcJ2KQPZEVmv2NLOFfsYPeY63jKeV Uh+Ymkz84YWPQYdaAAJcQx25tuQzSz2gLYONBhHotPhNlJJMkllJ469TidHGouREpqnAdgIfoGfYxDigzMV5dbY6QGlhrTCs3ZAXpu75MusoYGLOZ0pSUQTC
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1YJVwmZd6ACUdnLT5Db-cjtXdxM>
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 09:47:40 -0000

On Friday I wrote:
> I still think we'll end up re-implementing a new (and weaker) TCP.

Christian Hopps wrote 2020-05-04 01:27:
> Let's not be too cynical at the start though! :)

I wasn't trying to be cynical.
Let me explain my line of reasoning two years ago.

When reading about the proposals for limiting the flooding topology
in IS-IS, I read a requirement doc. It said that the goal was to
support areas (flooding domains) of 10k routers. Or maybe even 100k
routers. My immediate thought was: "how are you gonna sync the LSDB
when a router boots up ? That takes 300 to 3000 seconds !?".

This is the problem I wanted to solve. I hadn't even thought of
routers in dense topologies that have 1k+ neighbors.


There are currently heathens that use BGP as IGP in their data-centers.
There's even a cult that is developing a new IGP on top of BGP (LSVR).
If they think BGP/BGP-LS/LSVR are good choices for an IGP, why is that ?
One reason is that people claim that BGP is more scalable. Note, when
doing "Internet-routing" with large number of prefixes, routers, or
some implementations of BGP, still sometimes need minutes, or dozens
of minutes to process and re-advetise all those prefixes. So when we
talk about minutes, why do people think BGP is so much more wonderful ?
I think it's TCP. TCP can transport lots of info quickly and 
efficiently.
And conceptually TCP is easy to understand for the user ("you write
into a socket, you read from a socket on the other box. done").

If TCP is good enough for BGP bulk-transport, it should be good
enough for IS-IS bulk-transport.

If there are issues with using TCP for routing-protocols, I'm sure
we've solved those by now (in our implementations). We can use those
same solutions/tweaks we use for BGP's TCP in ISIS's TCP. Or am I
too naive now ?

BTW, all the implementations I've worked with used regular TCP. All
the Open Source BGPs seem to be using the regular TCP in their
kernels. Can someone explain why TCP is good for BGP but not for IS-IS ?

Almost 24 years ago, I sat on a bench in Santa Cruz discussing protocols
with an engineer who had a lot more experience than I had, and still 
have.
He was designing LDP at the time (with Yakov). LDP also uses TCP.
He said "if we had to design IS-IS now, of course we'd use TCP as
transport now". I never forgot that.


The goal here is not to make IS-IS transport optimal. We don't need to
use maximum available bandwidth. I just happen to think we need the
same 2 elements that TCP has: sender-side congestion-avoidance and
receiver-side flow-control. I hope I have explained why sender-side
congestion-control in IS-IS is not enough (you don't get the feedback
you need to make it work). Les and others have tried to explain
why receiver-side flow-control is hard to implement (the receiving
IS-IS might not know about the state of its interfaces, linecards, etc).

That's why I think we need both.
And when we implement both, it'll start to look like TCP.
So why not use TCP itself ?
Or Quic ? Or another transport that's already implemented ?

> I'd note that our environment is a bit more controlled than the
> end-to-end internet environment. In IS-IS we are dealing with single
> link (logical) so very simple solutions (CTS/RTS, ethernet PAUSE)
> could be viable.

Les's argument is that it's often not so controlled.

Let me ask you one question:
In your algorithm, the receiving IS-IS will send a "pause signal" when
it is overrun. How does IS-IS know it is overrun ? The router is 
dropping
IS-IS pdu's on the interface, on the linecard, on the queue between 
linecards
and Control Plane, on the IS-IS process's input-queue. When queues are 
full,
you can't send a message up saying "we didn't have space for an IS-IS 
message,
but we're sending you this message that we've just dropped an IS-IS 
message".
How do you envision this works ?

Imho receiver-side flow-control can only send a rough upper-bound on how 
many
pdu's it can receive normally.

A solution with a "pause signal" is basically the same as a 
receiver-side
flow-control, where the receive-window is either 0 or infinite.

> Thus our choice of algorithms may well be less restricted.

I'm looking forward to seeing (an outline of) your algorithm.

Again, I'm not pushing for TCP (anymore). I'm not pushing for anything.
I'm just trying to explain the problems that I see with solutions
that are, imho, a bit too simple to really help. Maybe I'm wrong, and
the problem is simpler than I think. Experimentation would be nice.

henk.