Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"

[Kuhn Nicolas <[e-mail]>]

Dear Lloyd,

Thank you for your feedback. 

Please find comments to your points in-line. 

We have submitted an updated version of the draft. 
We have also prepared slides to discuss the different points during the next IETF meeting. 

Cheers, 

Nicolas

-----Message d'origine-----
De : nwcrg <[e-mail]> De la part de [e-mail]
Envoyé : samedi 26 octobre 2019 05:13
À : [e-mail]; Vincent Roca <[e-mail]>
Cc : Marie-Jose Montpetit <[e-mail]>
Objet : Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"

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


some comments, since I haven't seen much traffic on this:


Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?

[NK] In PR #51 : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.

I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc.
They're stated as out of scope...

If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be '_network_ coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.

[NK] In PR #52 , we have changed:
"Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document."
by
"Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems."
For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level.
For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.

Discussion of BBFRAME without discussing the FECFRAME (BBFRAME with coding) appears to be an omission. Is this imagining a world where FECFRAME, and its convolutional layers of coding are considered completely unnecessary due to path coding within the BBFRAME?
If so (and it won't gain much traction) this would need to be stated.
I don't think claiming that FECFRAME is link/channel and out of scope really flies; BBFRAME is a link construct too.

[NK] In the representation that is proposed in Fig 2, we consider that the physical gateway turns BBFRAME into PLFRAME. We did not want to go more into the details on how this is achieved.
We have added in PR #53


Fig 2: PEP is primarily a transport-level function; firewalls are primarily network and transport. Having one outdour unit (dish at gateway?) when the other end (user terminal) has both an indoor and outdoor unit (IDU and ODU) seems a simplification. No idea what the stepped end user boxes mean; if four end users, four boxes the same size might convey that better, with numbers on them. 1, 2, 3, 4 ... n

[NK] We have reworked the figure in PR #54 .
We hope this is clearer.


minor nits:


section 4.1 - PEP is Enhancing, not Enhancement. PEP_s_ usually split...


section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well.


ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist.

[NK] Thanks for the nits on the PEP.
For the comment on ACM, we have updated the text (PR #55) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough."
We have updated the conference in PR #56 and PR #57

This document has a difficult task (trying to build something from nothing) but at least it's readable enough to debate.

[NK] Thanks a lot !


best


Lloyd Wood [e-mail] http://about.me/lloydwood






On Wednesday, 16 October 2019, 01:37:00 GMT+11, Vincent Roca <[e-mail]> wrote: 





Hello everybody,

A first RG Last Call for the « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04 draft in April this year enabled to collect many highly valuable feedbacks. They have been taken into consideration according to the authors who produced an update.

It’s now time to start a second RG LC for version -06:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

We would like to collect your comments by Wednesday 6th, November (3 weeks).

Thanks in advance.

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

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

--- Begin Message ---

A new version of I-D, draft-irtf-nwcrg-network-coding-satellites-07.txt
has been successfully submitted by Nicolas Kuhn and posted to the
IETF repository.

Name:           draft-irtf-nwcrg-network-coding-satellites
Revision:       07
Title:          Coding techniques for satellite systems
Document date:  2019-10-29
Group:          nwcrg
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-network-coding-satellites-07.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/
Htmlized:       https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites
Diff:           https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-07

Abstract:
   This document is the product of the Coding for Efficient Network
   Communications Research Group (NWCRG).  This document follows the
   taxonomy document [RFC8406] and considers coding as a linear
   combination of packets that operate in and above the network layer.
   In this context, this memo details a multi-gateway satellite system
   to identify use-cases where coding is relevant.  As example, coding
   operating in and above the network layer can be exploited to cope
   with residual losses or provide reliable multicast services.  The
   objective is to contribute to a larger deployment of such techniques
   in SATCOM systems.  This memo also identifies open research issues
   related to the deployment of coding in SATCOM systems, such as the
   interaction between congestion controls and coding techniques.




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.

The IETF Secretariat

--- End Message ---