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

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

(If a new draft is issued, does the last call clock restart?)

Nicolas

" I guess we should not go back to the "network coding"-like title."

Since this draft talks about network coding, it needs to explicitly state that,often, imo. Whenever this draft talks about coding, it means network coding --and it does need to state that to avoid losing the satellite-oriented audience.
   Considering for instance geostationary satellite system (GEO),
   physical or link layer erasure coding mechanisms recover transmission
   losses within a negligible delay compared to link delay.
The whole point of a FECFRAME and its two layers of coding isto recover and correct bit errors with no delay. This is not considered anerasure coding mechanism, which is very much a network coding concept.It really isn't possible to talk about DVB-S(2|2x) without some mentionof FECFRAME.

   Further exploiting
   coding techniques at application or transport layers is an
   opportunity for releasing constraints on the physical layer 
Having coding at the physical layer releases constraints on higherlayers. They can be viewed as supplementary, or different pointsin a design tradeoff space. Why you'd want to free up physicallayer overhead engineered and carefully tuned for the channel andlink for something that isn't, imposing more overhead -- well,that's a good question.


      It focuses on situations
      where coding is not widely deployed in current SATCOM systems.


Coding is widely deployed in every current satcom system. You mean
network coding *for applications and transports traversing satellite
links*. I can't stress enough how much this matters. The
implication that this will somehow 'fix' satellite systems that
don't have the coding that is considered desirable does the draft a
disservice.


inconsistent typo: "out door"

   (using multiple paths does not guarantee an
   improvement of both the reliability and the total capacity).

I believe you mean "using multiple paths does not guarantee animprovement of *either* the reliability *or* the total capacity).
Express it in Boolean algebra...


Sorry, commenting on this draft requires far more time than
I have available, so I'll stop here.

best

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




 
 
 On Wednesday, 30 October 2019, 20:40:17 GMT+11, Kuhn Nicolas <[e-mail]> wrote: 





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

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