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

Mitchell Erblich <erblichs@earthlink.net> Mon, 04 May 2020 07:28 UTC

Return-Path: <erblichs@earthlink.net>
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 1DEA93A0D1D for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 00:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=earthlink.net; domainkeys=pass (2048-bit key) header.from=erblichs@earthlink.net header.d=earthlink.net
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 cnr3aPc6o9b1 for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 00:28:48 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (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 88F663A0D1B for <lsr@ietf.org>; Mon, 4 May 2020 00:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1588577328; bh=GdaafkXE2ZY0/lnhkYY+A6K6XJaG6HVBI0Vb PlJtZ8I=; h=Received:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; b=NScwiYSrUb YndRCL99x6GCqqIlCpaEwjA3tYoBxPz99umqFw7zFlUsw5gpdIRyVwIn3gkDLeMfRIQ 8sMsNLM+ImgBUWm63EvDaPFszC9Y79pB9gF0VBUd2eNogagHQgTR+ZEsjbnVlEfcyKg pXZ7ldOkEOtgf7vkjTWPTtn70Iupkjs+6QKonwZiof9AQ7Sla6fqwMCzxf2+MBhJToT usOsC/KO9c/nAKzGKmzy+CtRkTX5y8VgrWJfEMVb6UUS4BXh3I6p+xfqNUzai3eZ8PT omYPWiNiRiZYIrYbyv/PXoq6D6sD5uOiHqNHXvFElwfQUnTc/xiQv8WAIXlgIC8g==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=p1NJiNdr8eqK/3uvFChvtEnS9v5+grPtQYADOUjWB6Lq5X+jyInHIg8LwsYo7AQFd541YGYeFY2fyNA0Ua23Lk59AAztP6lwuiPKZY60+7Rstqi++TR/ojdTDA7gwgBfIVEWnF3bQfxr5TDORuXFVmInWFkdZKO/1x/3Oxj4K8z151KhlVAUyWJgiOsiY1YMwNZB7pjm8B0SVXyURbe33Ikg/JLa2DZovzO6znKOUHuOwY5b/fr3f0KG0XKsdfwAME7NSU/xCgR+tli3KuMKYBjIgsTvLaBucnvepezmtBLeMkv4x8B0CbdZUtozC1P8UXOog22dqVZbtrcxUBDRCw==; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [98.234.227.202] (helo=[10.0.0.53]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4) (envelope-from <erblichs@earthlink.net>) id 1jVVWs-000BuO-Dd; Mon, 04 May 2020 03:28:42 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mitchell Erblich <erblichs@earthlink.net>
In-Reply-To: <D6C211CF-FD4F-44FF-B3AC-B2DE4FBFED08@tony.li>
Date: Mon, 4 May 2020 00:28:40 -0700
Cc: Henk Smit <henk.ietf@xs4all.nl>, lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: tony.li@tony.li
X-Mailer: Apple Mail (2.3124)
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79ddaad2ca984b3341495915a2f5da78ac350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 98.234.227.202
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/H8LYvoEQAQiEcv6LKeWkbjCKm1U>
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 07:28:50 -0000

Inline…

Mitchell Erblich
Implementation of IS-IS for Extreme Networks in what seems Eons ago…
erblichs@earthlink.net



> On May 3, 2020, at 11:12 PM, tony.li@tony.li wrote:
> 
> 
> 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.

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

> 
> 
>> 			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.

	Sorry, I disagree ,, Link capacity is always an issue.. wrt to video we now have 4k/8.3mpixels video streams with 8k support at the TV in the near future. And as you mentioned 400Gb via Link Aggregation… Whether a single or multiple 1 core, 4core or more is used and the speed of the Eth interface(s) is based on the platform. I would assume that hello 2 level neighbors / adjacencies would be more WAN based and thus stresses a router’s link capacity more than a standard neighbors via hello 1s… 

		Even more grey scale or the number of different colors of pixels require more link capacity…

		Pixelation on your TV is based on either link capacity or not being able to process the packets, and thus either get dropped or just skipped.

		Even compression consumes CPU processing a requires an “entire frame” / partial frame to be recieved before the frame can be processed.

		If we jump to OSPF it is the DRs and BDRs, I would assume consume more link capacity, than DRothers (note; does not use TCP). 

		So, link capacity and/or packet-per-sec processing Will always be an issue in some/many environments, and is more so with IPv4 due to fragmentation given fixed input queue/fifos sizes, and whether the router then does tail drops, or REDS (random early discards), or does delay of dropping an adjacency because it is processing a massive number of LSAs and has not processed the hello,,, Please tell me 1 router can process say 1GByte of min sized packets at wire speeds of say 400Gb/sec, via echo requests/responses… aka 1 million pings as a quick stress test..

 Even with long enough FIFOs, don’t we have longer latencies as we queue up the packets? This is a side effect of link capacity… 

	Even limiting the number of routers in a area and having slower or faster convergence, is based on link capacity and CPU capacity,,, aka the platform

> 
> Tony
>