Re: [nwcrg] [dtn] Network Coding and SATCOM - call for review

[Kuhn Nicolas <[e-mail]>]

Dear Lloyd, 

Thank you for your feedback. 
Please find some comments inline.
We are working on an updated version of the draft that we would release as a consequence. 

FYI, I cc the NWCRG list. 

Kind regards,

Nicolas KUHN
CNES/DSO/NT/ST
([phone]


-----Message d'origine-----
De : Lloyd Wood <[e-mail]> 
Envoyé : mercredi 7 novembre 2018 02:51
À : Kuhn Nicolas <[e-mail]>; [e-mail]; [e-mail]
Cc : Vincent Roca <[e-mail]>; Marie-Jose Montpetit <[e-mail]>
Objet : Re: [dtn] Network Coding and SATCOM - call for review

Nico,

This document appears to be intended for the DVB-S2 community, and is likely better as a contribution to the appropriate DVB forum (which is to say, ETSI). Certainly not an IETF document, whether it's suitable for IRTF is a tossup, really.
> [NK] Well - at some point in the past, the IRTF (and not IETF) Network Coding Research Group needed some use-cases documents to assess the gaps between the codes that are developed and their applicability/deployment. The research challenge and gap analysis is one of the core activity of the IRTF.  The goal of this document falls in the scope of trying to make links between academic activities and industrial deployments : " We have noticed an active research activity on how network coding and SATCOM in the past. That being said, not much has actually made it to industrial developments". Whether this document is in the scope of some ETSI standardization activity or not at the moment, we believe that to help network coding codes to make it out in industrials products, the IETF is a good place. 


Speaking as a satellite network operator, this document shows very little awareness of why network coding doesn't get used widely in satellite networks.
> [NK] We have asked for help in the NWCRG mailing and had few industrial feedback. I totally agree that we may not have the whole knowledge on why it did not made it out. The thing we could do was focusing in identifying interesting use-cases so that the network coding could make it out at a wider scale this time. If you want to contribute and provide information on why network coding did not made it out in the past, this could clearly improve the draft. 


"NC is an inherent part of the physical layer of satellite systems"
that's not network coding...
> [NK] I agree that this could be considered as FEC, but we tried to be consistent with the RFC 8406. This draft uses the term NC as a generic term. 
 
"Moreover, with On-Board Processing satellite payloads, the network coding operations could be done at the satellite level, thus reducing the end-to-end delay of the communication."

that might reduce end-to-end delay of resend, but in reality the major gain would be in improvement of return channel MAC allocation and resend algorithms by doing it onboard, shortening that feedback loop and improving slot allocation...
and that is not network coding.
> [NK] This use-case results in important resource savings. Moreover, the demonstration that supported it was an important move in showing to people some strength of network coding - which is one of the reasons we speak about it.  We do not speak about the MAC mechanisms underneath in this case because depending on how you could do it, there are multiple possible aspects (e.g. one could use SCPC channels). 


Network coding is of little use when the satellite link has very different characteristics to other links, and those can vary.  Which is why satellite links (such as the Ka-band ones I'm using) deploy adaptive coding and modulation (ACM) tailored to the link. Why impose coding overhead on the entire network simply because one hop is different?
> [NK] There are cases where the ACM mechanisms are not enough (mobile users / important channels fading) and a recovery mechanism at a higher layer is relevant since errors could be recovered within one RTT (at a cost of supplementary resource). The higher layer scheme could work at a different timing scale as the ACM could. This is what we try to say in section 4.4 (https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-00#section-4.4) but it may not be clear enough?


"This use-case considers the usage of network coding to overcome cases where the wireless link characteristics quickly change overtime and where the physical layer codes could not be made robust in time."

this claims that network coding can be faster than per-link ACM?
I don't think so. Claiming that whatever happens at layer 2 or below is a redefined network coding seems like a dodge to make network coding seem more relevant.
> [NK] We do not claim to replace ACM mechanisms (or be faster) but we believe that there are cases where adding high layer redundancy can help in reducing transmission delays. This is, e.g., why QUIC is considering NC at the application layer. We have added some content in the next version of the draft to make that clearer. 


"increase the reliability and/or the total bandwidth"

increase the total bandwidth? What does total bandwidth mean here?
it's not MHz...
> [NK] It is indeed not MHz but Bits/per/sec. We change it to "capacity" and hope this is clearer. 



independant -- independent
> [NK] Thanks.

network coding schemes could be proposed as VNF -- or NFV? typo?
or just not defining abbreviations?
> [NK] We are indeed speaking about virtual network function (VNF). We will make that clearer in the next version.  

Is the DTN section at all useful?

"DTN can also be seen as an alternative solution to cope with satellite communications usually managed by PEP."
academic papers may well tell you that, but their sources are only other academic papers. A sponge can be seen as a torque wrench, but it's still a sponge.
> [NK] There is another email's discussion on this topic and I will be back on it ASAP. 
For the usefulness of the DTN section, before going towards a working group last call, we have been kindly asked to have discussion with the DTN group. 
We indeed have some old pointers and would be happy to hear about more recent activity in the interactions between DTN and NC.

"This document presents presents the current deployment of network coding in some satellite telecommunications system"

Where? I completely missed any discussion of practical deployment (presents presents?)
> [NK] Thank for the typo. I think the confusion comes from the fact that physical layer FEC are considered as NC and also we have quickly mention that applications may use NC. This is discussed in section 3 (https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-00#section-3). 


"5.  Research challenges

5.1.  Deployability in current SATCOM systems"

Never getting deployed is a challenge of relevance, certainly.
> [NK] Indeed. 


"discussion on the multiple opportunities to introduce these techniques at a wider scale."

techniques not being used for good reason will continue to not be used for good reason. I don't think this document in its current form makes the case for their wider adoption.
> [NK] These techniques are interesting for many use cases. I agree that making it integrated in multiple systems is complexed. That being said, I believe that a content provider (in a CDN) could be interested in integrated NC mechanisms. I hope that the answer provided in this email make our draft clearer on the opened aspects.  


regards

 
Lloyd Wood [e-mail] http://about.me/lloydwood



________________________________
From: Kuhn Nicolas <[e-mail]>
To: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
Cc: Vincent Roca <[e-mail]>; Marie-Jose Montpetit <[e-mail]>; Kuhn Nicolas <[e-mail]>
Sent: Monday, 5 November 2018, 14:50
Subject: [dtn] Network Coding and SATCOM - call for review




Dear all, 
 
We have been working on a « network coding and satellites » document at NWCRG: https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-00 
We have a section on DTN and network coding that may be of interest for your group: https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-00#section-4.6 
The DTN RG documents that we point to are surely outdated, so we would be happy to have more relevant pointers. 
 
We would also need any volunteers to review the document since it is soon-to-be in WGLC. 
I would be around in the DTN working group meeting on Thursday. Let me know if you want to have a chat on this document. 
 
Thanks,
 
Nico
 _______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn