Re: [Lsr] Dynamic flow control for flooding

tony.li@tony.li Wed, 24 July 2019 05:55 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 13C5212004E for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 22:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.558
X-Spam-Level:
X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 H9giRjlkUDTi for <lsr@ietfa.amsl.com>; Tue, 23 Jul 2019 22:55:57 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 4B8C912003F for <lsr@ietf.org>; Tue, 23 Jul 2019 22:55:57 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id k189so1582744pgk.13 for <lsr@ietf.org>; Tue, 23 Jul 2019 22:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+aUx1uwFwyQD5o38XOBpql+b07zLa/evV1k20fb6q2E=; b=hC4kogTYPuuXUDBJyECWOv8XiwKTV8w0z9b3dkzqOSw1B4EHBPpJXVJtTd+mgCiGi3 mWk37FxDQcLkZk21V4VpSq92FtH2oD8mOIM+0QaKbwGGBFb0GK0V8K3xH2JZ9KtOEUWt kxAgPDK27M5xouGjoCsLZS5qUdqMboda5B2ATibJsNhhbm4pOOUX23w6ZMC9LVF6ZmUK p/rYiP9mTVrcVCo8jwJjUnfLc9THowJqTvSiSp++cjOwIxGce3QKMv0CHtFzOvmpD7lZ zxV02KvX+xTDUP6s3dhzJIwnRipSUKjIquIPQgj/qS0kga9Y6LXxAIyHxgfsiZWg4F09 VSLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+aUx1uwFwyQD5o38XOBpql+b07zLa/evV1k20fb6q2E=; b=e5aFhY/7zEOXmV9bsQwNOqZszqr49xnELbbke30IKouNPVnPnMVpqzihta2tvIcKJE 0GtY/qhDl6zD71v3JC7Ynjy7LMeHmH96/vfspHlfbNL5ZnWN2s5AlArnMzSoOBCLPCan 0tWPm3/KHxC6DXdYanRoKr9RjY4pzUmY80J6z3PFbN0MmU/sJL3QnLcY3cUd/X5pMpOk mBPLRckBC/3Kaz9Aq9WrsaUUJbUHIE7FuN4YsH4FKlJkQmtbfNC89oyKHABiLG4j/gIe 2HgHaeTReMDcRTLC0hcmL8Nr+Q91OzRyS6IxsUcf/dpKTsYi7+v+sWbPLnMhyee43OUp Uviw==
X-Gm-Message-State: APjAAAWOR0p3DhoDyxoy2THaF1ISDtzZ4iRr5gmbjmZOeeTn0Ggm94xZ bY0ApGltRi/tqjMQ8W3SMjY=
X-Google-Smtp-Source: APXvYqylBoQIouq08jZj6aZHzg9VVKe2TZq6xuzuXovU0gr9fBhW/hXUoCOSiDwyyBcUhMGJHE+T3w==
X-Received: by 2002:a62:2ad3:: with SMTP id q202mr9799131pfq.161.1563947756773; Tue, 23 Jul 2019 22:55:56 -0700 (PDT)
Received: from [192.168.1.13] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id x1sm37238809pjo.4.2019.07.23.22.55.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 22:55:56 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <7D53FA6A-8072-4FC5-ABC9-5791F139C011@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D65CB2B-7911-4B2D-AFFB-93765F0CE5DF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 22:55:51 -0700
In-Reply-To: <BYAPR11MB363856BB026992DFBB3BB224C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
Cc: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "lsr@ietf.org" <lsr@ietf.org>
To: Les Ginsberg <ginsberg@cisco.com>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com> <5841_1563943794_5D37E372_5841_105_1_9E32478DFA9976438E7A22F69B08FF924D9C373E@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> <BYAPR11MB363856BB026992DFBB3BB224C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/GNtG7b4_AtDL29iZtrgGxsu4s78>
Subject: Re: [Lsr] Dynamic flow control for flooding
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, 24 Jul 2019 05:55:59 -0000

Les,

> There is something to be said for simply “flooding fast” and not worrying about flow control at all (regardless of whether TX or RX mechanisms would be used).


The only thing I would say to that is: really bad idea.

If you supersaturate the receiver, you waste transmitter in the transmission, you swamp the receiver causing packet loss, you potentially trigger the loss of IIH’s, you risk causing a cascade failure, and until we come up with a better retransmission mechanism, you probably actually delay network convergence, as nothing is going to happen until you’ve completed retransmissions.

The way to maximize goodput is NOT to transmit blindly.


> But most important to me is to recognize that flow control (however done) is not fixing anything – nor making the flooding work better. The network is compromised and flow control won’t fix it.


???? The network is not compromised.


> If you accept that, then it makes sense to look for the simplest way to do flow control and that is decidedly not from the RX side. (I expect Tony Li to disagree with that 😊– but I have already outlined why it is more complex to do it from the Rx side.)



Flow control cannot be done without involvement of the RX side.  That’s why it’s called flow _control_.  The only thing that can be done purely from the TX side is a unilateral (and pessimal) transmit rate cap that will have to allow for the worst case CPU in the worst case situation (e.g., BGP impacting the CPU).

Flow control is the creation of a control loop and that requires feedback from the receiver.  This is true in every form of true flow control: XON/XOFF, RTS/CTS, sliding window protocols, credit based fabric mechanisms, etc.  

I’ll go so far as to quote Wikipedia:

"In data communications <https://en.wikipedia.org/wiki/Data_communications>, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver. It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.”

Tony