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

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

Tomaso: I agree with you. At the interim meeting in Cambridge last year we  had been clear that we were not addressing physical layer coding where symbols are bits bits and not packets. We had also discussed the fact that other SDOs were already covering physical layer coding hence no need for the IRTF (and by extension the IETF) to address this.

And as far as the lack of commercial implementations of NC and satellite we, in nwcrg, 1. have no problem with it as we focus on the research aspects of NC and 2. recognize that this could also be in some specific and proprietary implementation that we are not aware of yet. again justifying more research.


Marie-Jose Montpetit, Ph.D.
[e-mail]
[e-mail]
[phone]
@SocialTVMIT



> On Nov 8, 2018, at 6:47 PM, <[e-mail]> <[e-mail]> wrote:
> 
> 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