Re: [Rdma-cc-interest] Minutes of the side meeting at IETF-106

Lars Eggert <> Wed, 04 December 2019 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 200741200EC for <>; Tue, 3 Dec 2019 22:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o0vzNf0yJ78H for <>; Tue, 3 Dec 2019 22:37:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A4D912008C for <>; Tue, 3 Dec 2019 22:37:38 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 8EB88B0093; Wed, 4 Dec 2019 08:37:35 +0200 (EET)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1A76561BDA3; Wed, 4 Dec 2019 08:37:26 +0200 (EET)
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_10C2BCD6-6C75-4E37-857B-D0A26572C506"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 4 Dec 2019 08:37:25 +0200
In-Reply-To: <>
To: Paul Congdon <>
References: <>
X-MailScanner-ID: 1A76561BDA3.A6663
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Rdma-cc-interest] Minutes of the side meeting at IETF-106
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Congestion Control for Large Scale HPC/RDMA Data Centers <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Dec 2019 06:37:40 -0000


On 2019-12-3, at 21:55, Paul Congdon <> wrote:
> e.    Jake Holland wanted to understand why ICMP source quench is a problem.  Is it simply the presence of tunnels?  It wasn’t clear what the other problems were at the time of the meeting, but this should be investigated.

It can't be authenticated, i.e., it's trivial to spoof. In other words, any node can quench any other node.

> d.    Roberto Peon stated that shifting decision making to places in the network where measurements can be made on very short time scales will be important in the data center.  The longer the delay for a control loop, the smaller the impact that offloads will have.


> 9.    Paul Congdon took the final minutes to ask people how to proceed within the IETF.  David Black felt the side meeting approach appears to be working and suggested to continue.


>  Paul pointed out that, while it is great that IETF is making the time available for side meetings, there is a challenge assuring a time is available to meet that doesn’t conflict and can draw critical attendees.   The meetings are not being recorded and there isn’t a place to upload the contributions.  This would be an improvement that IETF could make to the process.

Any organizer of a side meeting can minute the meeting (as you did here) and make materials available, e.g., on GitHub.