Re: [nwcrg] nwcrg @ ietf106 minutes

Hi,

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,

Nicolas

De : nwcrg <nwcrg-bounces@irtf.org> De la part de lloyd.wood@yahoo.co.uk
Envoyé : mardi 26 novembre 2019 09:24
À : Vincent Roca <vincent.roca@inria.fr>; nwcrg@irtf.org; Marie-Jose Montpetit <marie@mjmontpetit.com>
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.

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<mailto: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<mailto: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<mailto:mariejose@mjmontpetit.com>
mariejo@mit.edu<mailto:mariejo@mit.edu>

On November 26, 2019 at 1:43:02 AM, lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> (lloyd.wood@yahoo.co.uk<mailto: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<mailto: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<mailto: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<mailto:nwcrg@irtf.org>
https://www.irtf.org/mailman/listinfo/nwcrg