Subject: [nwcrg] nwcrg @ ietf106 minutes

From: Vincent Roca <[email-masked]>
Date: Mon, 25 Nov 2019 15:07:42 +0100

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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 Nov 2019 00:42:56 +0000 (UTC)

> 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 causingconfusion if no context is provided, and there is little needto refer to the satellite platform/payload distinction when everythingis going through the communications payload. However, there is aglossary in the draft where the term and its use can be explicitlycalled 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 relieson heavily. That an IETF group chose the same name, what, adecade later is merely a coincidence. And there is a glossaryin the draft where the term and its use(s) can be explicitly calledout.

Really, discussing DVB-S without not even saying why you'renot addressing the key FECFRAME component of DVB-S isinsufficient, or not clarifying error correction vs erasurecorrection 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 negligeableshould be
Physical- and link-layer coding protection are usuallysufficient to guarantee Quasi-Error-Free communications,with a negligible...

Please run a spellcheck before asking for anotherlast call.

thanks and regards

Lloyd Wood [email-masked] http://about.me/lloydwood 

    On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca <[email-masked]> wrote:  
 
 Dear all,

Cheers,

 Marie-Jose and Vincent

_______________________________________________
nwcrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 25 Nov 2019 23:28:15 -0800

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
[email-masked]
[email-masked]

> in the satellite context) may create confusion at IETF and these

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

On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca <
[email-masked]> wrote:

Dear all,

NB: you will also find them in the github repository in IMHO a more
readable format
    along with all the slides presented:

Cheers,

Marie-Jose and Vincent

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 Nov 2019 08:24:29 +0000 (UTC)

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.

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

best

L.

    On Tuesday, 26 November 2019, 18:37:18 GMT+11, Marie-Jose Montpetit <[email-masked]> 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
[email-masked]@mit.edu 

> in the satellite context) may create confusion at IETF and these
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 [email-masked]://about.me/lloydwood

On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca<[email-masked]> wrote:

Dear all,

We have uploaded the preliminary meeting minutes inthe 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 repositoryin IMHO a more readable format
    along with all the slidespresented:
    https://github.com/irtf-nwcrg/rg-materials/tree/master/ietf106-2019-11_singapore

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

Cheers,

Marie-Jose and Vincent

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 26 Nov 2019 00:32:16 -0800

Sorry I meant adding to the glossary.

mjm

On November 26, 2019 at 9:24:35 AM, [email-masked] (
[email-masked]) wrote:

Hi Marie-Jose,

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

best

L.

On Tuesday, 26 November 2019, 18:37:18 GMT+11, Marie-Jose Montpetit <
[email-masked]> wrote:

Hi Lloyd, a few things:

mjm

noted on the draft:

should be

thanks and regards

Dear all,

Cheers,

Marie-Jose and Vincent