Re: [Lsr] Congestion (flow) control thoughts.

tony.li@tony.li Wed, 06 May 2020 16:02 UTC

Return-Path: <tony1athome@gmail.com>
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 B334D3A0B69 for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 09:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 f9W-K9gwUFWh for <lsr@ietfa.amsl.com>; Wed, 6 May 2020 09:02:08 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE3A3A080B for <lsr@ietf.org>; Wed, 6 May 2020 09:02:08 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id x10so663288plr.4 for <lsr@ietf.org>; Wed, 06 May 2020 09:02:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vDK8qq2+uCZesl+Sm11ytX7NqsvYtkIgJkDUVBMtYtk=; b=iOjlk5KGNCgfvx0Nu14kSTZf8InhkmocYNjF26LToLLpXv/odpOePNTI+BbFtlXUsQ zdkv4vvFUSgAmptv/rHl7yGKnWfqvPoDF0d7pK+SBtY3TqJ6eiNBk4mSKWQ2HouBqitc y5kumSTLImX+aQZdQN5F/KrcEg+lSY4G4zeiwns8w1fX4oFCsg40NN8I4Gdd+UkHWREy tbrA/Y42sYWw361cxEF6S515ZC0/OSHGeFgLmMxUcDi6Y+qRGQVjwGuH0ac8UMYgjp8V /MrJi99/2PFQBEgv9XrSLuExesLy3fJ6RyNl/ZQgPqtSUyHdJYt7d7ewYBQApvOTEx9H UYhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=vDK8qq2+uCZesl+Sm11ytX7NqsvYtkIgJkDUVBMtYtk=; b=ClK596Pv/RkiyVBaZV7JAaVPhOMyy0fFnLZcqqdwKCfqyB/Cwt1BfW2+vOgcl7Bt2w Cp3ljai42kq9jTsnE4TdxowI7TDhtGWsqwduAu8tnU6Y6im01oEIWoRTqlrmy1KD68Fi DZ9Fx8+ypDSMdO1EWRfwld+/JB9ILKAac36noAs2bl2IPbecwg6OOWS8MxyUJgdRWS/9 j9+TtXsTO+yd2mVuqtVzcJy3DjFLdw2RttJlPUvRuBE2xZDa0wFaXP8h/sUvt+g0q3v6 acIwhE16okfGF0d0oS9lnZmWtrQZcGfhJZaMoEc3OT8HjCEbpUq2RVVAATqkM11bw1t7 MjDg==
X-Gm-Message-State: AGi0PuaUBXHG94U/MBncyIKT6QLQ1MKi1d1Xc513Mft/xn/AIEiftxgk PZdZnnoO5gxKPJFhNc6k87Q=
X-Google-Smtp-Source: APiQypIlkXFSnqmE+tx7aCIaCw19QGAGIhhdq8lbNcLlD5E7aAigM6dQTtQkaGv4vWkRxWtec2jexQ==
X-Received: by 2002:a17:90a:a00a:: with SMTP id q10mr9878589pjp.103.1588780927725; Wed, 06 May 2020 09:02:07 -0700 (PDT)
Received: from [10.95.83.218] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id nu10sm5666314pjb.9.2020.05.06.09.02.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 09:02:06 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: tony.li@tony.li
In-Reply-To: <21e4996c370b475db4eb4e7ffc298434@huawei.com>
Date: Wed, 6 May 2020 09:02:02 -0700
Cc: "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <364EDB68-ABA4-4AA9-910E-065A15DB0965@tony.li>
References: <sa6r1w6h446.fsf@stubbs.int.chopps.org> <8016231f9ff94bd2b0f5ef989608922f@huawei.com> <DD8160ED-5131-40D3-AA12-D4810C26B9BA@tony.li> <21e4996c370b475db4eb4e7ffc298434@huawei.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_tevhbdNwTpDsCyrFspRyTRw_Ns>
Subject: Re: [Lsr] Congestion (flow) control thoughts.
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: Wed, 06 May 2020 16:02:10 -0000

Hi Xuesong,

> <Xuesong> I think there is no need to distinguish the concept of flow control and congestion control, considering that the core idea is the same: monitor the sending rate to match the capability of the bottleneck, no matter there are competitors or not. And the control loop is necessary in both case. 


This matches my perspective.


> <Xuesong> Thank you for explaining about the bottleneck of flooding and different cc solutions that are under discussion. It is helpful and I will read the drafts. 
> There is still one more question left in the previous email: " What is the criteria of comparing different solutions?". I think this is crucial for further discussion and comparative tests. I notice that in Bruno's data, some parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP delay", "retransmission time". I'm wondering whether it is able to choose a better solution through these parameters. If not, what should be added or considered. (Some other issues are also considered when choosing cc mechanism in layer 4, such as: fairness among flows, co-existence with other cc mechanism .. )


Sorry for missing the question. The criteria are, I think, quite clear: minimize overall flooding time.  As Bruno’s figures show, that does NOT happen simply by transmitting at the maximum rate. That causes overruns, resulting in retransmissions and that ends up being quite slow (tho we can work on that too). The question then is: what control mechanisms do we put in place to ensure minimal flooding time? This needs to interoperate across the full spectrum of implementations: fast brand X needs to not overrun slow brand Y while performing well with fast brand Z.

The floor is very much open.

Tony