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

"lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk> Tue, 05 November 2019 09:33 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 E1BF6120843 for <nwcrg@ietfa.amsl.com>; Tue, 5 Nov 2019 01:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, SPF_HELO_NONE=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 zs62ijyRGLgP for <nwcrg@ietfa.amsl.com>; Tue, 5 Nov 2019 01:33:16 -0800 (PST)
Received: from sonic303-19.consmr.mail.ir2.yahoo.com (sonic303-19.consmr.mail.ir2.yahoo.com [77.238.178.200]) (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 EB3C61201E5 for <nwcrg@irtf.org>; Tue, 5 Nov 2019 01:33:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1572946394; bh=DIyV+GYvFf4eYWwy5YyC8+tsTwevv+iygFf4uhN5upQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UgV4Jm5tnvWSMS3vLloOX+7WBkPo7FFYru1BbCjQwvOZgODApXyTLTzGnCaWmjKVhhHSDS23LQU1DpgDAzVGKWmxW0p02teGGjFZ+queEetF9xueki2Lmd0PHHhnuIwmQEB4pwhnTs4CWo9nA9X3cQ0HETZDEo6BclRyeVKJAu23NV9n/bZ86p1ydAPaxGoTEaQ1/4cuN2e2966qDjphMuNW13xMqiAHxkH31XFV3ilCai+ef1d5aRsyp3kHEnX0PEYtS/bvNsF0xLdb8uMtu4hRe0hq4ihex+PRikMlNKHFoc2DygIJqNX0+PfKDetsvBCd8/fZIO8HCNuPxxuipA==
X-YMail-OSG: qqq7YAoVM1kPhNU1mw6anQEiXd_JzOi7.RzgzlQoMmLtpQYIXC1fHRp_nKWX_ub Yb3Gyyly.GMYTY0rqY73PWTLlN9t4fZLmib2k3U487DomoGdQprWCvQPfOh85iXGwtSpfEdCQm5p 3o32iRG7ElvoCeRhtFdBTcasYDlmFffKy5AdS6br_ng4Lq.wMFt0F85D0h2c6HH6wKFHdVemQu.0 6xC3HKssOCFniJi6w1PY_AA0htGVbv6wrkYYSXufyhCvULzOzONtHilxQ1EZTfwnhumjdwarqrVy CW6Jj_.ZqSRb8mRXuRbuR7YmCiUhUB6_Wuo0SAPpl8FeL.uxzXu9dyeY4qdPSBK5YbL6j3MQ4MAI lEuqq4wvnfGHXlRgcNy_1hxNIbx.UnAF1A_kxzdrv8Jy4.vFih1nESbfnwVz196cXX9u2JTXdw9a nQQS.Fex12B.TWrhdBEcfT.gOfHrXRb4t2rvNgNKhkZc5NlFap1VK4xLJWZMIL6t4MKAMaQj1HAz 2I3dDtK5Cm7wHbYosA4j_zj1etUskkIQpWSBQdi9h7Qh5sf.wB1bfektV4_GSD.y9gAkQ720SVf_ tuBdXslFizpGkOV0qnBbwRd6IfkcRu3GmN5UKI.G6Oa.lsUUY9570WBPBKp5D_mLNet1zFvmZVSU 0LJCbgXoQFpbctogZ83lw_f8b.AhUxlDiCBSqFjlcw_3Ell1ogW0fso1uRB0I.PB1w_W9rs5erTC PeU95ZfzrKX5XjRdgIwxampwOOiE6Ou9w7wKt7csb3MtT6WY31d9FdoHgOrubrLbq2PvQLtZ78hj sSBw4Bi.PS5_d08EAnxVznbqDBssgkgUamhTLi_zi97yeTZJAOy5OfwGx.U54pO9D4wVgUwemg58 5kc3R9nwJPEwYmrAk1x65hGix3IlHUj03u2plpMpYzLsTqFm8FsCwHKBcYq4H1NXa69B.nwclewf Caav3Z1wRmINq.QIi8_xTA5ONBeZIfO5RZDe5OuBHN5sb_mY2y36p2Oa3kWfFvXIvf879D4RcVer 8v2xEGUaBxwqpYowLwi0B9KyICCENC3x47qEh0YEj7OmAUmU5ZNsvlu9ybFzf8oMcobfJp9EMJ.J 2rU8QWJTRYJzsh7WMZOTXjILs5Btfld1DoBIYZ9LqPfspfUF_2pJtBOvtb8B.quLWtdB_r7.8vvH gqe4NKLl5BTO38.PN9W8fy16COwG2oU7xrkndZFKvHLcmHqSGHuOQCFQ4z3g4UA_qtWuY0IIEO_c 6gt6Y_YhiyyoN_fr8PmEWdPlsgpKQjyxrXGAoNG1Gy2wk0z88kbXHs7dOYfr4YSTQPzjgBW6ajPU zanIYO7y9MYVRBnBAp3XB7hIYHPV4
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Tue, 5 Nov 2019 09:33:14 +0000
Date: Tue, 5 Nov 2019 09:33:10 +0000 (UTC)
From: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
To: "nwcrg@irtf.org" <nwcrg@irtf.org>, Vincent Roca <vincent.roca@inria.fr>, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
Cc: Marie-Jose Montpetit <marie@mjmontpetit.com>
Message-ID: <1360597091.280256.1572946390860@mail.yahoo.com>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1ECDFA49@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <D63FBBF9-CA7C-4AD1-9480-D335612FE708@inria.fr> <1665181122.766936.1572059555355@mail.yahoo.com> <F3B0A07CFD358240926B78A680E166FF1ECDFA49@TW-MBX-P03.cnesnet.ad.cnes.fr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_280255_660898162.1572946390857"
X-Mailer: WebService/1.1.14638 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/H_D83STYa4WK6iNordEE12iwUQU>
Subject: Re: [nwcrg] 2nd 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, 05 Nov 2019 09:33:19 -0000

(If a new draft is issued, does the last call clock restart?)

Nicolas

" I guess we should not go back to the "network coding"-like title."

Since this draft talks about network coding, it needs to explicitly state that,often, imo. Whenever this draft talks about coding, it means network coding --and it does need to state that to avoid losing the satellite-oriented audience.
   Considering for instance geostationary satellite system (GEO),
   physical or link layer erasure coding mechanisms recover transmission
   losses within a negligible delay compared to link delay.
The whole point of a FECFRAME and its two layers of coding isto recover and correct bit errors with no delay. This is not considered anerasure coding mechanism, which is very much a network coding concept.It really isn't possible to talk about DVB-S(2|2x) without some mentionof FECFRAME.

   Further exploiting
   coding techniques at application or transport layers is an
   opportunity for releasing constraints on the physical layer 
Having coding at the physical layer releases constraints on higherlayers. They can be viewed as supplementary, or different pointsin a design tradeoff space. Why you'd want to free up physicallayer overhead engineered and carefully tuned for the channel andlink for something that isn't, imposing more overhead -- well,that's a good question.


      It focuses on situations
      where coding is not widely deployed in current SATCOM systems.


Coding is widely deployed in every current satcom system. You mean
network coding *for applications and transports traversing satellite
links*. I can't stress enough how much this matters. The
implication that this will somehow 'fix' satellite systems that
don't have the coding that is considered desirable does the draft a
disservice.


inconsistent typo: "out door"

   (using multiple paths does not guarantee an
   improvement of both the reliability and the total capacity).

I believe you mean "using multiple paths does not guarantee animprovement of *either* the reliability *or* the total capacity).
Express it in Boolean algebra...


Sorry, commenting on this draft requires far more time than
I have available, so I'll stop here.

best

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




 
 
 On Wednesday, 30 October 2019, 20:40:17 GMT+11, Kuhn Nicolas <nicolas.kuhn@cnes.fr> wrote: 





Dear Lloyd,

Thank you for your feedback. 

Please find comments to your points in-line. 

We have submitted an updated version of the draft. 
We have also prepared slides to discuss the different points during the next IETF meeting. 

Cheers, 

Nicolas

-----Message d'origine-----
De : nwcrg <nwcrg-bounces@irtf.org> De la part de lloyd.wood@yahoo.co.uk
Envoyé : samedi 26 octobre 2019 05:13
À : nwcrg@irtf.org; Vincent Roca <vincent.roca@inria.fr>
Cc : Marie-Jose Montpetit <marie@mjmontpetit.com>
Objet : Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"

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


some comments, since I haven't seen much traffic on this:


Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?

[NK] In PR #51 : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.

I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc.
They're stated as out of scope...

If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be '_network_ coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.

[NK] In PR #52 , we have changed:
"Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document."
by
"Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems."
For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level.
For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.

Discussion of BBFRAME without discussing the FECFRAME (BBFRAME with coding) appears to be an omission. Is this imagining a world where FECFRAME, and its convolutional layers of coding are considered completely unnecessary due to path coding within the BBFRAME?
If so (and it won't gain much traction) this would need to be stated.
I don't think claiming that FECFRAME is link/channel and out of scope really flies; BBFRAME is a link construct too.

[NK] In the representation that is proposed in Fig 2, we consider that the physical gateway turns BBFRAME into PLFRAME. We did not want to go more into the details on how this is achieved.
We have added in PR #53


Fig 2: PEP is primarily a transport-level function; firewalls are primarily network and transport. Having one outdour unit (dish at gateway?) when the other end (user terminal) has both an indoor and outdoor unit (IDU and ODU) seems a simplification. No idea what the stepped end user boxes mean; if four end users, four boxes the same size might convey that better, with numbers on them. 1, 2, 3, 4 ... n

[NK] We have reworked the figure in PR #54 .
We hope this is clearer.


minor nits:


section 4.1 - PEP is Enhancing, not Enhancement. PEP_s_ usually split...


section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well.


ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist.

[NK] Thanks for the nits on the PEP.
For the comment on ACM, we have updated the text (PR #55) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough."
We have updated the conference in PR #56 and PR #57

This document has a difficult task (trying to build something from nothing) but at least it's readable enough to debate.

[NK] Thanks a lot !



best


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






On Wednesday, 16 October 2019, 01:37:00 GMT+11, Vincent Roca <vincent.roca@inria.fr> wrote: 





Hello everybody,

A first RG Last Call for the « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04 draft in April this year enabled to collect many highly valuable feedbacks. They have been taken into consideration according to the authors who produced an update.

It’s now time to start a second RG LC for version -06:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

We would like to collect your comments by Wednesday 6th, November (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

A new version of I-D, draft-irtf-nwcrg-network-coding-satellites-07.txt
has been successfully submitted by Nicolas Kuhn and posted to the
IETF repository.

Name:          draft-irtf-nwcrg-network-coding-satellites
Revision:      07
Title:          Coding techniques for satellite systems
Document date:  2019-10-29
Group:          nwcrg
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-network-coding-satellites-07.txt
Status:        https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/
Htmlized:      https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-07
Htmlized:      https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites
Diff:          https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-07

Abstract:
  This document is the product of the Coding for Efficient Network
  Communications Research Group (NWCRG).  This document follows the
  taxonomy document [RFC8406] and considers coding as a linear
  combination of packets that operate in and above the network layer.
  In this context, this memo details a multi-gateway satellite system
  to identify use-cases where coding is relevant.  As example, coding
  operating in and above the network layer can be exploited to cope
  with residual losses or provide reliable multicast services.  The
  objective is to contribute to a larger deployment of such techniques
  in SATCOM systems.  This memo also identifies open research issues
  related to the deployment of coding in SATCOM systems, such as the
  interaction between congestion controls and coding techniques.




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.

The IETF Secretariat