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

[<[e-mail]>]

Nicolas,

Just a quick comments about RFC 8406 you just mentioned to answer about the scope of network coding.

In the introduction is stated that:

"This document does not consider physical-layer transmission issues,
physical-layer codes, or error detection: if low-layer error codes
detect but fail to correct bit errors, or if an upper-layer checksum
(e.g., within IP or UDP) identifies a corrupted packet, then the
packet is supposed to be dropped."

As such I tend to exclude network coding as part of the physical layer, at least in the context of that RFC and I guess in the scope of this present I-D. One may want to talk about physical layer network coding, but this is in my view a different story...

Tomaso
> -----Original Message-----
> From: nwcrg [mailto:[e-mail]] On Behalf Of Kuhn Nicolas
> Sent: Thursday, November 08, 2018 12:03 PM
> To: Lloyd Wood; [e-mail]; [e-mail]
> Cc: Vincent Roca; Marie-Jose Montpetit; [e-mail]
> Subject: Re: [nwcrg] [dtn] Network Coding and SATCOM - call for review
> 
> 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]" <dtn-
> [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
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg