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

Lloyd Wood <lloyd.wood@yahoo.co.uk> Mon, 29 April 2019 07:19 UTC

Return-Path: <lloyd.wood@yahoo.co.uk>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730D41202E3 for <nwcrg@ietfa.amsl.com>; Mon, 29 Apr 2019 00:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsHQ0305_XsX for <nwcrg@ietfa.amsl.com>; Mon, 29 Apr 2019 00:19:36 -0700 (PDT)
Received: from sonic309-26.consmr.mail.ir2.yahoo.com (sonic309-26.consmr.mail.ir2.yahoo.com [77.238.179.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7313C1202E2 for <nwcrg@irtf.org>; Mon, 29 Apr 2019 00:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1556522374; bh=4ur1yFXkimrcg53hbVJIuERnC04E9LqYUxgWYKhJUDw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=LfrG0FcT1thrxv+jjF++OeMz06J7JndTLz3mJPwDqe05qq2U08RO07LbNEtk425vpaI/wXODPTt6V5DC3aAkAjLMmzwNrZ3n3tY0d0qixb0cjW0/wOtcez2m4FMIXHG6yyQ/5jBIDc+fMVN+5BoODwEvmISGDao3aSYMW2pL2RfziAlgm930kQg3d/fH8iSHDWs7UiAi7I6K2kfiCQzWqh0yoGNBcjeEjU3vd92/Fo1vRafin8YPqX0xTCmDNQ8+3uJBC+qRWhdDpZTeKxcd6NOLFVjFLzTxkF7VJFpR/4WvrzVNmP7YWel426M1B5IdNWjpBWXOJgl6xbxYn1B1NQ==
X-YMail-OSG: 9fSQhEoVM1kZ3aJlaDWu2iSXLpqdZ7rd874BIJmK5TeqECKC9zwzbHhvkWJYkKf 8eSHDQe1Jzwwj_jJ2Ug6msM98i4WVLdErv_hpP4wnOrmv0xQqRkGtlxETAh3_Hk0gOuPZhoSTmjy OYsP7_TbkkgmZq2ktqcKPxToZGGZod.F2QoGyIzLZo3XnYRfCSnnUVG1D0qjH2WV8A69txxeob7e l0YWUQ4X5v6aDa6_U_dPdOO.Tg4ghJhhQAMnb3IAjfCfxaxWDsrBf2zkHNnl7LZQNpQE3XgXGpjA CaWNplIQ58tO5EmHK2VigelJkgeIvelvgOuA5WbxtM7bhF9fw6pGMBcUl41BO8LOdfcZmuze36FL 0gfQ5NBvJ9Dv3BtOXbQtfjw655UdGBzMjbJQFvTVP1Y.hIkW64nd0zqdDdFd6y4DruwthARyk5Ue jXJsUVr3q6Z3S_cXxSX5X197AamCo7b1z_lT8ZIXJEkYgaji1X5b3_9JjTlF3DCwjbJ4G3gu2J.i d5dL0Rd7C.BViiVZz.JhCWOwZTH3lCKpeAalD0auVkpUbteClBT9Fm9T_9NFE.MDpURN4ToWMZ6m UU01nXOlRaW_Lmy6vhiABEuephN0t4X_GXn77b_QRCPcbWXbxICTN5ivcoXPXa0mk8HQ9eflyA1e RjYidy6Or0JndJ7PMgtq3_n.4lhtE1SfQTS01w5rkbpO7TN0HC79Xi1WTgif4f6FWP6WsHEo.CIU 6b2h5vVRpkrSBfn6O5L3sMoHs5HxoP9Xgzy7.a9xkt2EDPyLM34Djd17x9KPaRmykCAUnrLqpnVW gsJHwEEBGJis6_rXYeR1Yoz7mDwARUmBOYV_VpwcMRoD1Z3mxzEDmjGfKJ5bnuhQr74edCRTp7sO xqrjaBgBbP4iumOy1_6fNHphQdjeDkGUY.qPKXu6.2MCETEYUU5qd.MicOydl8w5gA1c1ZziUOiD YSp6ddAv6ZaUD7iQ9y8ranRajZ7aMBzyo5wLxxcvDlZpbDXsq62ZO6k2fXm_KoPTeGPWopPapSv9 ija1YBcvUzMKi8uZzcze3gXff01PDSEyvE0_DDOik83kq_7jGOLUgGfYeL26D1wqNm.IHp3M7Lrr vQw6IajDvvhd1gJpOeQxhc4QyW.sN_wXlhVZqSobTMD6QYmoL3EgohqTbLAQ6.NVoC1vDkG1A3fU rAJ8jzebXJtLFTbYtwPRkD0rS6xNynlp.aGbdK4vtady.twVSihUR82Xk
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ir2.yahoo.com with HTTP; Mon, 29 Apr 2019 07:19:34 +0000
Date: Mon, 29 Apr 2019 07:19:29 +0000 (UTC)
From: Lloyd Wood <lloyd.wood@yahoo.co.uk>
Reply-To: Lloyd Wood <lloyd.wood@yahoo.co.uk>
To: Vincent Roca <vincent.roca@inria.fr>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Cc: Marie-Jose Montpetit <marie@mjmontpetit.com>
Message-ID: <784634441.2538462.1556522369065@mail.yahoo.com>
In-Reply-To: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr>
References: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.13554 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/5Cy6jZiYm-PlyVbIGgB5wk_nw4g>
Subject: Re: [nwcrg] RG Last Call for draft "Network coding and satellites"
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 07:19:40 -0000

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 http://about.me/lloydwood






________________________________
From: Vincent Roca <vincent.roca@inria.fr>
To: nwcrg@irtf.org 
Cc: Vincent Roca <vincent.roca@inria.fr>fr>; Marie-Jose Montpetit <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

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