Re: [nwcrg] nwcrg @ ietf106 minutes

"" <> Tue, 26 November 2019 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 048A312081B for <>; Tue, 26 Nov 2019 00:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f_KPa_ZKm8b8 for <>; Tue, 26 Nov 2019 00:24:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9409A12003F for <>; Tue, 26 Nov 2019 00:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1574756675; bh=OKZdYqaajiWhRddm0ridecxq/g98a7f5sSDrAiCYTMk=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=auSy+kspv4FsPCfjawkdYVzUAzE8oc7ohzXnrlM5bttrBMShpc2sx/1Rib1+SZGVjWcB6MJfAs7ibuZraLvPiexqBo7LVk8X1TNX1c3oHL6W+U3ubS1CaVcNx94kTXvLhgmOYNIvkg8uGQo0+yt7lD4eIRS1BaXwWI1Hrszc/5fnaOBF9iQfjnbAUAPuVXI4uA4qTkS18gCHPcMVxWXd4uN3tV8k8ueWCy0CW4HqidSseIQeNckyeDmjwXkue8DXSYIbcbMM966lAahfsffKik2hymsaxXHcWxf885ZmGPXLTpGkTzOWysAOG17JCNzR9JX6uRBnXlW7lVv9nq1jlQ==
X-YMail-OSG: A1iTA8MVM1mlJF8s1eyk7SqZyk5jDcCV9XE1GYNZ_CRyuERNcbk63LwCZY8P8kp s6iuzm5KUkLMcBhHjcjyZO.Mk5gsvKVnU1HA4PPrOapGGWHtYm_qFfDv8gy7F6962NaL7gVHvzy1 bAFKtZLCaVvC0CYXF1DBoi9hG7E3mDMmdm.R3A80bPtCnPF2MLneCCfUYC_nL4q1GupJJOKA9tR1 pD_xBRnT7_v8Fu13phCTnvCu_PCV4WU7Xa27xQAumqAjQynXXfNMSU0jyj3Y4xrBAvqBKAfRL729 YflU.RNb8rYlA4zcivaBFOs9dfO12_3zz3.L9uuA.FdbPdhR1u8KP_Ql9KFIdSFMgGAVFugC64Ay D0KlxGWkNw0D_L8HXgiHAt.f5Txh6ZP72P0ZS_tlpH24z0w_6q7Qip9_PwWK1oFCI.Zpmac2C2uu HmyZp_JrFtIMHSam8cD6AbPsbHU2tgDWA9eN9nUnpa157A0gQt7UKKX6okwInjkVexghk1oYznAh x_FPh3zaEkuUcA28y6m82BWSMnfqPjLkI2VJ40Q3kf61P8IAxzU8RY.TcWCGVpkhK6B._6tUN4eB NCIxHkLW0JYv050vAkByVJpNT1wZyaw5UjECRZWFQGfbpDhWZwatWU1bhAf2isOt7.O4bdWjmvH6 5ao9OLGCmvBfN.2X5Shw_eAU5ZvtMvepjI2h56Th6cTbSzG0H9RqsKXb.6f65eSPGGdVEeaoAdiu gr_QV956S4j5QWJww6YNSMDNLFwYWNX3b83_A.cOnEe3_Mc6OX_53O61iIZXcwKpEJtuZVeba2EO 4bvxCx.UtlwMHSKGl_2LQIHnkgzKZb6HOpyWhWe7ir38gqiKmW7iflpUn5INeOAN51lpAckxKROI yfnR2ygs1L3r6bN61TvaMGqSD0sOFZvWkymKNZTyq5o6OVqJ7.aDAt3o78bHiJGRxqddvQPJGimM QYOW27K8XZ8nw1mD33BEGirzlqiKq5FnA95WurWslQp_NobfnpXyOHPK73MkHCe1E6tcCQ1PbZIl cdx6uhuRnZNefx8bwgGY1bY_beDv2muWk10nABdJreGGZ.wMkSMJIcvjxMp4IAjZlwiHX0Kn2yJY Hfvx9aA2kzipF.WRckTpcHcA2q9lpOa0RLSV.4j8TofLmlDwrVezDzi4IUE3IXBc6XBb_0baJc22 LuObNuJynqEy5awFSQsihMQjDweG8Pb4iRjA7PxYjxstskgJVYwIuPYr0aGzLmSVhvnOmkERQ0Op SWKhWrEwceEGsTFdyM42zBuFMc3F5CspimvBC4_RFAEEW_ynsyXb4TQE4XngV8myM9tAd7sSim_. on2lsM16sX96nkWyMn3o2SkYtf3pJ9Ll53pH3PENoJA--
Received: from by with HTTP; Tue, 26 Nov 2019 08:24:35 +0000
Date: Tue, 26 Nov 2019 08:24:29 +0000 (UTC)
From: "" <>
To: Vincent Roca <>,, Marie-Jose Montpetit <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_95437_291367334.1574756669190"
X-Mailer: WebService/1.1.14728 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Archived-At: <>
Subject: Re: [nwcrg] nwcrg @ ietf106 minutes
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, 26 Nov 2019 08:24:43 -0000

Hi Marie-Jose,

Adding a glossary? That's... puzzling.

If you care to look, you will see that there is alreadya glossary in section 6 of the draft, which is listedclearly in the contents. That glossary hasbeen present in the draft in one form or anothersince Kuhn's original -00.

My comments below are on that latest version of the draft,which I read (again). Doing so before commenting is a basiccourtesy to the authors, I'd think. (I presume latestis still as submitted before IETF cutoff dates, and not some 
go-do-a-github-repository-pull-for-HEAD thing.)

I am saying that some discussion of DVB's FECFRAMEis appropriate, since it's a major component of DVB-S,and the draft calls on DVB-S(2|2X) a lot.
The rationale for simply ignoring it and the presence ofcoding for link conditions in favour of networkcoding shows the weakness of the network coding argument,to my mind. The name overlap with the IETF FECFRAME seemslike an excuse -- because there is already a glossarywhich can help avoid the 'confusion' that is claimed.

Similarly, a larger acknowledgment, at least,that the 'other' FEC exists would be appropriate forsetting context - even though it is dismissed as outof scope. I'd entertain the argument that network codingand link coding can be complementary, depending onconditions and use cases (rather like the ARQ/FEC tradeoffwe discussed in RFC3366 with discussion of hybrid strategies)-- but I'm having trouble imagining realistic applicationsover satellite where erasure coding provides clear benefits,to the point where all link coding is discarded as unneeded,as this draft seems to be implying. The complementaryargument needs more exploration and fleshing out, imo,and could become a strength of this draft.

Geo satellite conditions generally drive the path, andthe conditions are handled locally in the link/phy layerfor the satellite link. But if network coding is compelling,why should there being a well-conditioned satellite link inthe path even matter?

My take: this draft is a narrowly-scoped house of cardswhich does not hold up that well under inspection, despitethe effort being put into shoring it up - it's betterthan previous versions, but it's a difficult take tosupport as it stands. Well, that's reality for you, andreality bites.

Do give it some thought, give it a spellcheck and a closereading from others than me, then think about another'last' call. Alas, I have other demands on my time...



Lloyd Wood 

    On Tuesday, 26 November 2019, 18:37:18 GMT+11, Marie-Jose Montpetit <> wrote:  
 Hi Lloyd, a few things:
Are you recommending adding a glossary to the draft and adding a clarification of the DVB S2 vs IETF definition of FECFRAME?
As per on-list discussion: you have been the main commenter on this draft (and thanks for thatt) so maybe you could see if the latest version responds to your comments and we start from there for a next “last-call” cycle?

 Marie-José Montpetit, Ph.D.Research Affiliate, MIT Media Laboratory 

On November 26, 2019 at 1:43:02 AM, ( wrote:

> All the comments from Lloyd Wood and Vincent Roca have been answered
> (see details in github I-D repository for Lloyd’s comments).

Well, this is news to me. If something is brought up on the list,
I'd expect it to be answered on the list, as the primary place
where work is discussed. Where is this? Thanks.

> Some satellite vocabulary (satellite "payload" and "FECFRAME"
> in the satellite context) may create confusion at IETF and these
> terms have been removed.
I can see satellitepayload/packet vs frame payload causingconfusion if no context isprovided, and there is little needto refer to the satelliteplatform/payload distinction when everythingis going through thecommunications payload. However, there is aglossary in the draft where theterm and its use can be explicitlycalled out. A glossary is toclear up confusion about vocabulary;that is why it isthere.

FECFRAME is integral to DVB-Sand S2, which the draft relieson heavily. That an IETF groupchose the same name, what, adecade later is merely acoincidence. And there is a glossaryin the draft where the term andits use(s) can be explicitly calledout.

Really, discussing DVB-S withoutnot even saying why you'renot addressing the key FECFRAMEcomponent of DVB-S isinsufficient, or not clarifyingerror correction vs erasurecorrection in some detailparticularly where terminology (FEC)overlaps, is not enough in myview.

noted on the draft:

   Physical and link layers coding protection is
   usually sufficient to guarranty Quasi-Error Free, with a negligeableshould be
Physical- and link-layer codingprotection are usuallysufficient to guaranteeQuasi-Error-Free communications,with a negligible...

Please run a spellcheck beforeasking for anotherlast call.

thanks and regards

Lloyd Wood

On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca<> wrote:

Dear all,

We have uploaded the preliminary meeting minutes inthe datatracker:
Please tell us if you have comments.

NB: you will also find them in the github repositoryin IMHO a more readable format
    along with all the slidespresented:

We’d like to warmly thank Nicolas, Cédric andOumaima for taking notes.


Marie-Jose and Vincent

nwcrg mailing list