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

Vincent Roca <vincent.roca@inria.fr> Fri, 10 May 2019 13:14 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4FB1201B7 for <nwcrg@ietfa.amsl.com>; Fri, 10 May 2019 06:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWKXA7WvcRpl for <nwcrg@ietfa.amsl.com>; Fri, 10 May 2019 06:14:46 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15961201A2 for <nwcrg@irtf.org>; Fri, 10 May 2019 06:14:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,453,1549926000"; d="scan'208,217";a="382589668"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.34]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 15:14:43 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <032D9225-A933-4B31-BDB3-562B6F3948D8@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EF0F7DA0-CD73-47B8-A4F3-D2AFAF0C396A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 10 May 2019 15:14:42 +0200
In-Reply-To: <BL0PR11MB33941ECA07714F1024DCAD6290340@BL0PR11MB3394.namprd11.prod.outlook.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, Marie-Jose Montpetit <marie@mjmontpetit.com>
To: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>, Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr>, "nwcrg@irtf.org" <nwcrg@irtf.org>
References: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr> <BL0PR11MB33941ECA07714F1024DCAD6290340@BL0PR11MB3394.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/1fs4GKLL3cgv4GXxNMAcYCCrrhs>
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2019 13:14:49 -0000

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>.