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

[Marie-Jose Montpetit <[e-mail]>]

Thanks Tomaso!

And thanks of course to Lloyd for having taken the time to provide detailed comments. I will leave the authors to respond specifically to each point. 

But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.

mjm

Marie-Jose Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
[e-mail]
[e-mail]
[phone]
@SocialTVMIT



> On Apr 29, 2019, at 8:49 AM, <[e-mail]> <[e-mail]> wrote:
> 
> Dear Lloyd,
> 
> 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.
> 
> In case you needed more details, please let me know.
> 
> Best Regards,
> 
> Tomaso
> 
> -----Original Message-----
> From: nwcrg [mailto:[e-mail]] On Behalf Of Lloyd Wood
> Sent: Monday, April 29, 2019 9:19 AM
> To: Vincent Roca; [e-mail]
> Cc: Marie-Jose Montpetit
> Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"
> 
> This draft is not yet ready imo.
> As in previous reviews, the trivial issues are unfortunately masking the deeper issues with what the draft is for. Comments on trivial and deeper issues in order on the draft below.
> 
> abstract
> 
>   This memo details a multi-gateway satellite system to identify
>   multiple opportunities on how *network* coding techniques could be deployed at
>   a wider scale.
> 
> 
> this is talking about *network* coding, and this draft needs to be perfectly clear throughout that it is doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading. Blurring the coding case is not helping your cause.  I called this out previously. This is important.
> 
> 
> Introduction
> physical-layer reliability mechanisms -- hyphenate adjectival terms
> style: e.g. should be in a clause separated by commas, not brackets.
> 
> 500 ms one-way _delivery_ delay (or path -- i.e. not propagation)
> 
> "However, physical layer reliability mechanisms may not
> recover transmission losses (e.g. with a mobile user) and layer 2 (or
> above) re-transmissions induce 500 ms one-way delay with a
> geostationary satellite"
> 
> Look, forward error coding (FEC) and link ACKs are complementary on a sliding scale depending on delay/channel quality, and this is talking solely about retransmissions. In fact, link or channel FEC do recover a large number of transmission bit/symbol losses without adding extra delay.
> 
> 
> "We have noticed an active research activity on coding and SATCOM in the past."
> -- if it's active, it's not in the past.
>   if it's in the past, it's not active.
> Do you mean 'in the past we have noticed'? that's redundant.
> 
> 
> "In this context, this document aims at identifying opportunities for further usage of coding in these systems."
> 
> again, _network_ coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.
> 
> 
> ACM : Adaptative Coding and Modulation;
> -- Adaptive. This error repeats.
> CPE: Customer Premise Equipment;
> -- Premises. (My premise is that this is unfortunate.)
> 
> 
> FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help.
> 
> 
> FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo.
> 
> 
> PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's _Enhancing_ and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for.
> 
> 
> PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
> 
> 
> Don't hyphenate the Qualities.
> section 2
> 
> 
> "This section describes the components in satellite system that layson SATCOM systems dedicated to broadband Internet access that follows
> the DVB standards"
> 
> -- This section describes the components of a satellite system that follows the ETSI DVB standards to provide broadband internet access. (Actually, DVB-S standards).
> 
> Following the DVB standards has effects on draft scope and terminology. Are you sure you want to do that? The current approach to DVB-S seems to be to pick and choose whatever is convenient to the argument.
> 
> 
> A high-level description of a multi-gateway _satellite_ network is provided.
> 
> "a bi-directional' - elide a, elide -
> Fig 1 doesn't resemble the multi-gateway DVB satellite systems that I have worked on.
> 
> 
> Indoor and outdoor unit typically refers to the customer satellite terminal pieces as well, not jut a piece of the gateway. (Indoor - network to/from intermediate frequency IF. Outdoor: IF to/from RF) The satellite link appears to be in the wrong place, or the terminal needs breaking down further. And there's no mention of FECFRAME? PLFRAME is the structure, the data gets turned into FECFRAME. But that has "FEC" in it and this draft aims to downplay FEC... awks. Encaps like GSE or MPE have been skipped, but that's really just added flavour.
> 
> 
> Section 3 Actual deployment
> this is cherrypicking, not discussing link/channel FEC (Error) or ACK.
> 
> 
> the heading should really be 'of network coding schemes'.
> 
> "to cover cases where where"?
> 
> At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error?
> 
> "Based on public information, coding does not seem to be widely used at higher layers."
> it isn't, and that section can be reduced to just that sentence.
> 
> Section 4
> 
> 
> "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.
> 
> 
> 5.2. Interaction with virtualization
> 
> I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that.
> 
> chin-nfvrg-cloud-5g-core-structure-yang
> referring to an expired -00 internet-draft does not add credibility.
> 
> 
> 5.3 delay-tolerant
> 
> legitimate -> legitimize.
> 
> This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case.
> Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references.
> EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.
> 
> 
> I could write more and go into other diagrams in detail, but I'm not sure that the added effort would be worthwhile.
> 
> The draft scope, intent and underlying purpose need a rethink IMO. And lack of comments from other group members would be an indication of... something, and I'm not sure what.
> 
> 
> regards
> 
> Lloyd Wood [e-mail] http://about.me/lloydwood
> 
> 
> 
> 
> 
> 
> ________________________________
> From: Vincent Roca <[e-mail]>
> To: [e-mail] 
> Cc: Vincent Roca <[e-mail]>; Marie-Jose Montpetit <[e-mail]>
> Sent: Thursday, 18 April 2019, 15:42
> Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"
> 
> 
> 
> 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/
> 
> 
> We would like to collect your comments by Thursday 9th, May (3 weeks).
> 
> 
> Thanks in advance.
> 
> 
>    Marie-Jose and Vincent
> 
> _______________________________________________
> 
> nwcrg mailing list
> 
> [e-mail]
> 
> https://www.irtf.org/mailman/listinfo/nwcrg
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg