Re: [nwcrg] nwcrg @ ietf106 minutes

["[e-mail]" <[e-mail]>]

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 [e-mail] http://about.me/lloydwood 

    On Wednesday, 11 December 2019, 19:31:31 GMT+11, Kuhn Nicolas <[e-mail]> wrote:  
 
 
Hi,
 
  
 
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.
 
  
 
Cheers,
 
  
 
Nicolas
 
  
 
De : nwcrg <[e-mail]>De la part de Kuhn Nicolas
Envoyé : jeudi 5 décembre 2019 17:30
À : '[e-mail]' <lloyd.wood=[e-mail]>; Vincent Roca <[e-mail]>; [e-mail]; Marie-Jose Montpetit <[e-mail]>
Objet : 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 <[e-mail]>De la part de [e-mail]
Envoyé : mardi 26 novembre 2019 09:24
À : Vincent Roca <[e-mail]>;[e-mail]; Marie-Jose Montpetit <[e-mail]>
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 [e-mail] http://about.me/lloydwood
 
  
 
  
 
On Tuesday, 26 November 2019, 18:37:18 GMT+11, Marie-Jose Montpetit <[e-mail]> 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
 
[e-mail]
 
[e-mail]
 
  
 
On November 26, 2019 at 1:43:02 AM,[e-mail] ([e-mail]) 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 [e-mail]://about.me/lloydwood
 
  
 
  
 
On Tuesday, 26 November 2019, 01:08:12 GMT+11, Vincent Roca <[e-mail]> 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
 
[e-mail]
 
https://www.irtf.org/mailman/listinfo/nwcrg
 
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

Abstract:
  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:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-09
https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-09


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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