IETF Logo Mail Archive

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

tony.li@tony.li Thu, 07 May 2020 15:28 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 3738F3A09CC for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 08:28:14 -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 TPE2kQqM0Ohn for <lsr@ietfa.amsl.com>; Thu, 7 May 2020 08:28:11 -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 C4CC43A0815 for <lsr@ietf.org>; Thu, 7 May 2020 08:28:11 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id b8so2056473plm.11 for <lsr@ietf.org>; Thu, 07 May 2020 08:28:11 -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=zLkXn4YXDIDmG+CmGtpDV6II0AUUAm72YMFeFLn5810=; b=g8lFra0sq7/AWL/quL+BSOWWkhV6tHj+n38r5PyLPdvHjdOzmRwMbJOwLRptouCfcR b73kT8tP+sWF7tv7XpneJfmzlMkCQs131//OFK+yNFIffREFjaoJ4il/owaiQISQ4Y+I ayz85BVqY6i8omM0kC0JTDIDpNAxfuMLN4vsPVm0+/Hp6oFettW/Gk82HV96g45XP/GK d/YjkS+8/xDw8P40JZSFXhbCYHHS9jkN7KmyNo+9iKesjZcoFRKnLp3jiYqgdNRlsHO2 jmF+MUYONmH52gdjO7qnumTCPMhkMsRQ/tTYB2hm8TU93opSl6710ohWPEzfSp1eWuon lRFA==
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=zLkXn4YXDIDmG+CmGtpDV6II0AUUAm72YMFeFLn5810=; b=Rm5Vy3Jq57MdPJsrpmB+dV+YoG00qpZ/uqFegtPqkQFBnBEExImN7G8hlAPr8I4jqt bUjByzXmNRDC60hjPXxQwHpx+rqUPEAHHz1SHAUJiBwKSnuXOuqUIsY2eiVEqaL/xIUv qIO4snL3WXLIOty98un/Y1eIzTOud1Kwr7nfuHGU5TL/5msJpz+8kZR4FNNih6DxA3ak 7pCdU8jvPu5RovNslf5f8UyZMdd5DG4zL26feOe4srQg58KxVFkcNBOt1jCadeo/14eJ oqStaXP3dyO1pLpFODKLcn/eJcEFE9kD80a8byXeti0PVI6pgmfFkZLeHunGrc7IqWYJ WIXw==
X-Gm-Message-State: AGi0PuanZq3g6O5l7uQvQfzDFqaSDpXEjMMEnn4hyeKXlxfoGCOrLPA9 K13YrG/uZTwJrItqGpyTwJf1W8gr
X-Google-Smtp-Source: APiQypK0J2dDi0BU/x7QW5LSCUo0OGQ2+Ku9MZy9pEFMKyB+IQhbK46uDviIZmcJPUDQWIeIhZqY0Q==
X-Received: by 2002:a17:90a:558a:: with SMTP id c10mr639286pji.53.1588865291111; Thu, 07 May 2020 08:28:11 -0700 (PDT)
Received: from [10.95.84.23] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id 10sm5178465pfn.204.2020.05.07.08.28.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 08:28:10 -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: <f62a652c6b6a489faef754697670aaa0@huawei.com>
Date: Thu, 07 May 2020 08:28:08 -0700
Cc: "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B3A2CF5-559C-4C49-93FD-9FE116D049DE@tony.li>
References: <sa6r1w6h446.fsf@stubbs.int.chopps.org> <8016231f9ff94bd2b0f5ef989608922f@huawei.com> <DD8160ED-5131-40D3-AA12-D4810C26B9BA@tony.li> <21e4996c370b475db4eb4e7ffc298434@huawei.com> <364EDB68-ABA4-4AA9-910E-065A15DB0965@tony.li> <f62a652c6b6a489faef754697670aaa0@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/lskIRI30mIwmIo7vTEO6pj5XQNY>
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: Thu, 07 May 2020 15:28:14 -0000

Hi Xuesong,

> I agree that "minimal flooding time " is a good choice, which may differ from the traditional cc in layer 4, which is difficult to get the completion time for each flow.
> I am still a little confused about " fast brand X needs to not overrun slow brand Y while performing well with fast brand Z". Is this talking about interoperation between different company device, which may use different type of cc mechanism?


Yes, I’m talking about interoperability. 

Normally, in this working group, interoperability implies that each implementation is sending and receiving correctly formatted packets and computing correctly. This particular item adds in one other degree of complexity: timeliness. An implementation must be able to go fast or slow, depending on the needs of the receiver.

Tony

v2.23.0 | Report a Bug | By Email