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

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 5 Nov 2018 03:50:05 +0000

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

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 05 Nov 2018 11:02:40 +0700

On 5 Nov 2018, at 10:50, Kuhn Nicolas wrote:

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

Would you come to the mike during the DTN session and « advertise » 
it?  And then sending an email to the dtn wg mailing list about this.

Marc.

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 7 Nov 2018 01:51:10 +0000 (UTC)

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.

Speaking as a satellite network operator, this document shows
very little awareness of why network coding doesn't get used
widely in satellite networks.

"NC is an inherent part of the physical layer of satellite systems"
that's not network coding...

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

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?

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

"increase the reliability and/or the total bandwidth"

increase the total bandwidth? What does total bandwidth mean here?
it's not MHz...

independant -- independent

network coding schemes could be proposed as VNF -- or NFV? typo?
or just not defining abbreviations?

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.

"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?)

"5.  Research challenges

5.1.  Deployability in current SATCOM systems"

Never getting deployed is a challenge of relevance, certainly.

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

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. 

Thanks,
 
Nico
 _______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Carlo Caini <[email-masked]>
Date: Wed, 7 Nov 2018 09:24:04 +0000

Dear Lloyd,
      I do not intend to enter the topic, i.e. 
Network Coding and Satcom, but I can't help 
presenting my comments on your phrase:
>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.

To the best of my knowledge I was the first 
researcher that studied the possible usefulness 
of DTN architecture when applied to GEO satellite 
systems. The most important paper I published on this topic is the following:

Carlo Caini, Haitham Cruickshank, Stephen Farrell, and Mario Marchese
Delay- and Disruption-Tolerant Networking (DTN): 
An Alternative Solution for Future Satellite Networking Applications
IEEE Proceedings, 2011, 99, pp. 1980 - 1997 DOI: 
<https://doi.org/10.1109/JPROC.2011.2158378>10.1109/JPROC.2011.2158378

In the paper an approach based on DTN is compared 
with end-to-end TCP (NewReno or Hybla) and TCP 
splitting PEPs. These techniques are compared in 
a scenario with fixed terminals (no disruptions, 
Fig.5) and in a scenario with mobile terminal 
(disruptions due to railways tunnels, Fig.7). My 
comments on the first scenario is that
>The best performance is achieved by PEPsal, 
>which takes advantage of both Hybla and the 
>reduced RTT (575 ms) on the satellite 
>connection. DTN reaches basically the same 
>performance as PEPsal, due to the similarity between the two architectures

on the second:
>the qualitative behaviour is the same as without 
>disruptions, except that, in this case, it is 
>DTN, and not PEPsal, that offers the best 
>performance. The difference however, is slight, but real.

I can add that both TCP splitting PEPs and DTN 
architectures are very effective and produce 
similar results  (they have in common the fact 
that the TCP connection is split) but  they have 
different pros and cons. The main advantage of 
PEPs is that they are transparent, which is also 
their main disadvantage, as their violation of 
the end-to-end semantic of TCP is not for free, as you certainly know.

That said, you can either agree or disagree with 
my comments, but these were based on facts, not 
previous Academic papers citing other papers. 
Results presented in Figure 5 and 7 were entirely 
original, and obtained by means of a real tesbed 
(TATPA) running the full protocol stack 
(GNU/Linux etc.). I still have the original data 
and also the original testbed (now so old to be 
suitable for a Computer Science museum...).

I am aware that the need of having paper 
published and cited has brought as a side effect 
a decline of average thoroughness of scientific 
papers authored by academic researchers, but 
there are a few exceptions. I am personally aware 
that the "Nature is an open book written in 
mathematical characters", as said by Galileo 
Galilei, and that scientific comments must not be 
based on comments by other researchers but on 
observations, i.e. on numbers obtained by means 
of reproducible experiments. In current plain 
language "talk is cheap, show me the code" (by 
Linus Torvalds).  This is what I have always done.

Yours sincerely,
      Carlo Caini

At 02:51 07/11/2018, Lloyd Wood wrote:
>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. Speaking as a satellite network 
>operator, this document shows very little 
>awareness of why network coding doesn't get used 
>widely in satellite networks. "NC is an inherent 
>part of the physical layer of satellite systems" 
>that's not network coding... "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. 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? "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. 
>"increase the reliability and/or the total 
>bandwidth" increase the total bandwidth? What 
>does total bandwidth mean here? it's not MHz... 
>independant -- independent network coding 
>schemes could be proposed as VNF -- or NFV? 
>typo? or just not defining abbreviations? 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. "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?) "5.  Research challenges 
>Never getting deployed is a challenge of 
>relevance, certainly. "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. 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: 
>We have a section on DTN and network coding that 
>may be of interest for your group: 
>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] 
>dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 7 Nov 2018 12:57:08 +0000 (UTC)

Carlo,

thanks for your comment, which might just prove my point.

Your Proceedings paper compares DTN against PEPsal, a TCP
accelerator written by your team as yes, another academic

exercise. (An academic paper cited as reference 38.)
That's an entirely worthy effort, and quite

laudable. Bravo, etc. I am not criticizing you for
having achieved that.

However, concluding that something you wrote performed

similarly to something else you wrote (based on the
same code and architecture, even, so getting similar
performance may not be that surprising) is a conclusion
of limited generality. More importantly, it ignores the
existence of all the commercial shipping TCP accelerator
devices, and how well they perform, to establish a
baseline for comparison. And, since there's a market
for those devices, they must perform, somehow. (Show me the
money...)

Did you test PEPsal performance against some that of some

commercial PEP devices(on loan, say) to get a feel for how
well the performance comparison and conclusion that
your DTN implementation is comparable to a PEP holds up?
While the commercial devices don't make code available,
it is certainly possible to observe their performance
with experiments in the interest of enquiry.

Whether you did or didn't do that would be a very
interesting fact.
best

L.

has qualms about the whole 'academia ignores industry
but then tells industry what best practice it should be
adopting' thing in general. Lucky that industry ignores
academia too, eh?

________________________________
From: Carlo Caini <[email-masked]>
To: Lloyd Wood <[email-masked]>; Kuhn Nicolas <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: Vincent Roca <[email-masked]>; Marie-Jose Montpetit <[email-masked]>
Sent: Wednesday, 7 November 2018, 20:24
Subject: Re: [dtn] Network Coding and SATCOM - call for review

Dear Lloyd,

Yours sincerely,
      Carlo Caini

---

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. 

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

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

> [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

Dear all, 

 
Thanks,
 
Nico

---

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?
> 
> 
> 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.
> 
> > [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
> 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.

"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