Comments on section 4

[NicoKos]

"This section details use-cases where network coding schemes could improve theoverall performance of a SATCOM system (e.g. considering a more efficient usage of the satellite resource, delivery delay, delivery ratio)."

Adding network coding overhead doesn't improve efficiency, ergo removing network coding overhead must therefore increase it. Which is pretty much in the not-using-network-coding state we're in. You'd need to define your 'efficiency' metric very carefully here.

The network coding example isn't convincing IMO; doesn't discuss the difficulty of getting coding to the satellite at similar times. And the choice of symbols is not clear. "Moreover, with On-Board Processing satellite payloads, the coding operations could be done at the satellite level."

if a pig could fly, it would be a flying pig. Are we talking about network coding here? In the middle of a path? Are you alluding to the AmerHis example as some sort of DVB OBP best case? I have no idea. Network coding across multiple MF-TDMA uplinks and handling onboard would be... ambitious, and heavily restrict the flexibility of the payload to (as far as I can see) little benefit.

section 4.3 hybrid access

in Fig 5, given that curly brackets have been used as notation elsewhere, you'd do better drawing bidirectional links as <=>n rather than causing confusion with other diagrams and triggering LaTeX flashbacks. 4.4 varying capacity "recovered with higher layers" -- recovered with higher-layer...

"the usage of coding to cope with cases where channel condition can change in less than a second"

this is claiming that network coding, working on a longer path, is more useful than ACM working across just the satellite link from direct measurement of channel conditions. That's an unsupportable and untenable argument.

For this to be attempted, the coding overhead has to already be present, which is generally viewed as undesirable, due to satellite capacity costs, efficiency across the entire path, etc. I've spent years pointing out the need for checksums to people who don't think they're necessary. Someone who doesn't believe in checksums isn't going to believe in network coding...

4.5 gateway handovers

if doing a gateway handover to deal with really bad weather, equipment failure or site loss, network coding overhead won't help, and it won't be seamless.

"communalised" - I don't know what that word means in this context, or what European diplomatic language is doing here.

[NicoKos]

Tomaso : Concerning the comment on Section 4.5 "Gateway handover", I think it refers to the case where one wants to exploits the bandwidth of the "bad" gateway as much as possible and has however to take into account that gateway handover prediction algorithms show a non -negligible probability of missed detection. In this case, then network coding can avoid some losses, obviously at cost of some additional overhead (redundancy packets) transmitted through the "good" gateway. This scenario was partly studied in one of the activities carried out in the ESA co-funded SatNEx III project.

[NicoKos]

Tomaso : SGD stands for Smart Gateway Diversity. When I said that supporting to a reference destination satellite terminal does not come for free I was actually linking to your comment, i.e. that achieving the proposed concept requires some advanced design on the ground and space segments, which obviously might have some downside in terms of cost and complexity.

[NicoKos]

John Border : 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.)

[NicoKos]

John Border : 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.

[NicoKos]

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

[NicoKos]

Thank you all for these comments. I think most of them have been answer in PR #40