[Rdma-cc-interest] Minutes from the IETF-113 side meeting on 802.1 Congestion Management Initiatives

Paul Congdon <paul.congdon@tallac.com> Thu, 24 March 2022 09:51 UTC

Return-Path: <paul.congdon@tallac.com>
X-Original-To: rdma-cc-interest@ietfa.amsl.com
Delivered-To: rdma-cc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30033A173C for <rdma-cc-interest@ietfa.amsl.com>; Thu, 24 Mar 2022 02:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.092
X-Spam-Level:
X-Spam-Status: No, score=0.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URI_DOTEDU=1.997] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tallac-com.20210112.gappssmtp.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 dd4jjabZBEZ7 for <rdma-cc-interest@ietfa.amsl.com>; Thu, 24 Mar 2022 02:51:46 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 33ACD3A1701 for <rdma-cc-interest@ietf.org>; Thu, 24 Mar 2022 02:51:46 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id p22so4762233iod.2 for <rdma-cc-interest@ietf.org>; Thu, 24 Mar 2022 02:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tallac-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=GtzSCNEp25As+2rowhiZv+7I3cgrWU4FCBcxNP3/fqk=; b=25KFm8p6zDKELV/w6wgK/wtyuTr2YZxaugj9DOOSBHtRFc3P4pAPtZVBlzpEG4gt+P mYvw2JnmflNUnfyLVDxEuHAOsuQWZEe0NR29GJl6z55SUxPxUuo0DmJDYZEnOUFDHD1h Wm9/TFOGZdjijX+ck9d7ZGm9QLdQMb5coFUnxjN4762KiOA2zkcaCzQABdcoiDZ1i3Tp LRDmnfFs8kpKIpnT1OrFVL/ALafo13BVmW0aVkZXcl6GKEALYmLycnuIPKitIf2tiBgd 5IjnvALSogjTPb5zbi6x7kUgJY8kC65365mGvWFDzfEXc3/G5wKrEaQhT6gtlZE31oTK 8c6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=GtzSCNEp25As+2rowhiZv+7I3cgrWU4FCBcxNP3/fqk=; b=tG4CbwXZ9AsEnjrfAOd94HeVov3YyajhtuA855Yvpe2GbXr2OdHGKcClv8v2gQ7wVp OBrbrktMk4LiEfBFeEZLoU23qXHFDlgTlI7kCVxlRdSA+t4aaEjhjo9EdRH6Aa7EQF2t Y6jGAkdLnwAAt7Wxy86lkP/3pf+AdH+4wEewlg8gKSoLcsl95ojRF3iKY5hySJiv6hMM VXkftYYpIpbC8HfYLiBXPNPbO8v8sRQEsCTQMU3O3gHZsb4issrnKQVyNBLXRPgq7hcq MWKJDP00Us2Av5VKhLchK+jdcrSoQNtSHdS1bYz1c+eG3OyzYCee4CYPFLLKsWDFxW8/ kuFw==
X-Gm-Message-State: AOAM530N8ZGr4oqby7t4irsPfY0UH6o6Ff0XCsLRqaVaBfH5PWNnVhWi sIdRJo4/Fg9G+v2X2SEnRkj3GItVtOG5GyFsJIEqhir6xdIn5C+h7BM=
X-Google-Smtp-Source: ABdhPJzyryRVRJT5TU/EljqfhNnLZ7BTfUo3T6QAoXLOLi8POeMpAmauU3DQ59ETD4Z2rRdWB89aFhRwf8GQwxBjisM=
X-Received: by 2002:a5d:84c1:0:b0:649:f07e:9c9c with SMTP id z1-20020a5d84c1000000b00649f07e9c9cmr1469223ior.33.1648115504696; Thu, 24 Mar 2022 02:51:44 -0700 (PDT)
MIME-Version: 1.0
From: Paul Congdon <paul.congdon@tallac.com>
Date: Thu, 24 Mar 2022 02:51:33 -0700
Message-ID: <CAAMqZPs1ZQ1rZ2S4fOsPqyDyNin_PvLOX0BpyZ6tJNJ_H2Kp9A@mail.gmail.com>
To: rdma-cc-interest@ietf.org
Cc: Paul Congdon <paul.congdon@tallac.com>
Content-Type: multipart/alternative; boundary="00000000000034e0e705daf3cbb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rdma-cc-interest/HByIMAY2A2WLSx6kijxP33M7VUc>
Subject: [Rdma-cc-interest] Minutes from the IETF-113 side meeting on 802.1 Congestion Management Initiatives
X-BeenThere: rdma-cc-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Congestion Control for Large Scale HPC/RDMA Data Centers <rdma-cc-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rdma-cc-interest>, <mailto:rdma-cc-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rdma-cc-interest/>
List-Post: <mailto:rdma-cc-interest@ietf.org>
List-Help: <mailto:rdma-cc-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rdma-cc-interest>, <mailto:rdma-cc-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2022 09:51:59 -0000

Here are the minutes from the side meeting on March 23, 2022 - at 10AM in
Vienna.  Please send corrections or comments to the mailing list.

Thanks for your participation,
Paul

1.       Attendees:

a.       Paul Congdon, Tallac Networks, Huawei

b.       Richard Scheffenegger, NetApp

c.       Hirochika Asai, Preferred Networks / WIDE Project

d.       Stein Gjessing, University of Oslo

e.       Michael Welzl, University of Oslo

f.        José Duato  (online)

g.       V. Michael Boyle (GOV) (online)

h.       Lily  Lv (来宾) (Guest) (online)

i.         Tianran (来宾) (Guest) (online)

j.         Haibo Wang (来宾) (Guest) (online)

k.       huafeng wen (来宾) (Guest) (online)

l.         Dmitry Afanasiev (Guest) (online)

m.     Marco Liebsch (NEC) (Guest) (online)


2.       Paul Congdon presented the background slide material.  The slides
may be obtained from:
https://www.ieee802.org/1/files/public/docs2022/new-congdon-IETF-113-sidemeeting-0322-v01.pdf
.


3.       Jose Duato noted that calculating headroom on a per-traffic class
basis must be done assuming the worst case, that is, packets are in flight
for only a single traffic class at a time.  In reality, packets on the wire
may be from multiple traffic classes and thus we could be overestimating
the needed headroom.  This is traffic pattern dependent and can’t be
predicted, so a worst case needs to be assumed.  Jose mentioned some
implementations could have a shared buffer for ingress that acts like a
“landing pad” for packets before being marshalled out to the intended
traffic class.  Only this ‘landing pad’ would require implementing
headroom, independent of traffic class.


4.       Richard Scheffenegger pointed out that the traditional end-to-end
congestion control loop is too slow for these types of data center networks.


5.       Richard voiced concerns that SFC may have some challenges during
standardization.  There may be hidden complexities.  Jose spoke in favor of
SFC speeding up backpressure (i.e., backward propagation of flow control)
and the fact that individual flow information is contained in the signaling
message could be helpful to stop only the congesting flows, thus avoiding
head of line blocking.  Jose voiced that SFC is a good idea, but it’s
better to be combined with accurate congestion detection mechanism.
Inaccurate congestion detection may worse the performance. Prof. Duato is
doing research on congestion detection mechanisms and believes this can
help.


6.        Jose noted that Clos network topology may not be the most
cost-effective design as the network scales in size.  A consideration of
Dragonfly topologies may be more cost-effective for actual datacenter
traffic, but could involve other changes to deadlock avoidance and
congestion management.


7.       Hirochika mentioned that issues associated to overlay networks and
SFC should be discussed in the IETF.


8.       Michael Welzl voiced a concern about reactive congestion control
algorithms in general.  He wondered if in-band telemetry schemes, such as
HPCC+, are practical to implement and for deployments – perhaps their
implementation cost on NICs could be problematic?  He also asked if
‘shadow’ queue approaches are practical and more cost effective to
implement?  Michael references a paper from Nick McKeown related to
congestion control that is relevant. See:
http://yuba.stanford.edu/~nickm/papers/p230-cronkite-ratcliff.pdf

Meeting adjourned at 11:35AM