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

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: lloyd.wood@yahoo.co.uk [mailto:lloyd.wood@yahoo.co.uk]
Sent: Tuesday, April 30, 2019 2:46 PM
To: Cola, Tomaso de; lloyd.wood@yahoo.co.uk
Cc: marie@mjmontpetit.com; vincent.roca@inria.fr; nwcrg@irtf.org
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

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 Wood
lloyd.wood@yahoo.co.uk

On Tuesday, April 30, 2019, 6:13 pm, Tomaso.deCola@dlr.de wrote:

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:lloyd.wood@yahoo.co.uk]
Sent: Tuesday, April 30, 2019 10:02 AM
To: Cola, Tomaso de
Cc: marie@mjmontpetit.com; vincent.roca@inria.fr; nwcrg@irtf.org
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

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 lloyd.wood@yahoo.co.uk http://about.me/lloydwood

________________________________

From: "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de>
To: lloyd.wood@yahoo.co.uk
Cc: marie@mjmontpetit.com; vincent.roca@inria.fr; nwcrg@irtf.org
Sent: Monday, 29 April 2019, 22:49
Subject: RE: [nwcrg] RG Last Call for draft "Network coding and satellites"

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:nwcrg-bounces@irtf.org<mailto:nwcrg-bounces@irtf.org>] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; nwcrg@irtf.org<mailto:nwcrg@irtf.org>
Cc: Marie-Jose Montpetit
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"

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 lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> http://about.me/lloydwood

________________________________
From: Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>>
To: nwcrg@irtf.org<mailto:nwcrg@irtf.org>
Cc: Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>>; Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>>
Sent: Thursday, 18 April 2019, 15:42
Subject: [nwcrg] RG Last Call for draft "Network coding and satellites"

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

_______________________________________________

nwcrg mailing list

nwcrg@irtf.org<mailto:nwcrg@irtf.org>

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

_______________________________________________
nwcrg mailing list
nwcrg@irtf.org<mailto:nwcrg@irtf.org>
https://www.irtf.org/mailman/listinfo/nwcrg