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

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 8 Nov 2018 11:03:21 +0000

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 <[email-masked]> 
Envoyé : mercredi 7 novembre 2018 02:51
À : Kuhn Nicolas <[email-masked]>; [email-masked]; [email-masked]
Cc : Vincent Roca <[email-masked]>; Marie-Jose Montpetit <[email-masked]>
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 [email-masked] http://about.me/lloydwood

________________________________
From: Kuhn Nicolas <[email-masked]>
To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: Vincent Roca <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; Kuhn Nicolas <[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: <[email-masked]>
Date: Thu, 8 Nov 2018 11:47:12 +0000

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 8 Nov 2018 21:48:59 +0700

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.
[email-masked]
[email-masked]
+1-781-526-2661
@SocialTVMIT

> On Nov 8, 2018, at 6:47 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Nicolas,
>

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 12 Nov 2018 09:39:50 +0000

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 <[email-masked]>
Envoyé : jeudi 8 novembre 2018 15:49
À : [email-masked]
Cc : Kuhn Nicolas <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [dtn] Network Coding and SATCOM - call for review

Marie-Jose Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
+1-781-526-2661
@SocialTVMIT

On Nov 8, 2018, at 6:47 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Nicolas,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
Sent: Thursday, November 08, 2018 12:03 PM
To: Lloyd Wood; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Vincent Roca; Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>
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.

Kind regards,

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

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

Nico,

[NK] It is indeed not MHz but Bits/per/sec. We change it to "capacity" and
hope this is clearer.

[NK] Thanks.

[NK] We are indeed speaking about virtual network function (VNF). We will
make that clearer in the next version.

"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.

Where? I completely missed any discussion of practical deployment
(presents presents?)

"5.  Research challenges

[NK] Indeed.

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

regards

Lloyd Wood [email-masked]<mailto:[email-masked]> http://about.me/lloydwood

________________________________
From: Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <dtn-
[email-masked]<mailto:[email-masked]>>
Cc: Vincent Roca <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit
<[email-masked]<mailto:[email-masked]>>; Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: <[email-masked]>
Date: Mon, 12 Nov 2018 10:05:46 +0000

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:[email-masked]]
Sent: Monday, November 12, 2018 10:40 AM
To: Marie-Jose Montpetit; Cola, Tomaso de
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dtn] Network Coding and SATCOM - call for review

Dear all,

Kind regards,

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

Nicolas,

Tomaso
-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
Sent: Thursday, November 08, 2018 12:03 PM
To: Lloyd Wood; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Vincent Roca; Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>
Subject: Re: [nwcrg] [dtn] Network Coding and SATCOM - call for review

Dear Lloyd,

Kind regards,

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

-----Message d'origine-----
De : Lloyd Wood <[email-masked]<mailto:[email-masked]>>
Envoyé : mercredi 7 novembre 2018 02:51
À : Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : Vincent Roca <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit

Nico,

"5.  Research challenges

regards

Dear all,

Thanks,

Nico

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 12 Nov 2018 17:40:49 +0000

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 : [email-masked] <[email-masked]>
Envoyé : lundi 12 novembre 2018 11:06
À : Kuhn Nicolas <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : RE: [dtn] Network Coding and SATCOM - call for review

Hi Nicolas,

Regards,

Tomaso

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear all,

Kind regards,

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

De : Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>
Envoyé : jeudi 8 novembre 2018 15:49
À : [email-masked]<mailto:[email-masked]>
Cc : Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [dtn] Network Coding and SATCOM - call for review

Nicolas,

Tomaso
-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
Sent: Thursday, November 08, 2018 12:03 PM
To: Lloyd Wood; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Vincent Roca; Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>
Subject: Re: [nwcrg] [dtn] Network Coding and SATCOM - call for review

Dear Lloyd,

Kind regards,

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

-----Message d'origine-----
De : Lloyd Wood <[email-masked]<mailto:[email-masked]>>
Envoyé : mercredi 7 novembre 2018 02:51
À : Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : Vincent Roca <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit

Nico,

"5.  Research challenges

regards

Dear all,

Thanks,

Nico

---

From: Emmanuel Lochin <[email-masked]>
Date: Tue, 13 Nov 2018 01:27:44 +0100

Dear Tomaso,

Le 12/11/2018 à 11:05, [email-masked] a écrit :
> 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.

This was more a general statement but we are going to rewrite this part 
taking into account your remark.

Emmanuel

-- 

Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/

"Tomorrow is our purpose": 
découvrez le nouveau film de marque de l'ISAE-SUPAERO !
discover the new ISAE-SUPAERO brand film!

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 14 Nov 2018 02:35:04 +0000 (UTC)

Likely relevant to this draft:

Can network coding bridge the digital divide in the Pacific?, Spiedel et al.,
International Symposium on Network Coding (NetCod), Sydney, June 2015.

http://arxiv.org/abs/1506.01048
http://dx.doi.org/10.1109/NETCOD.2015.7176795
https://internetnz.nz/sites/default/files/IR201404%20-%20University%20of%20Auckland%20-%20FINAL%20REPORT%20April%202015.pdf
https://conference.apnic.net/data/41/apricot-talk_1451964216_1456023873.pdf

My take from years of using a very large number of TCP accelerators across satellite
links is that:

- the performance benefits from the local file/stream/chunk/'object' rapid fetch
  from Internet side and cached delivery that they offer for the satellite link
  will far outweigh benefits of network coding across the path and its virtual
  'erasure channel' for responsiveness, but that's hard to see from a throughput
  graph.

- the over-satellite-link FEC feature offered is rarely that useful in practice,
  as channel coding makes it largely redundant. If the PEP accelerator FEC becomes

  useful, the channel coding needs to be adjusted for the SNR, and that's often

  a local ACM problem, e.g. heavy rain fade at Ka-band, which the O3b example used
  in the paper suffers from.

- there's a whole bunch of tuning of traffic for the offered satellite link
  capacity (QoS, prioritisation, shaping, etc) brought to the table by PEPs
  that network coding cannot consider. Sometimes this gets called 'Orchestration',
  though that means different things to different communities.

oh, draft typo: writting->writing. Haven't had the time to reread
and think about the whole draft revision yet.

L.

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 13 Nov 2018 19:28:34 -0800

Yes this is a study done a few years ago.

Marie-José Montpetit
[email-masked]
[email-masked]

> On Nov 13, 2018, at 6:35 PM, Lloyd Wood <[email-masked]> wrote:
>

---

From: Muriel Medard <[email-masked]>
Date: Wed, 14 Nov 2018 03:35:56 +0000

Dear all,

Actually, the experiments are ongoing and extensive, so there is a lot more data.

Best,

Muriel

Muriel Médard
Cecil H. Green Professor of EECS
Massachusetts Institute of Technology.

On Nov 13, 2018, at 10:28 PM, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

Marie-José Montpetit

L.

---

From: Emmanuel Lochin <[email-masked]>
Date: Wed, 14 Nov 2018 07:05:15 +0100

Hi Marie-Jo, all,

Following one of your request, we (Muriel, I and others) did the work in 
2013 to reference NC papers as the one below. It was expected to store 
(and update) the list over a wiki page. May be this will be a good thing 
for newcomers in the group to have this list.

EL

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 14 Nov 2018 03:02:52 -0800

Good idea.

mjm

> On Nov 13, 2018, at 10:05 PM, Emmanuel Lochin <[email-masked]> wrote:
> 
> Hi Marie-Jo, all,
> 
> Following one of your request, we (Muriel, I and others) did the work in 2013 to reference NC papers as the one below. It was expected to store (and update) the list over a wiki page. May be this will be a good thing for newcomers in the group to have this list.
> 
> EL
> 
> "Tomorrow is our purpose": découvrez le nouveau film de marque de l'ISAE-SUPAERO !

---

From: "Kerim Fouli" <[email-masked]>
Date: Fri, 16 Nov 2018 15:17:50 -0500

Hi Lloyd,

Thank you for the interesting point on Sat links and network coding. Coding
and PEPs are certainly not mutually exclusive, and coding has a lot to offer
on the caching side that is not represented in the article either.

However, there may still be other gains purely at the link level: The
attached white paper illustrates that a network-layer code can allow the PHY
code to let through more errors, leading to link budget gains.  

Best,

Kerim

-----Original Message-----
From: nwcrg <[email-masked]> On Behalf Of Lloyd Wood
Sent: Tuesday, November 13, 2018 9:35 PM
To: Kuhn Nicolas <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nwcrg] [dtn] Network Coding and SATCOM - call for review

Can network coding bridge the digital divide in the Pacific?, Spiedel et
al., International Symposium on Network Coding (NetCod), Sydney, June 2015.

http://arxiv.org/abs/1506.01048
http://dx.doi.org/10.1109/NETCOD.2015.7176795
https://internetnz.nz/sites/default/files/IR201404%20-%20University%20of%20A
uckland%20-%20FINAL%20REPORT%20April%202015.pdf
https://conference.apnic.net/data/41/apricot-talk_1451964216_1456023873.pdf

My take from years of using a very large number of TCP accelerators across
satellite links is that:

- the performance benefits from the local file/stream/chunk/'object' rapid
fetch
  from Internet side and cached delivery that they offer for the satellite
link
  will far outweigh benefits of network coding across the path and its
virtual
  'erasure channel' for responsiveness, but that's hard to see from a
throughput
  graph.

- the over-satellite-link FEC feature offered is rarely that useful in
practice,
  as channel coding makes it largely redundant. If the PEP accelerator FEC
becomes

  useful, the channel coding needs to be adjusted for the SNR, and that's
often

  a local ACM problem, e.g. heavy rain fade at Ka-band, which the O3b
example used
  in the paper suffers from.

- there's a whole bunch of tuning of traffic for the offered satellite link
  capacity (QoS, prioritisation, shaping, etc) brought to the table by PEPs
  that network coding cannot consider. Sometimes this gets called
'Orchestration',
  though that means different things to different communities.

oh, draft typo: writting->writing. Haven't had the time to reread and think
about the whole draft revision yet.

L.