Re: [nwcrg] nwcrg @ ietf106 minutes

"" <> Fri, 13 December 2019 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0757C120815 for <>; Thu, 12 Dec 2019 21:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, 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 niEjQ88SqApm for <>; Thu, 12 Dec 2019 21:48:50 -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 403E912026E for <>; Thu, 12 Dec 2019 21:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1576216127; bh=ccMn4X9EWV7M+nBVS6HywkNRUxWJ9BPXXGY8oNUoJQs=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=DavmZchf2n1o9Dglu852Keu05ch4eT9qaaXfODp4i9/5xwbk2g9Qg5LzohoJwM/5ieLYg+TCfqLrQZ02TInfsL0cX61GQY9Qu58iI9xKsuj2fOHNF9o/e8yCa4E3U+k1Rv99p9E+dcr/rsVyS5VHoAO6xJ1/Bf3IuMmneuEIM4t00XxhJDZcBlxLQ6L+xNWu7OlSWg+0GYR4RF6uepQlw5T2kI7LrD8qvXn9/v7uHWdP75+3X3ov8jLgf4Iq5vQ8GS8FngQnpieDKhgr7MfCj5IaK1Q+KW3CrKFdw8Q5AkobBnPBWAFkIF+W0qDmqo+GzoVOkFvVF49N7Nk0VjvMIw==
X-YMail-OSG: VET8rxsVM1l26mx94zKEBcu942MkrLioejPNtxYVpcor1rVg7Fz0cv3kHH2j7YO pIIw43_JdPObLAnaco1jWScCX04EY95hgGHESzVJtcmYw_KToArivlcWBV7RCVGYJ5dltGEm5jUi ie4OZvNGNKbJN9iLU2Vdy62q8MbGJw5vQM0qk3h7JApU0OnHKQJ.M8o8cCtwjRoyOWnvhwObL0M9 UJosR768b32WIkiDc7hhP9GFJJ2pa2lHu77vvSZeNDVPqQ232Kw7LQjgggVgbmSTZx9XDQheu9aL j58qFcvBykHaRODfYB84mLtp7x.dGAS7Bz5zNE9n5wtKETrpKgk_1qoJUCLPP_B7JqoKVaWYvIR7 wu1_FSlJZVnHt7y41wQH1AwV41jXVe6A6v5ydLsaYZ2Ys6xCba4l372hOepn173MoHkXb2DyUD84 .XGTqwTYWNns04ZJwtuNdpNQ4vzeyofshKtGFrL0fc9rAWDBH77M7CLRf9qb5GPIFk7yoTw5sD3q P2mGClaRp6TFf9uQ06i8IqEcQFPynJzuG2kxEiE2_995RLhVymvJelEiGxTfucw5ulPCGfcJilWr EvXC2jKC9zeqYzBB7ZMasQfrRdXtg_MsTmRyoyDL_muXeZ6qNz207Ph85bsAmLuFQIYeF3V7Zp6Y ITdmbbPL9Qskf.OrlFSyzrXWBk70dez67uV85WjxCXKP2jNI8GQ4JHzA5fO0gkBJkNL0Dg2V8DJ2 hJkjFTYFo6lcAIJxLSzHmV6GdzmSIeUBBnzQ_EGWzbFv8Gcii23Zb0kKJtJ9E.FDgRjrlZuXkeAt CSmapDQ_VL25AKrPjVLTYgHzxYPfFp21JVoz4Px1MkP1xlIQ1oRRpxxC1X2dkfsAeD77wmVsamNp nMEIBI8T_slq1fu4cQnA4EVg86P9m_qh4dlEeBTWxxl732yuRFseuyVxtAGhQcePspJQUjehyjI7 7g29J.YEgXf1SSFu0lQiGEh4IK3RML0O4jcIpe3GkXs.ixMMJfghTnf3NE69GBJDP7bCzJWHXkPz .nb.5y1rNvNmJOxg30pDSHXvtHWJ.LFq676WbmxH43sHPQ9vQKTSIJAUoZElnKqf8KYa5oKAO7XX XHQRG2ynX8897_2.kmkfYw2b7VqqR0tb8dcfK7heZKnuNCQW2tsgFWKeHs_i03rIhaDdU.Oo474Z MIo61SmyLvpnTUrXiI3pMSc8uuYRCwIZj_b6wbd82vIqnQXteiMKW0okdfX9IETstUno9X0jwK05 HuEPuhFPbKJlHkb15uob1tvfVzqsRVSnKhKE2PmNaCP1oRi7uSXY_ZwZfoe.x3dGoprOqqrV.NHp EusFISsWNTTh8zImtTIh0m5Ksa.J02BBe_jhO
Received: from by with HTTP; Fri, 13 Dec 2019 05:48:47 +0000
Date: Fri, 13 Dec 2019 05:48:42 +0000 (UTC)
From: "" <>
To: Kuhn Nicolas <>, "''" <>, Vincent Roca <>, "" <>, Marie-Jose Montpetit <>, Kuhn Nicolas <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_12480493_576328480.1576216122544"
X-Mailer: WebService/1.1.14728 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.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: Fri, 13 Dec 2019 05:48:53 -0000

Comments from a brief look

There is no mention of FECFRAME in the document.
I'd argue that hybrid link FEC/network coding (for multicast)could be a research challenge.

     "BBFRAME: Base-Band FRAME - satellite communication layer 2      encapsulation work as follows: (1) each layer 3 packet is
      encapsulated with a Generic Stream Encapsulation (GSE) mechanism,
      (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs
      contain information related to how they have to be modulated (4)
      BBFRAMEs are forwarded to the physical-layer;"

that's within the context of DVB-S2 - GSE is not the only method, coding
choice are not mentioned (it's modulation and coding) BBFRAMEs aren't
forwarded to the physical layer because the link layer is heavily involved
in creating a FECFRAME... this 'PLFRAME' pseudonym doesn't fly.

Lloyd Wood 

    On Wednesday, 11 December 2019, 19:31:31 GMT+11, Kuhn Nicolas <> wrote:  
Marie-José went through the document and helped us with the spelling – thank you very much!!
The posted version (*-09) includes the FECFRAME/DVB discussion as a research challenge.
Let us know if you have further comments on this version.
De : nwcrg <>De la part de Kuhn Nicolas
Envoyé : jeudi 5 décembre 2019 17:30
À : '' <>rg>; Vincent Roca <>fr>;; Marie-Jose Montpetit <>
Objet : Re: [nwcrg] nwcrg @ ietf106 minutes
Sorry for my late reply.
I will try to gather here what I think can be source of disagreement and hope we can reach a rough consensus on these points. 
On the assessment of your comments
                Even if there are multiple communication channels (github, meetings, mails), I always try to reply by email. 
                I answered to your last email at the beginning of the IETF week so that we can push an updated version before the meeting.  
                However, there was probably not a consensus on the scope of the document – see below: “all the comments” may not be covered indeed.
On the FECFRAME / DVB / discussion
                Our intent is not to ignore the FECFRAME in the DVB world. There is coding in these parts of the SATCOM systems. 
The goal of the document is to identify use-cases where coding in higher layers is relevant and is not commonly used. 
The interaction between link and network coding is indeed an interesting approach.
We propose to mention that in the research challenges.
This would let us stay from the network layer and above in the document.
Ø Would you agree with that approach ?
On the spellcheck
                I am not a native speaker and am sorry for that.
                We will do our best for the next versions of the document.
In the meantime, we are working on version 09 of the document.
Kind regards,
De : nwcrg <>De la part de
Envoyé : mardi 26 novembre 2019 09:24
À : Vincent Roca <>;; Marie-Jose Montpetit <>
Objet : Re: [nwcrg] nwcrg @ ietf106 minutes
Hi Marie-Jose,
Adding a glossary? That's... puzzling.
If you care to look, you will see that there is already
a glossary in section 6 of the draft, which is listed
clearly in the contents. That glossary has
been present in the draft in one form or another
since 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 basic
courtesy to the authors, I'd think. (I presume latest
is 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 FECFRAME
is 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 of
coding for link conditions in favour of network
coding shows the weakness of the network coding argument,
to my mind. The name overlap with the IETF FECFRAME seems
like an excuse -- because there is already a glossary
which can help avoid the 'confusion' that is claimed.
Similarly, a larger acknowledgment, at least,
that the 'other' FEC exists would be appropriate for
setting context - even though it is dismissed as out
of scope. I'd entertain the argument that network coding
and link coding can be complementary, depending on
conditions and use cases (rather like the ARQ/FEC tradeoff
we discussed in RFC3366 with discussion of hybrid strategies)
-- but I'm having trouble imagining realistic applications
over 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 complementary
argument needs more exploration and fleshing out, imo,
and could become a strength of this draft.
Geo satellite conditions generally drive the path, and
the conditions are handled locally in the link/phy layer
for the satellite link. But if network coding is compelling,
why should there being a well-conditioned satellite link in
the path even matter?
My take: this draft is a narrowly-scoped house of cards
which does not hold up that well under inspection, despite
the effort being put into shoring it up - it's better
than previous versions, but it's a difficult take to
support as it stands. Well, that's reality for you, and
reality bites.
Do give it some thought, give it a spellcheck and a close
reading 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 satellite payload/packet vs frame payload causing
confusion if no context is provided, and there is little need
to refer to the satellite platform/payload distinction when everything
is going through the communications payload. However, there is a
glossary in the draft where the term and its use can be explicitly
called out. A glossary is to clear up confusion about vocabulary;
that is why it is there.
FECFRAME is integral to DVB-S and S2, which the draft relies
on heavily. That an IETF group chose the same name, what, a
decade later is merely a coincidence. And there is a glossary
in the draft where the term and its use(s) can be explicitly called
Really, discussing DVB-S without not even saying why you're
not addressing the key FECFRAME component of DVB-S is
insufficient, or not clarifying error correction vs erasure
correction in some detail particularly where terminology (FEC)
overlaps, is not enough in my view.
noted on the draft:
   Physical and link layers coding protection is    usually sufficient to guarranty Quasi-Error Free, with a negligeable 
should be
Physical- and link-layer coding protection are usually
sufficient to guarantee Quasi-Error-Free communications,
with a negligible...
Please run a spellcheck before asking for another
last call.
thanks and regards
On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca <> wrote:
Dear all,
We have uploaded the preliminary meeting minutes in the datatracker:
Please tell us if you have comments.
NB: you will also find them in the github repository in IMHO a more readable format
    along with all the slides presented:
We’d like to warmly thank Nicolas, Cédric and Oumaima for taking notes.
Marie-Jose and Vincent
nwcrg mailing list
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Coding for efficient NetWork Communications Research Group RG of the IRTF.

        Title          : Network coding for satellite systems
        Authors        : Nicolas Kuhn
                          Emmanuel Lochin
        Filename        : draft-irtf-nwcrg-network-coding-satellites-09.txt
        Pages          : 15
        Date            : 2019-12-11

  This document is the product of the Coding for Efficient Network
  Communications Research Group (NWCRG).  It conforms to the directions
  found in the NWCRG taxonomy [RFC8406].  Thus, the scope of the
  document is network coding as a linear combination of packets in and
  above the network layer.  Physical and MAC layer coding are beyond
  the scope of the document.  The draft focuses on a multi-gateway
  satellite system and identifies the use-cases where network coding
  provides significant performance improvements.  The objective is to
  contribute to a larger deployment of network coding techniques in
  SATCOM to complement already implemented loss recovery mechanisms.
  The draft also identifies open research issues related to the
  deployment of network coding in SATCOM systems.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

nwcrg mailing list
nwcrg mailing list