Re: [nwcrg] nwcrg @ ietf106 minutes

Marie-Jose Montpetit <marie@mjmontpetit.com> Tue, 26 November 2019 08:32 UTC

Return-Path: <marie@mjmontpetit.com>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CCB12081B for <nwcrg@ietfa.amsl.com>; Tue, 26 Nov 2019 00:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.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 AWIfiDZbqMRb for <nwcrg@ietfa.amsl.com>; Tue, 26 Nov 2019 00:32:31 -0800 (PST)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 16D1412081A for <nwcrg@irtf.org>; Tue, 26 Nov 2019 00:32:18 -0800 (PST)
Received: by mail-il1-x131.google.com with SMTP id u17so16868693ilq.5 for <nwcrg@irtf.org>; Tue, 26 Nov 2019 00:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=3ltwgK+kOd/HLPuAx4MEWQx2cFGQlHsgY+qfhbxdiWc=; b=h4aFlHROprHYpHb5FojO5MJVmjAml30vknAxcNoyJ2TAbQtQ33qO+cMRMGzbSXgdCC kBuFcrCeHd37XbLJaYn5hv25urj9ei+2A7WKqHbHT9SozBGdxHAyUImTTcr7NtQNWMVH QMHIqvm9JznJc0WEARqkjvPES5ke1swPJ8zPj62omZN0dz1IRIz/dHQsZeiaOndLKK2N rm89kn/lAXvouLqwBgvRypR0O7Tx1/1wDyiz3QVyIFjTBZ8AAA/CAAfbK1pt9WYPw5Wr M3Ifh9TJknHqRI3pfe9AItFGO1etauhuvZr+QsN46rYJUnHDNyGwPhA/3IPqMA++Z/P5 Fskg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=3ltwgK+kOd/HLPuAx4MEWQx2cFGQlHsgY+qfhbxdiWc=; b=mRpmAJrPmT0crQplZowQ18VYtlxWjtrI62ZNs6cP3s2+HeWEVq5fpyQwcB70H7shit lfOwJiZFHQL9k9pQ78ActzlNcvKObCCf18V5OHITH5bEkqPoQTEnZaRXHwjK6y6cfL6b nAZCSZeTgSzFj4lM0T1fsPDiCqYGBkcpw4rjy3V2sca3mobmzAdb/zwzi7zCxEEMJ2IC nMzWPgaE1UBtfKuHx46ksR8rG9sxJpJJ0R/dDIIiWNwD4S60mtRRch74mm6VR4VsfuRS YBvG/Xkd+4GA/fhrNFQWssLzeVQZ+Xfeod/HqvkKRYRhFDDGu/arJkqdIFiXtqzGunPh JGRg==
X-Gm-Message-State: APjAAAXLj+Tj5DqIlU7abId2sVMD+uUS7eUOLe4dpqy8GZLUKJouSv6k Lw3/C1hzgi8VYiCl7g1xJ9oFr777lnXppHIx+Y7YCw==
X-Google-Smtp-Source: APXvYqzYkGvDoCUL35Tlho/IyX8g87AXSxddEDMVpHLfdzzSm5gRbEmX6lq56/JR7etHxLDZMg31arpEaSW2neGBRiE=
X-Received: by 2002:a92:4609:: with SMTP id t9mr35582621ila.156.1574757136960; Tue, 26 Nov 2019 00:32:16 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 26 Nov 2019 00:32:16 -0800
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <782986222.95438.1574756669195@mail.yahoo.com>
References: <9919B131-F5AF-4315-8306-DEE754984D0F@inria.fr> <2034725577.38471.1574728976552@mail.yahoo.com> <CAPjWiCTgjxckAm5VWqZ7c7o6xy8s4W4m2RbXj=ndTbTvnoXsNg@mail.gmail.com> <782986222.95438.1574756669195@mail.yahoo.com>
MIME-Version: 1.0
Date: Tue, 26 Nov 2019 00:32:16 -0800
Message-ID: <CAPjWiCRRkVN6JH+K7Ry8hTM7b7Hp=-q=jxmm4WyTVvBRODoeRg@mail.gmail.com>
To: Vincent Roca <vincent.roca@inria.fr>, "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>, nwcrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000c19d2e05983bb709"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/PJbAJx6sdQs1yJuNTqQ1-x9KHWA>
Subject: Re: [nwcrg] nwcrg @ ietf106 minutes
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 08:32:35 -0000

Sorry I meant adding to the glossary.

mjm

Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com
mariejo@mit.edu

On November 26, 2019 at 9:24:35 AM, lloyd.wood@yahoo.co.uk (
lloyd.wood@yahoo.co.uk) wrote:

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.


https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/?


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...


best


L.


Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood


On Tuesday, 26 November 2019, 18:37:18 GMT+11, Marie-Jose Montpetit <
marie@mjmontpetit.com> 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?

mjm



Marie-José Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
mariejose@mjmontpetit.com
mariejo@mit.edu

On November 26, 2019 at 1:43:02 AM, lloyd.wood@yahoo.co.uk (
lloyd.wood@yahoo.co.uk) 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
out.


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 lloyd.wood@yahoo.co.uk http://about.me/lloydwood


On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca <
vincent.roca@inria.fr> wrote:


Dear all,

We have uploaded the preliminary meeting minutes in the datatracker:
    https://datatracker.ietf.org/doc/minutes-106-nwcrg/
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:

https://github.com/irtf-nwcrg/rg-materials/tree/master/ietf106-2019-11_singapore

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

Cheers,

Marie-Jose and Vincent

_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg