Subject: [nwcrg] TR: New Version Notification for draft-kuhn-nwcrg-network-coding-satellites-02.txt

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 26 Feb 2018 15:30:58 +0000

Dear all,

We have provided some more content to the "NC and SATCOM" document.
All comments are welcome. 

We plan on further work on this document before the official cut-off. 
Let us know if you are willing to contribute to this document.

Kind regards, 

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

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 26 février 2018 16:25
À : Kuhn Nicolas <[email-masked]>; Emmanuel Lochin <[email-masked]>
Objet : New Version Notification for draft-kuhn-nwcrg-network-coding-satellites-02.txt

A new version of I-D, draft-kuhn-nwcrg-network-coding-satellites-02.txt
has been successfully submitted by Nicolas Kuhn and posted to the IETF repository.

Name:		draft-kuhn-nwcrg-network-coding-satellites
Revision:	02
Title:		Network coding and satellites
Document date:	2018-02-25
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-kuhn-nwcrg-network-coding-satellites-02.txt
Status:         https://datatracker.ietf.org/doc/draft-kuhn-nwcrg-network-coding-satellites/
Htmlized:       https://tools.ietf.org/html/draft-kuhn-nwcrg-network-coding-satellites-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-kuhn-nwcrg-network-coding-satellites-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-kuhn-nwcrg-network-coding-satellites-02

Abstract:
   This memo presents the current deployment of network coding in some
   satellite telecommunications systems along with a discussion on the
   multiple opportunities to introduce these techniques at a wider
   scale.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: <[email-masked]>
Date: Tue, 27 Feb 2018 15:48:46 +0000

Dear Nicolas,

Some comments to the I-D from my side:

1) General: since the draft is supposed to be informational, therefore not containing any normative text, I don't think normative references are necessary.

2) Section 2, end of page 2: there is a mention on how to map the considered architecture to cellular system. I'm wondering whether this is really necessary since the I-D deals only with satellite systems.

3) Section 5.1: you may want to add a reference to ASMS demonstration in Cagliari. Moreover, in the general description of the two-way relay channel, it could be worth mentioning that in case of OBP payload, network coding operations could be even directly implemented there.

4) Section 5.2: is there any difference with what can be done with NORM?

5) Section 5.3: it refers to " [I-D.boucadair-mptcp-dhc]" for the multi-link architecture. As a matter of fact, that I-D is more dedicated to DHCP implications. I'd rather refer to the recently published ETSI TR dealing with MPTCP and multi-link architectures, output of the BATS project.

6) Section 5.5: it is not clear to me how network coding can help in the case of variable link capacity. Probably some more details would be helpful. Is it about recovering congestion losses due to bottleneck created by sudden capacity reduction (although if one uses ACM with Ka-band the rate reduction should be gradual)? If on the other hand the use case is about feeder link outage I guess network coding could be an interesting option once dealing with gateway handover. The use of network coding to just cope with the losses occurring on a given feeder link looks to me a bit critical from a deployment/implementation viewpoint, because of the duration of these outage events and the consequent number of losses.

7) Section 6: I read from the last lines " how network coding can be integrated inside a PEP with QoS scheduler has been proposed in RFC 5865 [RFC5865]." As far as I can remember from that RFC, there is almost no mention about PEP and network coding integration. Did you mean something different maybe?

Hope it can help. I'm in any case obviously available for further iterating on my comments.

Best Regards,

Tomaso

———————————————————————— 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
http://www.dlr.de/kn/institut/abteilungen/san 

> -----Original Message-----
> From: nwcrg [mailto:[email-masked]] On Behalf Of Kuhn Nicolas
> Sent: Monday, February 26, 2018 4:31 PM
> To: [email-masked]
> Subject: [nwcrg] TR: New Version Notification for draft-kuhn-nwcrg-network-
> coding-satellites-02.txt
> 
> Dear all,
> 
> De : [email-masked] [mailto:[email-masked]] Envoyé : lundi 26
> février 2018 16:25 À : Kuhn Nicolas <[email-masked]>; Emmanuel Lochin
> <[email-masked]> Objet : New Version Notification for draft-
> kuhn-nwcrg-network-coding-satellites-02.txt
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Emmanuel Lochin <[email-masked]>
Date: Tue, 27 Feb 2018 18:10:44 +0100

Dear Tomaso,

Many thanks for your feedback, some comments in-line (I let Nicolas to 
correct/complete).

> 3) Section 5.1: you may want to add a reference to ASMS demonstration in Cagliari. Moreover, in the general description of the two-way relay channel, it could be worth mentioning that in case of OB…
You are free to propose or directly write inside the draft a 
modification of this section.
> 4) Section 5.2: is there any difference with what can be done with NORM?
NORM is one possible option and the illustration proposed might suggest 
its use. However NORM is only FEC-based.
This part seeks to consider other network coding schemes such as sliding 
window encoding (described in the taxonomy draft), where some real 
implementations exist enabling a reliable multicast service.

> 6) Section 5.5: it is not clear to me how network coding can help in the case of variable link capacity. Probably some more details would be helpful. Is it about recovering congestion losses due to…
Correct, we need to better explain. In brief we consider a scenario 
where losses occur due to link impairments over, for instance, a BGAN.
> 7) Section 6: I read from the last lines " how network coding can be integrated inside a PEP with QoS scheduler has been proposed in RFC 5865 [RFC5865]." As far as I can remember from that RFC, the…
Correct, there is a glitch in this sentence. RFC5865 refers to QoS 
schedulers and definitely not to network coding.
> Hope it can help. I'm in any case obviously available for further iterating on my comments.
Once again thanks!

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 30

---

From: Kuhn Nicolas <[email-masked]>
Date: Wed, 28 Feb 2018 09:18:23 +0000

Dear Tomaso, 

Please find my comments inline. I will also prepare a -03 version of the draft that will include modifications.

Kind regards,

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

-----Message d'origine-----
De : nwcrg [mailto:[email-masked]] De la part de Emmanuel Lochin
Envoyé : mardi 27 février 2018 18:11
À : [email-masked]
Objet : Re: [nwcrg] New Version Notification for draft-kuhn-nwcrg-network-coding-satellites-02.txt

Dear Tomaso,

Many thanks for your feedback, some comments in-line (I let Nicolas to correct/complete).

> 1) General: since the draft is supposed to be informational, therefore not containing any normative text, I don't think normative references are necessary.
[NK] It will be updated in the next submission of the draft.
> 2) Section 2, end of page 2: there is a mention on how to map the considered architecture to cellular system. I'm wondering whether this is really necessary since the I-D deals only with satellite…
[NK] It is not necessary, indeed. That being said, this may be relevant since some proposals of this draft are not specific to SATCOM but could be applied to other context since there are similarities in the aggregation networks. I would propose to move that section in the "deployability" section which is later in the document.
> 3) Section 5.1: you may want to add a reference to ASMS demonstration in Cagliari. Moreover, in the general description of the two-way relay channel, it could be worth mentioning that in case of OB…
You are free to propose or directly write inside the draft a modification of this section.
[NK] In the mean time, I can add that the network coding operations could be done on-board. 
> 4) Section 5.2: is there any difference with what can be done with NORM?
NORM is one possible option and the illustration proposed might suggest its use. However NORM is only FEC-based.
This part seeks to consider other network coding schemes such as sliding window encoding (described in the taxonomy draft), where some real implementations exist enabling a reliable multicast service.
[NK] We will provide some more details in the next version of the draft. 

> 5) Section 5.3: it refers to " [I-D.boucadair-mptcp-dhc]" for the multi-link architecture. As a matter of fact, that I-D is more dedicated to DHCP implications. I'd rather refer to the recently pub…
[NK] The rationale of mentioning the draft on MPTCP is to highlight that the architecture are similar and supported by (at least one) telco operator. We will add a pointer to the ETSI TR that deals with multiple link TCP (but not the actual MPTCP in the linux kernel).
> 6) Section 5.5: it is not clear to me how network coding can help in the case of variable link capacity. Probably some more details would be helpful. Is it about recovering congestion losses due to…
Correct, we need to better explain. In brief we consider a scenario where losses occur due to link impairments over, for instance, a BGAN.
[NK] The outage events and the consequent number of losses depends a lot on the application use-case, such as when mobile users are considered. In this case, the solution could be to either add network coding at higher layers seems relevant or switch to another gateway, but this comes with other constraints (mostly depending on the duration of the link impairment). We can indeed add some information related to the gateway handover but this is not the exact same use case IMHO. 
> 7) Section 6: I read from the last lines " how network coding can be integrated inside a PEP with QoS scheduler has been proposed in RFC 5865 [RFC5865]." As far as I can remember from that RFC, the…
Correct, there is a glitch in this sentence. RFC5865 refers to QoS schedulers and definitely not to network coding.
[NK] We will correct this in the next version of the draft. 
> Hope it can help. I'm in any case obviously available for further iterating on my comments.
Once again thanks!
[NK] Thanks for your comments that I think improve the relevance of this draft. 

Emmanuel
>
> Best Regards,
>
> Tomaso
>
>
> ————————————————————————
> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace 
> Center Institute of Communications and Navigation | Satellite Networks 
> | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D.
> Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | 
> [email-masked] http://www.dlr.de/kn/institut/abteilungen/san
>
>
>> Subject: [nwcrg] TR: New Version Notification for 
>> draft-kuhn-nwcrg-network- coding-satellites-02.txt
>>
>> Dear all,
>>
>> Envoyé : lundi 26 février 2018 16:25 À : Kuhn Nicolas 
>> <[email-masked]>; Emmanuel Lochin 
>> <[email-masked]> Objet : New Version Notification 
>> for draft- kuhn-nwcrg-network-coding-satellites-02.txt
>>
>>
>> A new version of I-D, 
>> draft-kuhn-nwcrg-network-coding-satellites-02.txt
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>

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