Subject: [nwcrg] Review of draft-kuhn-nwcrg-network-coding-satellites-04

From: Vincent Roca <[email-masked]>
Date: Wed, 20 Jun 2018 17:17:04 +0200

<Chair hat off>

Hello Nicolas and Emmanuel,

Please find below a review of your I-D.
Cheers,

 Vincent

——

** Globally I do appreciate this compact I-D. It goes right to the point which is fine, even if sometimes an explanation 
  would be welcome (examples below).

** General comment: the current I-D does not put so much emphasis on research challenges. This can be an issue. 
  Do you think this can be improved without involving a full rework of the I-D (which is not the goal)?

Section 1, Intro:

** Sentence "Network coding schemes are inherent part of the satellite systems » contradicts the abstract that mentions "current deployment of network coding in some
 satellite telecommunications systems » (but not all of them).

** It is not clear how the use of coding enables a "better exploitation of the scarce resource ». And there’s no mention to
  the long to very long delays involved and the obvious benefits of coding from this point of view.

Section 2:

** Please define (beyond the acronym list) what SATCOM refers too. Is it a generic term, and in that case say so.

** Sentence:
	"It is worth noting that some functional blocks aggregate the traffic
	 coming from multiple users, allowing the deployment of network coding
	 schemes. »
is not clear to me. Why is aggregation a requirement to NC?

** Having a glossary is fine, but if the acronyms are expended, there is no explanation, and Fig. 1 is provided as is, without
any description. A sentence (in section 2 or in section 1.1, up to you) about BBFrame, PLFrame, PEP, etc. would be welcome.
No need to have lengthy descriptions (this I-D should remain compact), but a middle term is needed.

** Fig 1 is a bit strange. The link from servers to the outdoor unit is pretty detailed, but then there is no detail, the satellite link
arriving directly to the terminal. Why not with a satellite phone, but in case of a home connected to Internet through a satellite
link, I guess there are a few components in between.
I don’t understand either why this is supposed to be a "multigateway satellite system ». Access and PHY gateways have different
roles. Is that the reason? Not clear.
Then, why do you depict two stacks?
Are the Access Functions and gateways collocated? In that case regular Internet is supposed to link application servers to the
Network Function boxe. Am I right?
And since we focus on Internet access, some links should be bidirectional which is not the case.

Section 3:

** The legend of Figure 2: "Network coding and satellite systems » could be improved to highlight that this is for
currently deployed systems. 

** Fig. 2 depicts a situation that is pretty different from that of the introduction (where it is said that NC is « an inherent part
of the satellite systems »). Except within the application (where any developper is free to add what she wants) and PHY coding,
there’s nothing else!

Section 4:

** s/middle ware/middleware/

Section 4.1:

** I suggest adding arrows to the "===«  links of Fig. 4. for the A+B flow. In particular when the arrow reaches term A and B.
Maybe: 
               ^
		||===============
		v
would be preferable.
I know the use-case but I have problems understanding the figure. Why is there such a big gateway for instance (it’s 3 times
the surface of the server)? 

Section 4.2

** s/multi-cast/multicast/g

** Is the multicast flow originating from the gateway? I see a « —«  from the multicast server and then « ===«  since the gateway.
 Very obscur. Also please add arrows and better terminate the arrow arriving to A and B terminals.

** More fundamentally, does this use-case really require a feedback? Isn’t a purely unicast stream feasible and sometimes desirable
 (for instance for scalability purposes?). FLUTE/ALC and FECFRAME are perfect match in that case. And if there’s a feedback
flow, Tetrys as a sliding window approach with a reference to one of the published articles.

Section 4.3:

** Question: in "to either increase the reliability or the total bandwidth » are the two alternatives really mutually exclusive?

** Fig. 5 introduces the notion of Backbone Concentrator that is not described neither here nor in the Glossary.
 The flow destination is also missing, this is a little bit annoying IMHO.
 Another comment regarding the figure: there’s a single flow leaving the CPE which is then split during transmission. This is really
 misleading. Three flows should leave the CPE!

Section 4.4.

** What is the meaning of the « ? » in « NC? », Fig. 6? 
 And how should we understand that? Is it between the terminal AND the PHY gateway, or between the terminal AND the Access Gateway, etc. 
 I imagine that NC between the PHY and Access gateway is meaningless.
 In fact I also have problems undersntanding the sink of the data flow. It seems to be the Network Function box, but I guess there
 should be a destination server or terminal instead.

** Text is unclear about the implications of each technical proposal (at access gateway or network function).

Section 4.5

** Sorry but I don’t understand Fig. 7. I understand the problem as it is explained, but how this maps to the figure is really obscure.
  What’s the switching entity? Why are arrows bidirectional except for the terminal that only sends data? Where’s the receiver?
  And where is NC applied in this big figure? 

Section 5

** Typo : rather than "Proxy-Enhanced-Proxy » you probably mean performance…

** including NC inside PEP is not a universal solution (e.g. in case of multi-path). The paragraph is probably too optimistic as it
 suggests it’s applicable for scenarios of section 4.

** The note on similarities with cellular infra is interesting but it is not related to this section 5. Move it elsewhere. The virtualisation
 of network functions is probably more important than this cellular discussion.

Section 9 « Security considerations »

** Well, I’m sure we can find a few interesting things to talk about. 

** Finally remove me from the contributors list, I didn’t provide anything.