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

[Vincent Roca <[e-mail]>]

Hello Nicolas and Emmanuel,

My answers below.

> Thank you for your review of our document. 
> We have just pushed a *-05 version that, we hope, assess your comments. 
> I propose some comments below. 
> 
> I will try to connect remotely to the next meeting.
> Let me know if you think that a presentation of the update of this document is relevant. 

[…]

> ——
> 
> ** 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).
> 
> [NK] Thanks
> 
> ** 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)?
> 
> [NK] IMHO, this document is not aiming at identifying research challenge, but rather the opposite: identify what has been done in research in this topic and try to identify use-cases that are relevant for industrials. 

[VR] The goal is clearly defined in introduction and it can make sense. However this is a question
that may arise as « research challenges » discussions are well appreciated in IRTF groups.

> 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).
> 
> [NK] Thanks. We have updated the introduction to reflect your comment as follows: 
> Guaranteeing both physical layer robustness and efficient usage of
>   the radio resource has been in the core design of SATellite
>   COMmunication (SATCOM) systems.  The trade-off often resided in how
>   much redundancy a system had to add to cope from link impairments,
>   without reducing the good-put when the channel quality is high.
>   Generally speaking, enough redundancy is added so as to guarantee a
>   Quasi-Error Free transmission; however, there are cases where the
>   physical layer could hardly recover the transmission losses (e.g.
>   with a mobile user) and layer 2 (or above) re-transmissions induce an
>   at least 500 ms delay with a geostationary satellite.  Further
>   exploiting network coding schemes at higher OSI-layers is an
>   opportunity for releasing constraints on the physical layer and
>   improve the performance of SATCOM systems when the physical layer is
>   challenged.  We have noticed an active research activity on how
>   network coding and SATCOM in the past.

[VR] Great. I like this extended introduction that clearly states the situation.
Typos:
- s/improve/improving/
- verb is missing in last sentence. 

> ** 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.
> 
> [NK] The new version of the introduction tries to assess this point. 
> 
> Section 2:
> 
> ** Please define (beyond the acronym list) what SATCOM refers too. Is it a generic term, and in that case say so.
> 
> [NK] Done
> 
> ** 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?
> 
> [NK] We have precised that.

[VR] Thanks.

Typo:
- s/on a aggregate/on an aggregate/

> 
> ** 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.
> 
> [NK] We have provided some more information. We hope that this is clearer now. 
>   o  BBFRAME: Base-Band FRAME - satellite communication layer 2
>      encapsulation work as follows: (1) each layer 3 packet is
>      encapsulated with a Generic Stream Encapsulation (GSE) mechanism,
>      (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs
>      contain information related to how they have to be modulated (4)
>      BBFRAMEs are forwarded to the physical layer;
> 
> [...] 
> 
>   o  PEP: Performance Enhanced Proxy - a typical PEP for satellite
>      communications include compression, caching and TCP acceleration;
> 
>   o  PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME
>      with additional information (e.g. related to synchronization);
> 
>   o  SATCOM: generic term related to all kind of SATellite
>      COMmunications systems;

[VR] Good. Just a comment: UMTRAN is defined but not used in current text.


> ** 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.
> 
> [NK] We have updated both figure 1 and the text directly referring to it. 

[VR] Thanks. However this section 2 remains unclear to me. Naively, I thought that 
« multi-gateway » refers to multiple satellites that collaboratively route/forward traffic.
I see it’s not the case, but why is the distinction between access and physical gateways
important enough to qualify this architecture a multi-gateway system?


> Section 3:
> 
> ** The legend of Figure 2: "Network coding and satellite systems » could be improved to highlight that this is for currently deployed systems. 
> 
> [NK] Done
> 
> ** 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!
> 
> [NK] That is indeed what we know from public information.

[VR] Maybe a sentence to clarify this would be welcome, in order to complement the table.


> Section 4:
> 
> ** s/middle ware/middleware/
> [NK]  Thanks
> 
> 
> 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)? 
> 
> [NK] We have reworked most of the figures. I hope this is clearer now. 

[VR] Good. I now understand.
The legend and notation is however unclear. 
Rather than:     -X>-               I’d prefer:  --X->--
Rather than:     ={X+Y=         I’d prefer:   ==<=X+Y==


> Section 4.2
> 
> ** s/multi-cast/multicast/g
> 
> [NK] Done. 
> 
> ** 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.
> 
> [NK] We have clarified the figure. 

Well, I don’t like the paragraph:
   "A multicast flow (M) […] so that the information transfer is reliable. »
at all. No mention to coding is done whereas this is an obvious target use-case.

I suggest:
   A multicast flow (M) is forwarded to both satellite terminals A and B.
   However packet Ni (resp. Nj) get lost at terminal A (resp.  B), and terminal A (reps. B) returns a negative acknowledgement Li (resp. Nj), indicating that the packet is missing.
   Then either the access gateway or the multicast server includes a repair packet (rather than the individual Ni and Nj packets) in the multicast flow to let both terminals recover from losses.

And finally:
 This could be achieved by using NACK-Oriented Reliable Multicast (NORM) [RFC5740] in situations where a feedback is possible and desirable, or FLUTE/ALC [RFC6726] when it is not the case.
  Note that currently both NORM nor FLUTE/ALC are limited to block coding, none of them supporting sliding window encoding schemes [RFC8406].

NB: it’s time to update the taxonomy I-D reference to RFC8406 ;-)

Typo:
s/is forward/is forwarded/


> Section 4.3:
> 
> ** Question: in "to either increase the reliability or the total bandwidth » are the two alternatives really mutually exclusive?
> 
> [NK] In multipath transport, having reliability and higher bandwidth is not always guaranteed. 
> 
> ** 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!
> 
> [NK] Same as above, we have slightly clarified the figure and hope that it is clearer. 
> 

[VR] Much better. However, using "->- : bidirectional link », i.e., a unidirectional arrow to indicate a
bidirectional link is inappropriate. This comment also applies to the following figures.

Typo:
- s/cope from/cope with/
- instead of "end-user movements » I’d prefer "end-user mobility »

> 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.
> 
> [NK] Same as above, we have slightly clarified the figure and hope that it is clearer. 
> 
> ** 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? 
> 
> [NK] Same as above. 

[VR] Okay.

> 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.
> 
> [NK] It may be optimistic and we can make it less optimistic in a next update of the document if you think it is relevant. 

[VR] You’re saying that « the discussion on how network coding can be
   integrated inside a PEP with QoS scheduler has been proposed in RFC 5865 » 
Really? I gave a (very) quick look at rfc 5865 but it’s only about diff-serv.


> ** 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.
> 
> [NK] We have moved the discussion on the cellular network in a conclusion. 

[VR] That’s much better.

> Section 9 « Security considerations »
> 
> ** Well, I’m sure we can find a few interesting things to talk about. 
> 
> [NK] I would be happy to discuss it :).

[VR] Sure, but you’re the satellite guy, don’t forget it.


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


Typos:

** section 1.1, PEP definition: s/include/includes/

Cheers,

  Vincent