Re: [nwcrg] [dtn] TR: I-D Action: draft-irtf-nwcrg-network-coding-satellites-03.txt

Dear Lloyd, all, 

We have updated the document following your comments. See attached email. 
Please find some more comments inline. 

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> 
Envoyé : mercredi 12 décembre 2018 01:23
À : Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>; nwcrg@irtf.org; dtn@ietf.org
Objet : Re: [dtn] TR: [nwcrg] I-D Action: draft-irtf-nwcrg-network-coding-satellites-03.txt

Some brief notes on the draft below, in order they appear in the draft, so trivial typos are mixed in with far deeper issues.

"In this context, this document aims at
identifying opportunities for further usage of *network* coding in these systems."

this is talking about *network* coding, and you need to be clear throughout that you are doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading.

[NK] It is true that we have a conflicts between the original title and this summary. We will update that in the next version of this document. The memo is on network coding but slightly presents some physical-layer coding. We have clarified the section 3 as a consequence. In the next version of the document, we will make the titles clearer. See the GITHUB repo for these changes.  

BBFrame definition - this is a DVB-S construct, as is GSE, which is defined within it. really, using these too heavily is not useful. Ditto for PLFRAME. More generic terms could be used instead.
[NK] The precisions where asked in a previous review of this document. 

PEP - this is an IETF term. informative reference RFC3135 here directly, I think
[NK] Thanks.

COM needs to be defined as COMmunication. Defining within definitions is messy.
[NK] Thanks.

section 2

generic? this is already tightly tied to DVB-S
[NK] We have rephrased it so that it assumes being tightly tied to DVB-S

high-level should be hyphenated
[NK] Thanks

While DVB-S is common and popular, almost no-one uses RCS or RCS2, which has very little market traction. DVB-S use (BBFRAME etc) can be argued for, as it's widespread. I don't think there's anything RCS specific here for the return channel, and little discussion of shared return capacity.
[NK] We have made it more generic. 

section 3

SP and MP should probably be SPC and MPC.
[NK] Thanks.

some acknowledgement of Link Coding (LC) and Channel Coding (CC) is probably needed here. This is very much the elephant in the room that makes network coding largely unnecessary in this scenario. And it should be included in fig 2 between packetisation and PHY. the physical layer is, you know, physical, and link coding is a logical construct applied on top of it, rather like the link itself. Channel coding can be path specific; the channel is unique between two endpoints; link coding is on the logical path overlaid on that.
[NK] We have changed most of this part to clearly states we are not focusing on physical and link layers issues.

taxonomoy document - typo: taxonomy.
[NK] Thanks.

4. Where *network* coding schemes...

while E2E source coding are done -- IS done

"Satellite terminal A (resp.  B) transmits a flow A (resp.  B) to a NC server, which forwards a combination of both terminal flows." I don't know what this sentence means. I don't see how it relates to the diagram. What is resp. B? How do you go from talking about one flow, then talking about two?
[NK] We have rephrased it. 

(for a flow, suggest use of 'send' - not transmit, which implies physical things. Does anyone else think TCP is misnamed?)

"Moreover, with On-Board Processing satellite payloads,   the coding operations could be done at the satellite level, thus  reducing the end-to-end delay of the communication."

you're talking about *network* coding? The argument that e2e delay is reduced is tenuous at best. this would need to be fleshed out -- if it's really a valid argument.
[NK] We have removed the sentence on reduced delay.

Shouldn't FLUTE/ALC be in the glossary? Not sure it's useful to include here.
[NK] Added - thanks. 

I don't buy any argument in section 4. You need an intermediate section 3.5 actually making the case for network coding and its utility in this scenario. I mean, the best use of satellite diversity I can think of is Globalstar's CDMA recombination, whic doesn't need network coding.

4.4 usage of *network* coding...

What is QEF? quasi error free? not in glossary. changing in less than a second - this is what interleaving and channel coding is for... 
[NK] The usage of satellite diversity may not be possible in case of mobile users or with optical link variations. In these cases higher layer protection may be relevant. 

Coding may be applied on IP packets? Source coding? Channel coding? network coding?
physical-layer coding - hyphenate. But again, channel or link?

5. During these critical phases, *network* coding can be added

some equipment might be communalised. - 'communalised' might have meaning in some European project variant of English, but I'm afraid it means nothing to me.
[NK] Thanks.

layer-2, layer-1 - hyphen
[NK] Thanks.

Deploying *network* coding schemes at the TCP level 

in these equipments - awkward to read. it pluralises - in this equipment. 
[NK] Thanks.

from specificities  - awkward. suggest 'independent of the specific characteristics of a SATCOM link'
[NK] Thanks.

how much reliability packets can be introduced to -- unclear. how many reliability packets? How much overhead from redundant reliability packets?
[NK] Thanks. 

"Next generation of SATCOM ground segments could rely on a virtualized environment." - depends on the scope of virtualized environment. Virtual machines all over the place here. but that is, I suspect, not the virtualization you intend to mean. Is applying virtual network functions to satellite actually useful?
[NK] Applying virtual network functions to satellite ground segments would be relevant as far any aggregation network. In these case, deploying a VNF-network coding could be as easy as deploying a VNF-PEP function. 

NFV is still not defined in glossary, unlike VNF

5.3 DTN section adds nothing IMO. E2E-reliable communication over DTN, which is inherently not E2E? A bold, unsupported, and imo completely unsupportable claim.

Conclusions

"This document presents the current deployment of coding in some satellite telecommunications systems"
it's *network* coding, and current deployment has not been discussed at all.
[NK] Updated.

multiple opportunities - wishful thinking IMO.

Why does this IRTF document have RFC 2119 boilerplate and normative referencing? The CAPITAL LANGUAGE is not used - nor should it be.
[NK] Removed, thanks.

Even *though* this document focuses on satellite systems...

their help in writting this document. -- writing. that typo is still not fixed.
[NK] Thanks. 

some specificities - please reword
[NK] Done

On the specific scenario of NC in SATCOM systems, there are no specific security considerations.
- hard to have security considerations for something that doesn't exist.

I'm afraid that the brief notes above may have left the impression that I don't like this draft. Well, I don't; there may be something good there, but in its current form I'm really having trouble seeing it. Still, Joyeux Noël, and have some Cassoulet de Toulouse for me.
[NK] I had the Cassoulet during the XMAS break, thanks. 

L.

Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood

________________________________
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: "nwcrg@irtf.org" <nwcrg@irtf.org>; "dtn@ietf.org" <dtn@ietf.org>
Sent: Tuesday, 11 December 2018, 19:53
Subject: [dtn] TR: [nwcrg] I-D Action: draft-irtf-nwcrg-network-coding-satellites-03.txt

Dear all, 

We have updated the draft following the recent comments that we had received. 
Let us know if you have any views on it. 

Cheers,

Nico

-----Message d'origine-----
De : nwcrg <nwcrg-bounces@irtf.org> De la part de internet-drafts@ietf.org
Envoyé : mardi 11 décembre 2018 09:49
À : i-d-announce@ietf.org
Cc : nwcrg@irtf.org
Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-network-coding-satellites-03..txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Coding for efficient NetWork Communications Research Group RG of the IRTF.

        Title           : Network coding and satellites
        Authors         : Nicolas Kuhn
                          Emmanuel Lochin
    Filename        : draft-irtf-nwcrg-network-coding-satellites-03.txt
    Pages           : 15
    Date            : 2018-12-11

Abstract:
   This memo details a multi-gateway satellite system to identify
   multiple opportunities on how coding techniques could be deployed at
   a wider scale.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-03
https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/