Re: [nwcrg] [dtn] Network Coding and SATCOM

Hi,

Thanks for your quick feedback and for the (very) relevant pointer.
We have just pushed a 02 version that we hope better assess your view.
We will still go for a full review before the end of November.

Thanks,
Cheers,

Nico

De : Tomaso.deCola@dlr.de <Tomaso.deCola@dlr.de>
Envoyé : lundi 12 novembre 2018 11:06
À : Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
Cc : marie@mjmontpetit.com; vincent.roca@inria.fr; nwcrg@irtf.org
Objet : RE: [dtn] Network Coding and SATCOM - call for review

Hi Nicolas,

Just a very quick comment related to section 4.6. When you talk about erasure coding for DTN in space missions  I suggest to also add a reference to the CCSDS orange book (experimental standard) on erasure coding, which was defined to work below BP, LTP or even CFDP, although it was exemplified especially for LTP.

Moreover I’m a bit confused about the following text:

“Another proposal is the use of erasure coding inside the CCSDS (Consultative Committee for Space Data
   Systems) architecture [COLA11].  The objective is to extend the CCSDS File Delivery Protocol (CFDP) [CCSDS-FDP] with erasure coding
   capabilities where a Low Density Parity Check (LDPC) [RFC6816] code with a large block size is chosen.”

When you say “the objective is to extend […]”, do you refer to what discussed in reference [COLA11] or is a general statement? If the former please note that that reference does not address exclusively CFDP but also considers the case of erasure coding applied with BP and LTP, taking also into account what was at that time in preparation for the aforementioned CCSDS orange book which was published then just a few years later. Still on this point, you refer to RFC6816, again if you refer to the text of [COLA11], this is not fully correct since the work carried out in CCSDS was certainly inspired by RFC 6816 but it was in fact developed independently.

In case you had other comments or needed any details about the work done in this context, please let me know.

Regards,

Tomaso

From: Kuhn Nicolas [mailto:Nicolas.Kuhn@cnes.fr]
Sent: Monday, November 12, 2018 10:40 AM
To: Marie-Jose Montpetit; Cola, Tomaso de
Cc: lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk>; dtn@ietf.org<mailto:dtn@ietf.org>; dtn-chairs@ietf.org<mailto:dtn-chairs@ietf.org>; vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>; nwcrg@irtf.org<mailto:nwcrg@irtf.org>
Subject: RE: [dtn] Network Coding and SATCOM - call for review

Dear all,

Following the recent discussions, we have uploaded a new version of the draft.
We plan on further working on it before the end of November.

In the meantime, do not hesitate to let us know if you have further opinions on it.
In particular, we have a section on DTN and network coding that may be of interest for the DTN WG: https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-01#section-4.6
The DTN RG documents that we point are surely outdated, so we would be happy to have more relevant pointers.

Kind regards,

Nicolas KUHN
CNES/DSO/NT/ST
(+33)5 61 27 32 13

De : Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>
Envoyé : jeudi 8 novembre 2018 15:49
À : Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de>
Cc : Kuhn Nicolas <Nicolas.Kuhn@cnes.fr<mailto:Nicolas.Kuhn@cnes.fr>>; lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk>; dtn@ietf.org<mailto:dtn@ietf.org>; dtn-chairs@ietf.org<mailto:dtn-chairs@ietf.org>; vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>; nwcrg@irtf.org<mailto:nwcrg@irtf.org>
Objet : Re: [dtn] Network Coding and SATCOM - call for review

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.
mariejo@mit.edu<mailto:mariejo@mit.edu>
marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>
+1-781-526-2661
@SocialTVMIT

On Nov 8, 2018, at 6:47 PM, <Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de>> <Tomaso.deCola@dlr.de<mailto:Tomaso.deCola@dlr.de>> 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:nwcrg-bounces@irtf.org] On Behalf Of Kuhn Nicolas
Sent: Thursday, November 08, 2018 12:03 PM
To: Lloyd Wood; dtn@ietf.org<mailto:dtn@ietf.org>; dtn-chairs@ietf.org<mailto:dtn-chairs@ietf.org>
Cc: Vincent Roca; Marie-Jose Montpetit; nwcrg@irtf.org<mailto:nwcrg@irtf.org>
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
(+33)5 61 27 32 13

-----Message d'origine-----
De : Lloyd Wood <lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk>>
Envoyé : mercredi 7 novembre 2018 02:51
À : Kuhn Nicolas <Nicolas.Kuhn@cnes.fr<mailto:Nicolas.Kuhn@cnes.fr>>; dtn@ietf.org<mailto:dtn@ietf.org>; dtn-chairs@ietf.org<mailto:dtn-chairs@ietf.org>
Cc : Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>>; Marie-Jose Montpetit
<marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>
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 lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> http://about.me/lloydwood

________________________________
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr<mailto:Nicolas.Kuhn@cnes.fr>>
To: "dtn@ietf.org<mailto:dtn@ietf.org>" <dtn@ietf.org<mailto:dtn@ietf.org>>; "dtn-chairs@ietf.org<mailto:dtn-chairs@ietf.org>" <dtn-
chairs@ietf.org<mailto:chairs@ietf.org>>
Cc: Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>>; Marie-Jose Montpetit
<marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>; Kuhn Nicolas <Nicolas.Kuhn@cnes.fr<mailto:Nicolas.Kuhn@cnes.fr>>
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
dtn@ietf.org<mailto:dtn@ietf.org>
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
nwcrg mailing list
nwcrg@irtf.org<mailto:nwcrg@irtf.org>
https://www.irtf.org/mailman/listinfo/nwcrg