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

From: "[email-masked]" <[email-masked]>
Date: Tue, 5 Nov 2019 09:33:10 +0000 (UTC)

(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 [email-masked] http://about.me/lloydwood

 
 On Wednesday, 30 October 2019, 20:40:17 GMT+11, Kuhn Nicolas <[email-masked]> 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 <[email-masked]> De la part de [email-masked]
Envoyé : samedi 26 octobre 2019 05:13
À : [email-masked]; Vincent Roca <[email-masked]>
Cc : Marie-Jose Montpetit <[email-masked]>
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 [email-masked] http://about.me/lloydwood

On Wednesday, 16 October 2019, 01:37:00 GMT+11, Vincent Roca <[email-masked]> 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
[email-masked]
https://www.irtf.org/mailman/listinfo/nwcrg

_______________________________________________
nwcrg mailing list
[email-masked]
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

---

From: Vincent Roca <[email-masked]>
Date: Wed, 6 Nov 2019 11:21:58 +0100

Dear authors, all,

I gave a look at the new 07 version and still found several small issues. They are listed in the joint document.
Nothing really serious, but a new version that clarifies them all is needed.

Since we’ll all be at Singapore, I suggest we take time together to revise it and prepare a new version.

Cheers,

  Vincent 

> Le 15 oct. 2019 à 16:36, Vincent Roca <[email-masked]> a écrit :
> 
> 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.
> 
> 	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/>
>

---

From: Vincent Roca <[email-masked]>
Date: Wed, 6 Nov 2019 11:26:26 +0100

Hello Lloyd,

Thanks a lot for reading and commenting this version once again. This is really useful.

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

The LC will be extended as long as we, Chairs, have the feeling the document is not yet ready. And the main benefit
of the LC is to trigger reviews.
In this case, yes, I’d like to see a new -08 version and extend the LC a little bit. We’ll see that in Singapore…

Cheers,

  Vincent

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 18 Nov 2019 15:41:07 +0000

Dear Lloyd, all,

We have updated the draft and hope this covers most of the issues.
This update also covers the comments from Vincent.
We will present this update on Thursday’s meeting.

Please let us know if you have further comments on this version.
Moreover, see inline for some comments on your email.

Thanks,

Nicolas

De : [email-masked] <[email-masked]>
Envoyé : mardi 5 novembre 2019 10:33
À : [email-masked]; Vincent Roca <[email-masked]>; Kuhn Nicolas <[email-masked]>
Cc : Marie-Jose Montpetit <[email-masked]>
Objet : Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"

Nicolas

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.
[NK] Looking again at the Taxonmy draft, it appears we can actually use the network coding title. I have changed that in the document. Thank you.

The whole point of a FECFRAME and its two layers of coding is
to recover and correct bit errors with no delay. This is not considered an
erasure coding mechanism, which is very much a network coding concept.
It really isn't possible to talk about DVB-S(2|2x) without some mention
of FECFRAME.
[NK] We present BBFRAME and PLFRAME. For more information on the DVB standards, we ask the reader to go to DVB document. The objective is more to explain how multigateway systems work – no need to go further in the detail to understand the use-cases in my opinion.

   Further exploiting

Having coding at the physical layer releases constraints on higher
layers. They can be viewed as supplementary, or different points
in a design tradeoff space. Why you'd want to free up physical
layer overhead engineered and carefully tuned for the channel and
link for something that isn't, imposing more overhead -- well,
that's a good question.
[NK] We have tried to clarify that in the updated version. We do not speak about releasing the physical layer constraints – let each of the network and physical operate separately (which will probably be the case in deployed environments).

      It focuses on situations

[NK] Same as before – we have tried to make that clearer in the introduction.

I believe you mean "using multiple paths does not guarantee an

improvement of *either* the reliability *or* the total capacity).
Express it in Boolean algebra...

[NK] Updated (sentence partially removed)

[NK] Thanks for your comments.

best

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

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

Dear Lloyd,

Cheers,

Nicolas

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

minor nits:

[NK] Thanks a lot !

best

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

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

Hello everybody,

Thanks in advance.

   Marie-Jose and Vincent
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

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

Abstract:

The IETF Secretariat

Subject: New Version Notification for draft-irtf-nwcrg-network-coding-satellites-08.txt
From: "[email-masked]" <[email-masked]>
To: Kuhn Nicolas <[email-masked]>, Emmanuel Lochin <[email-masked]>
Date: Mon, 18 Nov 2019 15:32:11 +0000

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

Name:           draft-irtf-nwcrg-network-coding-satellites
Revision:       08
Title:          Network coding for satellite systems
Document date:  2019-11-18
Group:          nwcrg
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-network-coding-satellites-08.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-08
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-08

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 network coding is relevant.  As example,
   network 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 network coding in SATCOM
   systems, such as the interaction between congestion control and
   network coding techniques.

The IETF Secretariat