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

From: "Border, John" <[email-masked]>
Date: Thu, 2 May 2019 21:13:55 +0000

Some comments on the document...

      I definitely agree with Lloyd that the discussion needs to always be clear what is being referred to by "coding".  Forward Error Correction (FEC) coding below the network layer takes us a long way.  At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough.  I do see that the referenced taxonomy document includes Forward Erasure Correction.  This “FEC” is described as an application layer technique.  The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers.  In any case, it is not always clear which “FEC” the document is referring to.

      Not that important but…  500 milliseconds is kind of high for the one way delay.  Congestion can get it there (and beyond).  But, we typically talk about 350 milliseconds.

      Section 4.2, 2nd Paragraph

            "Unidirectional" implies (to me) no ACKs.  Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost.  This seems different enough to me to be explained separate from NORM.

      In Sections 4.3 an 4.4, some additional discussion is needed explaining how network coding helps.

      Re Lloyd's comment about Section 4.4…

            I think the point (which needs to be much clearer) is that packets can be lost with sudden link condition changes when ACM cannot react fast enough.  Network coding could be use to compensate for this.  (However, usually this is a rare enough occurrence that the network coding overhead might not be worth it if that was the only thing it was doing.  This leads to the observation that it might take a combination of use cases to justify a particular network coding solution.)

      Section 9

            There is one security consideration that I think needs some discussion.  Theoretically, without some authentication protection, at least with some network coding approaches, an attacker could generate repair packets that alter the original data or at least cause denial of service.

Beyond the document…

      I have talked about this with Nicolas (et al.)…  I am not personally aware of the use of network coding to do any of the things mentioned over satellite networks.  I know of a couple of cases where the equivalent of network coding was used at the application layer.  But, I am hoping something can be developed to use this kind of coding to reduce the impact of recovering from packet loss faster than can be done via end to end retransmission over satellite. This is necessary because encrypted transports such as QUIC eliminate the ability to use PEPs to do the same thing.  I think any such mechanism, though, would require some ability to adapt to changes in latency and packet loss rate.

John

A few document nits…

      Section 2, 1st and 2nd Sentences

            “in satellite system” should be “in a satellite system”.  Not clear what “lays” means here.

            “multi-gateway satellites network” should be “multi-gateway satellite network”.  (Most of the uses cases have nothing to do with multi-gateway, though.)

      Section 3, 2nd Sentence

            Delete the duplicate “where”.

      Section 6, 2nd Sentence

            “that the some scenarios” should be “that some scenarios”.

-----Original Message-----
From: nwcrg <[email-masked]> On Behalf Of Vincent Roca
Sent: Thursday, April 18, 2019 1:42 AM
To: [email-masked]
Cc: Vincent Roca <[email-masked]>; Marie-Jose Montpetit <[email-masked]>
Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"

WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello everybody,

As discussed during the IETF104 meeting, we would like to start a RG Last Call for draft « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04

  https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dirtf-2Dnwcrg-2Dnetwork-2Dcoding-2Dsatellites_&d=DwIGaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=xPjBNRNdH_plOZd3f1NHC2zBjIGeGVJHWaC71SSw38Y&s=32zN_mPt7oUxDtLocIctXP50qy7zOeyVdjvNk59Flhk&e=

We would like to collect your comments by Thursday 9th, May (3 weeks).

Thanks in advance.

    Marie-Jose and Vincent
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_nwcrg&d=DwIGaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=xPjBNRNdH_plOZd3f1NHC2zBjIGeGVJHWaC71SSw38Y&s=YeRZHRydTmylC7Wm-bPvydTuvdHuUghSRUax72-cCQw&e=

---

From: Vincent Roca <[email-masked]>
Date: Fri, 10 May 2019 15:14:42 +0200

Dear authors, everybody,

My global feeling is that:

- this doc per-se is not yet ready, but the amount of work remaining is reasonnable and it's essentially a matter of clarifying several aspects;

- this document is useful at least to the NC/FEC community. It provides an interesting high-level overview of a domain (SATCOM) that is not very documented otherwise;

- there are of course limits to the work (it's a high-level overview) but this is not by itself an issue.

Cheers,

  Vincent

---

Abstract:

- The current abstract is not sufficiently detailed: which type of coding? Do you refer to FEC or NC (say so) since it may also be used for other types of coding. The notion of "wider scale" also suggests it is already deployed (is it the case?), or that it may be used outside of the multi-gateway satellite system itself. On the whole, this abstract is pretty ambiguous.

Section 1, Introduction:

- A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.

- The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.

- Typo: s/to cope from/to cope with/

Section 2, Note on sat topology

- First sentence is not very clear (structure (that ... that...), missing "a" in "in statellite system that lays...", etc.
- Last sentence "Coding schemes could be applied on both single and aggregated traffic." deserves to be detailed. Will it be discussed later on in this document?

Section 3, Actual deployment

- in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.

- Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.

- When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.

Section 4.1 Two-way relay

- The explanation is wrong IMHO. Terminal A wants to send traffic to terminal B, and vice-versa. This is why it is meaningful to send back a combination of the two flows. Otherwise if the server is the final destination it makes no sense.

- Fig. 3 refers to "gateway" and "server", two generic terms that are not used in Fig. 1. Is the server one that implements the "Network Functions" or is it an "Application Server"? I guess its the first case, but...
The same remark applies to Fig. 4, Fig. 5 (with a new term, "Data Server").

Section 4.2 Reliable multicast

- and you may add other forms of robust multicast/broadcast systems, RTP + FEC or FECFRAME for instance. But all of this is purely end-to-end, and you can use whatever you may want. But yes, the broadcast nature of a SATCOM makes these protocols perfectly suited.

Section 4.3 Hybrid access

- It is said that coding is used to cope with packet losses (last paragraph). Doesn't it also bring a lot of flexibility in the way traffic is split over the various access networks? Doesn't it also improve goodput in case traffic gets de-synchronized? And since these links have different transmission delays, it could also help, preventing head of line blocking. I have the feeling it's much more than just loss recovery.

Section 4.4 Varying capacity

- I'm wondering if the section title is appropriate. Wouldn't it be better to say: "Dealing with varying channel conditions"?

- I guess that the ACM scheme is applied at the PHY layer. This should be mentionned (it's said nowhere). And when you say just after that "The coding schemes could be applied at the access gateway or...", I guess that this time "coding" refers to the redundancy applied in higher layers, not that of ACM. Please clarify (it's somewhat the case in the following sentence).

- Typo: "relevant for when" => "relevant when"

- This use-case also introduces the question of adapting dynamically the protection to the channel conditions. You say it's not feasible at the PHY layer (within ACM), what about the higher layers? Is the problem easier to solve? Do you suggest to add a constant higher layer protection? Several questions arise here that could be mentioned.

Section 4.5 Gateway handover

- Typo: "this may result in packet loss" => losses and not loss.

Section 5 Research Challenges

- This section deserves a small introduction where you explain that you discuss a few topics, without trying to be exhaustive.

Section 5.1

- Are PEP part of "Network Functions"? What's their position in the architecture of Fig. 1?

- I don't understand why the question on code rate to use is in a challenge called "increased deployability". I'd rather put it in a challenge on dynamic adaptation (which is not identified).

Section 6 Conclusion

- First sentence, the use of "these techniques" is ambiguous. Which techniques?

Section 9 Security Considerations

- The way it's said may call for comments during SecDir review. I'd rather say:

Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section 3). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.

---

Side comment:
Any document issued from an IRTF RG needs to follow a certain number of rules (See https://trac.ietf.org/trac/irtf/wiki/IRTF-RFCs)
and more particularly item « Research Group Preparation ». In this case:

- abstract must mention the origin.
   This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG).
- Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406):
   This document is the product of and represents the collaborative work
   and consensus of the Coding for Efficient Network Communications
   Research Group (NWCRG); it is not an IETF product and is not a
   standard.  <A SMALL HISTORY HERE OF THE DOC AND SUPPORT IT GATHERED>.

---

From: Vincent Roca <[email-masked]>
Date: Mon, 13 May 2019 12:17:00 +0200

Dear authors, all,

The RG Last Call period just ended and we received several feedbacks. Above all, Marie-Jose 
and myself would like to thanks to all of you who reviewed it, this is highly appreciated.

Could you please answer to comments received so far and update your document accordingly.
Thanks in advance.

Cheers,

  Marie-Jose and Vincent (also acting as your document shepherd)

> Le 18 avr. 2019 à 07:42, Vincent Roca <[email-masked]> a écrit :
> 
> Hello everybody,
> 
> As discussed during the IETF104 meeting, we would like to start a RG Last Call for
> draft « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04
> 
>  https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/
>