Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"

From: Vincent Roca <[email-masked]>
Date: Thu, 18 Apr 2019 07:42:18 +0200

Hello everybody,

As discussed during the IETF104 meeting, we would like to start a RG Last Call for
draft « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04

  https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

We would like to collect your comments by Thursday 9th, May (3 weeks).

Thanks in advance.

    Marie-Jose and Vincent

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 29 Apr 2019 07:19:29 +0000 (UTC)

This draft is not yet ready imo.
As in previous reviews, the trivial issues are unfortunately masking the deeper issues with what the draft is for. Comments on trivial and deeper issues in order on the draft below.

abstract

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

this is talking about *network* coding, and this draft needs to be perfectly clear throughout that it is doing so, otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading. Blurring the coding case is not helping your cause.  I called this out previously. This is important.

Introduction
physical-layer reliability mechanisms -- hyphenate adjectival terms
style: e.g. should be in a clause separated by commas, not brackets.

500 ms one-way _delivery_ delay (or path -- i.e. not propagation)

"However, physical layer reliability mechanisms may not
recover transmission losses (e.g. with a mobile user) and layer 2 (or
above) re-transmissions induce 500 ms one-way delay with a
geostationary satellite"

Look, forward error coding (FEC) and link ACKs are complementary on a sliding scale depending on delay/channel quality, and this is talking solely about retransmissions. In fact, link or channel FEC do recover a large number of transmission bit/symbol losses without adding extra delay.

"We have noticed an active research activity on coding and SATCOM in the past."
-- if it's active, it's not in the past.
   if it's in the past, it's not active.
Do you mean 'in the past we have noticed'? that's redundant.

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

again, _network_ coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.

ACM : Adaptative Coding and Modulation;
-- Adaptive. This error repeats.
CPE: Customer Premise Equipment;
-- Premises. (My premise is that this is unfortunate.)

FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help.

FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo.

PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's _Enhancing_ and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for.

PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.

Don't hyphenate the Qualities.
section 2

"This section describes the components in satellite system that layson SATCOM systems dedicated to broadband Internet access that follows
the DVB standards"

-- This section describes the components of a satellite system that follows the ETSI DVB standards to provide broadband internet access. (Actually, DVB-S standards).

Following the DVB standards has effects on draft scope and terminology. Are you sure you want to do that? The current approach to DVB-S seems to be to pick and choose whatever is convenient to the argument.

A high-level description of a multi-gateway _satellite_ network is provided.

"a bi-directional' - elide a, elide -
Fig 1 doesn't resemble the multi-gateway DVB satellite systems that I have worked on.

Indoor and outdoor unit typically refers to the customer satellite terminal pieces as well, not jut a piece of the gateway. (Indoor - network to/from intermediate frequency IF. Outdoor: IF to/from RF) The satellite link appears to be in the wrong place, or the terminal needs breaking down further. And there's no mention of FECFRAME? PLFRAME is the structure, the data gets turned into FECFRAME. But that has "FEC" in it and this draft aims to downplay FEC... awks. Encaps like GSE or MPE have been skipped, but that's really just added flavour.

Section 3 Actual deployment
this is cherrypicking, not discussing link/channel FEC (Error) or ACK.

the heading should really be 'of network coding schemes'.

"to cover cases where where"?

At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error?

"Based on public information, coding does not seem to be widely used at higher layers."
it isn't, and that section can be reduced to just that sentence.

Section 4

"This section details use-cases where _network_ coding schemes could improve theoverall performance of a SATCOM system (e.g. considering a more
efficient usage of the satellite resource, delivery delay, delivery
ratio)."

Adding network coding overhead doesn't improve efficiency, ergo removing network coding overhead must therefore increase it. Which is pretty much in the not-using-network-coding state we're in. You'd need to define your 'efficiency' metric very carefully here.

The network coding example isn't convincing IMO; doesn't discuss the difficulty of getting coding to the satellite at similar times. And the choice of symbols is not clear.
"Moreover, with On-Board Processing satellite payloads, the coding operations could be done at the satellite level."

if a pig could fly, it would be a flying pig. Are we talking about network coding here? In the middle of a path? Are you alluding to the AmerHis example as some sort of DVB OBP best case? I have no idea. Network coding across multiple MF-TDMA uplinks and handling onboard would be... ambitious, and heavily restrict the flexibility of the payload to (as far as I can see) little benefit.

section 4.3 hybrid access

in Fig 5, given that curly brackets have been used as notation elsewhere, you'd do better drawing bidirectional links as <=>n rather than causing confusion with other diagrams and triggering LaTeX flashbacks.
4.4 varying capacity
"recovered with higher layers" -- recovered with higher-layer...

"the usage of coding to cope with cases where channel condition can change in less than a second"

this is claiming that network coding, working on a longer path, is more useful than ACM working across just the satellite link from direct measurement of channel conditions. That's an unsupportable and untenable argument.

For this to be attempted, the coding overhead has to already be present, which is generally viewed as undesirable, due to satellite capacity costs, efficiency across the entire path, etc. I've spent years pointing out the need for checksums to people who don't think they're necessary. Someone who doesn't believe in checksums isn't going to believe in network coding...

4.5 gateway handovers

if doing a gateway handover to deal with really bad weather, equipment failure or site loss, network coding overhead won't help, and it won't be seamless.

"communalised" - I don't know what that word means in this context, or what European diplomatic language is doing here.

5.2. Interaction with virtualization

I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that.

chin-nfvrg-cloud-5g-core-structure-yang
referring to an expired -00 internet-draft does not add credibility.

5.3 delay-tolerant

 legitimate -> legitimize.

This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case.
Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references.
EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.

I could write more and go into other diagrams in detail, but I'm not sure that the added effort would be worthwhile.

The draft scope, intent and underlying purpose need a rethink IMO. And lack of comments from other group members would be an indication of... something, and I'm not sure what.

regards

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

________________________________
From: Vincent Roca <[email-masked]>
To: [email-masked] 
Cc: Vincent Roca <[email-masked]>; Marie-Jose Montpetit <[email-masked]>
Sent: Thursday, 18 April 2019, 15:42
Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

_______________________________________________

nwcrg mailing list

[email-masked]

https://www.irtf.org/mailman/listinfo/nwcrg

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 12:49:16 +0000

Dear Lloyd,

Concerning the comment on Section 4.5 "Gateway handover", I think it refers to the case where one wants to exploits the bandwidth of the "bad" gateway as much as possible and has however to take into account that gateway handover prediction algorithms show a non -negligible probability of missed detection. In this case, then network coding can avoid some losses, obviously at cost of some additional overhead (redundancy packets) transmitted through the "good" gateway. This scenario was partly studied in one of the activities carried out in the ESA co-funded SatNEx III project.

In case you needed more details, please let me know.

Best Regards,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; [email-masked]
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

abstract

Introduction

Section 4

4.5 gateway handovers

5.3 delay-tolerant

regards

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

nwcrg mailing list

[email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 29 Apr 2019 09:44:44 -0400

Thanks Tomaso!

And thanks of course to Lloyd for having taken the time to provide detailed comments. I will leave the authors to respond specifically to each point. 

But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.

mjm

Marie-Jose Montpetit, Ph.D.
Research Affiliate, MIT Media Laboratory
[email-masked]
[email-masked]
+1-781-526-2661
@SocialTVMIT

> On Apr 29, 2019, at 8:49 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Dear Lloyd,
>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 30 Apr 2019 08:02:19 +0000 (UTC)

Tomaso
please email me more details and relevant SatNEx documentation, which may or may not be a relevant reference for the draft.

(Obviously, that's not how we do gateway failover, which involves switching gateway feeder uplinks and associated in-satellite circuits to spotbeams to the redundant dedicated failover gateway, which then assumes the characteristics - carriers/channel/beam/network properties - of the gateway it is now emulating. Transmitting through both gateways at once and causing uplink interference is not considered desirable here.)

L. Lloyd Wood [email-masked] http://about.me/lloydwood

      From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked]
 Sent: Monday, 29 April 2019, 22:49
 Subject: RE: [nwcrg] RG Last Call for draft "Network coding and satellites"
   
Dear Lloyd,

Best Regards,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; [email-masked]
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

abstract

Introduction

Section 4

4.5 gateway handovers

5.3 delay-tolerant

regards

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

nwcrg mailing list

[email-masked]

---

From: <[email-masked]>
Date: Tue, 30 Apr 2019 08:13:15 +0000

Lloyd,

Indeed transmitting the content to the same spotbeam (having in mind a reference destination satellite terminal) through two gateways simultaneously does not come for free and a more advanced design of the ground and space segments is certainly necessary, some of them being already analysed in the context of SGD satellite architectures.
Concerning the project documentation, I’m afraid I can only point you to the publications resulting from those activities, since the related deliverables are not publicly available. Let me check and I’ll send you another e-mail during the next days.

Best Regards,

Tomaso

From: Lloyd Wood [mailto:[email-masked]]
Sent: Tuesday, April 30, 2019 10:02 AM
To: Cola, Tomaso de
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

Tomaso

L.

Dear Lloyd,

Best Regards,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; [email-masked]<mailto:[email-masked]>
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

abstract

Introduction

Section 4

4.5 gateway handovers

5.3 delay-tolerant

regards

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

________________________________
From: Vincent Roca <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Cc: Vincent Roca <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 18 April 2019, 15:42
Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

nwcrg mailing list

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

_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 30 Apr 2019 05:40:45 -0400

Please send the papers to the list as it is relevant for understanding the draft.

mjm

> On Apr 30, 2019, at 4:13 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Lloyd,
>  
> From: nwcrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lloyd Wood
> To: Vincent Roca; [email-masked] <mailto:[email-masked]>
> Cc: Marie-Jose Montpetit
> Lloyd Wood [email-masked] <mailto:[email-masked]> http://about.me/lloydwood <http://about.me/lloydwood>
> 
> 
> 
> 
> 
> 
> From: Vincent Roca <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> 
> Cc: Vincent Roca <[email-masked] <mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>>
>   https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/>
> 
> 
> [email-masked] <mailto:[email-masked]>
> 
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>  
>

---

From: [email-masked]
Date: Tue, 30 Apr 2019 12:45:52 +0000 (UTC)

Tomaso,
What is SGD?

supporting a reference destination satellite terminal doesn't come for free?
looking forward to seeing your network coding design that will work for 100,000 terminals and 160Gbps of capacity.
thanks

Lloyd [email-masked]

On Tuesday, April 30, 2019, 6:13 pm, [email-masked] wrote:

#yiv7907712118 #yiv7907712118 -- _filtered #yiv7907712118 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv7907712118 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv7907712118 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7907712118 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv7907712118 #yiv7907712118 p.yiv7907712118MsoNormal, #yiv7907712118 li.yiv7907712118MsoNormal, #yiv7907712118 div.yiv7907712118MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv7907712118 a:link, #yiv7907712118 span.yiv7907712118MsoHyperlink {color:blue;text-decoration:underline;}#yiv7907712118 a:visited, #yiv7907712118 span.yiv7907712118MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv7907712118 span.yiv7907712118EmailStyle17 {color:#1F497D;}#yiv7907712118 .yiv7907712118MsoChpDefault {font-size:10.0pt;} _filtered #yiv7907712118 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7907712118 div.yiv7907712118WordSection1 {}#yiv7907712118 
Lloyd,

 

Best Regards,

Tomaso

 
Tomaso

 

 

L.

 

Dear Lloyd,

Best Regards,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; [email-masked]
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

abstract

Introduction

Section 4

4.5 gateway handovers

5.3 delay-tolerant

regards

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

nwcrg mailing list

[email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 30 Apr 2019 08:48:32 -0400

I come from a culture where criticism must come with ideas for a solution :)

> On Apr 30, 2019, at 8:45 AM, [email-masked] wrote:
> 
> Tomaso,
> 
> What is SGD?
> 
> Lloyd Wood
> [email-masked] <mailto:[email-masked]>
> On Tuesday, April 30, 2019, 6:13 pm, [email-masked] <mailto:[email-masked]> wrote:
> 
> Lloyd,
> 
>  
> From: Lloyd Wood [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> From: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> 
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 30 Apr 2019 12:50:51 +0000

SGD stands for Smart Gateway Diversity.
When I said that supporting to a reference destination satellite terminal does not come for free I was actually linking to your comment, i.e. that achieving the proposed concept requires some advanced design on the ground and space segments, which obviously might have some downside in terms of cost and complexity.

Tomaso

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 30, 2019 2:46 PM
To: Cola, Tomaso de; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

Tomaso,

What is SGD?

thanks

Lloyd Wood
[email-masked]

Lloyd,

Best Regards,

Tomaso

Tomaso

L.

Dear Lloyd,

Best Regards,

Tomaso

-----Original Message-----
From: nwcrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; [email-masked]<mailto:[email-masked]>
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

abstract

Introduction

Section 4

4.5 gateway handovers

5.3 delay-tolerant

regards

Hello everybody,

Thanks in advance.

    Marie-Jose and Vincent

nwcrg mailing list