Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room

Carsten Bormann <> Tue, 19 November 2019 04:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFB4912008A for <>; Mon, 18 Nov 2019 20:41:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKXqKiYeGQmx for <>; Mon, 18 Nov 2019 20:40:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A63712006F for <>; Mon, 18 Nov 2019 20:40:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 47HCnM5P4dzyT8; Tue, 19 Nov 2019 05:40:55 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 19 Nov 2019 12:40:52 +0800
X-Mao-Original-Outgoing-Id: 595831251.232051-4d004b256fcd4b606189b7ff0d444140
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Nov 2019 04:41:03 -0000

> A slide deck is at

Thank you for everyone who joined!
24 people signed the attendee list, but quite a few people wandered in later.

Some highlights of the discussion were:

* There was good support in the room for focusing on single retransmission implementations (which may or may not influence the actual protocol).  For enhancing path segments where that would not suffice, maybe adding FEC is the approach leading to more timely repairs.

* It is probably worth selecting a small number of example FEC schemes as something like a recommended basis for benchmarking the protocol during development.  This might include one “simple” scheme such as SMPTE 2022 style matrix parity, even if we know the areas of application will be limited.  The most powerful schemes are likely to be patent encumbered in many jurisdictions.  Some of these patents may have run out, though.  (A thought that occurs to me after the meeting:  Maybe we should procure an FEC equivalent of RFC 6090?)

* Discussing reordering at the different levels it occurs (and robustness against it may or may not be needed) may require some more attention.

* We probably need to look more closely into how QUIC reacts to congestion signals.

Please chime in if I overlooked something worthy to highlight.  In any case, I will use Yizhou’s note-taking (thank you!) and my audio recording to produce more detailed minutes after the IETF meeting has ended.

I’m CCing NWCRG as we have a short slot on their agenda on Thursday.

Grüße, Carsten