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

Lloyd Wood <lloyd.wood@yahoo.co.uk> Tue, 30 April 2019 08:02 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 8DFC91200F5 for <nwcrg@ietfa.amsl.com>; Tue, 30 Apr 2019 01:02:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 VxnNGPQqXlXy for <nwcrg@ietfa.amsl.com>; Tue, 30 Apr 2019 01:02:28 -0700 (PDT)
Received: from sonic301-21.consmr.mail.ir2.yahoo.com (sonic301-21.consmr.mail.ir2.yahoo.com [77.238.176.98]) (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 75C32120099 for <nwcrg@irtf.org>; Tue, 30 Apr 2019 01:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1556611345; bh=soZsaKSY+4SoYf9ZK70+gS5qHtKhZo6Modu8aJ/Xswo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IWchAQw0NcH+6Sjz3+bQBPbBy0/i29QQDIx067vKFgUt8hOIdpyGLL7F725JNkLcxpqMaj6hJX1l5P+r1OnO1wJyBQJMAyUOM0sIRTCTz4Oitz7N5TL5dD1EuOE28ndmTGjf3oDSG8uMwbBrcQR+BRtFd+0cfoVO647RfWvGYiGbVyPn70GUtDRA8QtEU3EJTebTfT76xKsK7Ki1J/wSevJtGQNSIKn4oUbDtCJYykDDkcN4pqEu8rwfWU9ARBuRZRkQiqBOg0dpHejc9dsal+9pEiyCIHScyL/hEMST5zoWcyd++a+U6GKymze/F68Vp3cl37z4AvvXYBgoCjOqqQ==
X-YMail-OSG: Nf9dMPUVM1kr14e.kxel38Y9i7i7_mwIbRRKpXzDq6382YIHdlFT.EFewkD4jQn OzNgZHrQIKxBqIZMVp_DnqaVUOOkpPNdj78meb.A2vG7pdL8NLRItmaBLyJDU_BBBtAiw254MUSu 5Dg_Q_v9MrJc5Lh0S6Kw87cfyAm1E0k7VZ_GFKNH_YGxn4XkFZh3WEHWnU8gwqK7nUdZfwzn8De_ 3huCznoLzpVWe32gsP_oQ3Qvadd19RifDR2VYHJfVwOF0JGQUUX0xVwThiivm5_XyXdwgr.nvo3g v48NNLqMe2JxWrZ6h.FI1MwxEZgVvA7NAXlZQtPmWzlqpTnloMRo6PrqA4TigVkaUfbIl9q0zw78 ugWyn3gxZKlcd8bYLqbyHqZoXQKQd1QTfPpN4FTJNmNCbWqfmQosHdk8x0HOeBOKY4Afw6fm917c 8o8XCSukNXBn6bylsynIYeySPu8QekFu5O3HPCsbzvDKrd.JlacvpZpktApPvDxjudv.VhjjiTJ7 YJ1Op6awGsoj8xJRz6O2gu2BYnRmQBPiqQRJtkTk_d14BuRvi3Q3Msq0RqtrXdoS4yYiIqhCdCQH rOpbJUI8Bx53BM0UyBO3W7MZLQ2p21KKxUd4b7zrKMoDPaIy7Kexu5L5neZa2fnLwnrdFxx29MIh BVltwovfLCG0ilLTO4DfvhbkEM1AL9WaYtj5ycpnMfwZhxhcxcF1jjBikgdvLkfQWuNfqZhg17vh qBuajwSImxXr0BI5rhsFH2wRc8faC5a2jATkJf30gZIswrufU_CVRoiM.e7UEvjWgBoJGUx0FAkQ Ce9uYtINS.IJp7.7SrYPCxpL9sm7shoTTi_boe5g8EmPWnNRjr_9jApEMikgNl9ceQRmFw2l63TS 1BHiPdHMZB_Yvw2WlU20CDk_l_5bb0XQ.BQRYv_T16vqlSelAyFQ9oEoPz5c67mOjW7Ahb2.Lo1h oEGzY7oftZ0TihTrihU9S.Hb2KpxL2PxfIAWI2kf4UUiT54y3wEJMi28eqYdXxqfdXRyVcMl9mR9 qxy7.JpHvfxGHs.wMMT5iMQ1ptp1eOXKc1rCJOwDKnitDyPlNs1Qe7c24HoOPpCynk0tLsBGpzku mvU9MpBXKnk2e5w7VV9Z5nuB2Gi6bUqrqwVRcdO8_TghptO7WBGgzeRycikND6L7Zuw8.9CYDRNU LBczh5AKQs8O_eTjcOQDpKdE14LyobtW_lSu9D4R55Frprl3S4Kr6DXU-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Tue, 30 Apr 2019 08:02:25 +0000
Date: Tue, 30 Apr 2019 08:02:19 +0000 (UTC)
From: Lloyd Wood <lloyd.wood@yahoo.co.uk>
Reply-To: Lloyd Wood <lloyd.wood@yahoo.co.uk>
To: "Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de>
Cc: "marie@mjmontpetit.com" <marie@mjmontpetit.com>, "vincent.roca@inria.fr" <vincent.roca@inria.fr>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Message-ID: <1902490412.3499547.1556611339630@mail.yahoo.com>
In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC35AA09B6C@DLDEFFMIMP02EXC.intra.dlr.de>
References: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr> <784634441.2538462.1556522369065@mail.yahoo.com> <1A39DCC13AF3C14B83CD74124D4DCFC35AA09B6C@DLDEFFMIMP02EXC.intra.dlr.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3499546_1153537873.1556611339627"
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/EGDgRPODXbd0t6TPp9zHISCk8HE>
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: Tue, 30 Apr 2019 08:02:31 -0000

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] On Behalf Of Lloyd Wood
Sent: Monday, April 29, 2019 9:19 AM
To: Vincent Roca; 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 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

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