IETF Logo Mail Archive

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

Christian Hopps <chopps@chopps.org> Mon, 04 May 2020 11:26 UTC

Return-Path: <chopps@chopps.org>
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 7AAFD3A07ED for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 04:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3wXtL_lrNnhc for <lsr@ietfa.amsl.com>; Mon, 4 May 2020 04:26:32 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2A63A07EC for <lsr@ietf.org>; Mon, 4 May 2020 04:26:32 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id F21EA610BE; Mon, 4 May 2020 11:26:31 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <82fdb997da5c9f181deb3a01e90e78f8@xs4all.nl>
Date: Mon, 04 May 2020 07:26:30 -0400
Cc: Christian Hopps <chopps@chopps.org>, lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE63ECD1-ED6F-410A-8081-2C911F7DA89E@chopps.org>
References: <07927ff234a0eb40738e63c36a356df5@xs4all.nl> <22AA7F36-9EAD-4EC0-958B-2DC1A4C55DC8@chopps.org> <82fdb997da5c9f181deb3a01e90e78f8@xs4all.nl>
To: Henk Smit <henk.ietf@xs4all.nl>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/a5t5bWYLjXjoVBcZip4vYTuL5LI>
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 11:26:34 -0000


> On May 4, 2020, at 5:47 AM, Henk Smit <henk.ietf@xs4all.nl> wrote:
> 
> I'm looking forward to seeing (an outline of) your algorithm.

I'm not trying to push any particular algorithm, we already have some proposals. My intention was only to suggest that we not disregard solutions too aggressively. The argument that there are too many queues in one routers implementation of a punt path, or there are so few or none that one can't tell IS-IS from other traffic early enough doesn't mean that one couldn't consider what *would* be required for a simple solution to be viable. If a simple solution is elegant enough then perhaps market forces start coming in to play and the cost to implement isn't actually that high.

In any case we already have a couple proposed semi-solutions and during the meeting it seemed to be agreed that people would write some code and collect some data at this point.

Thanks,
Chris.
[as WG member]

v2.23.0 | Report a Bug | By Email