Re: [nwcrg] nwcrg @ ietf106 minutes

Kuhn Nicolas <> Wed, 11 December 2019 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCE37120A88 for <>; Wed, 11 Dec 2019 00:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gk2OUBJSUnV1 for <>; Wed, 11 Dec 2019 00:31:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F73C120864 for <>; Wed, 11 Dec 2019 00:30:59 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.69,301,1571702400"; d="scan'208,217"; a="31505280"
X-URL-LookUp-ScanningError: 1
From: Kuhn Nicolas <>
To: Kuhn Nicolas <>, "''" <>, Vincent Roca <>, "" <>, "Marie-Jose Montpetit" <>
Thread-Topic: [nwcrg] nwcrg @ ietf106 minutes
Thread-Index: AQHVpDL7AWO6lVBJyU6EoWpn0sDEh6errQyggAkEcFA=
Date: Wed, 11 Dec 2019 08:29:55 +0000
Deferred-Delivery: Wed, 11 Dec 2019 08:30:55 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--20.933000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/mixed; boundary="_004_F3B0A07CFD358240926B78A680E166FF1ED232F3TWMBXP03cnesnet_"
MIME-Version: 1.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: Wed, 11 Dec 2019 08:31:06 -0000


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

Lloyd Wood<>

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<>
--- Begin Message ---
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
--- End Message ---