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

"Border, John" <John.Border@hughes.com> Thu, 02 May 2019 21:14 UTC

Return-Path: <prvs=30251ef68a=john.border@hughes.com>
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 5104F12008C for <nwcrg@ietfa.amsl.com>; Thu, 2 May 2019 14:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.336
X-Spam-Level:
X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hughes.com header.b=W3VSGYB9; dkim=pass (1024-bit key) header.d=hughes.com header.b=n0Y5DZoH
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 JZPCh2TctqZe for <nwcrg@ietfa.amsl.com>; Thu, 2 May 2019 14:14:05 -0700 (PDT)
Received: from mx0b-00115402.pphosted.com (mx0b-00115402.pphosted.com [148.163.153.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B0112007A for <nwcrg@irtf.org>; Thu, 2 May 2019 14:14:04 -0700 (PDT)
Received: from pps.filterd (m0118427.ppops.net [127.0.0.1]) by mx0b-00115402.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x42L6oGj007293; Thu, 2 May 2019 21:13:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=3152018; bh=0IAZxq9RsSoUtyFGCpT7POvOMtLVKKnxqgdmlOH3lps=; b=W3VSGYB9nVc5BV11JkXS9Uj10ZrtCsvU1j8kyR+A0J9SSmHZH+pC1vqbW+FO1zVw3DvR 8eJRyzMBUrG2Zow0MkKJJl0spXrN17Dcbo49H7Vv0DiGa/WFoQ10G+fcZ5+VfuH8oGxk YqTg5L0baC+FRGsCdullq+NXb4FKJEK5fVd+5t5tpP2HQDbFPVLKjwRNDPGZn/Gh/vd5 AGjrfx8Z+s9HwEy0XYtQsQpoSKE3vI/EqhlDfVt4+pkZeM9idWqKQy0po7x2xP1fo4ew QO78/r4GLhHdNMrsAoKPavnmFg14717sgbMSyhmXBFsQIf0KMwxBLyEgBf4zEFawyWTc wg==
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp2054.outbound.protection.outlook.com [104.47.50.54]) by mx0b-00115402.pphosted.com with ESMTP id 2s83tp1v12-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 May 2019 21:13:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0IAZxq9RsSoUtyFGCpT7POvOMtLVKKnxqgdmlOH3lps=; b=n0Y5DZoHkvk6MYZRR2T6RDidZi014dVwO1E4cqhcARI8tzczr4YuZIYsA+wEsE6gndiQ28xbkcr1AlyFuYSJIwlkcOP7rUhreu0Xh83c1Qv3ypzBk0WBL3w3YJs5JyfH2j7+nkxc8pQElFGx1kpz0YBqim7PawFEChCfqyUbWPw=
Received: from BL0PR11MB3394.namprd11.prod.outlook.com (10.167.240.87) by BL0PR11MB3218.namprd11.prod.outlook.com (10.167.233.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Thu, 2 May 2019 21:13:55 +0000
Received: from BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::80c:779:fb2f:f54f]) by BL0PR11MB3394.namprd11.prod.outlook.com ([fe80::80c:779:fb2f:f54f%2]) with mapi id 15.20.1835.018; Thu, 2 May 2019 21:13:55 +0000
From: "Border, John" <John.Border@hughes.com>
To: "nwcrg@irtf.org" <nwcrg@irtf.org>
CC: Marie-Jose Montpetit <marie@mjmontpetit.com>, Vincent Roca <vincent.roca@inria.fr>, Lloyd Wood <lloyd.wood@yahoo.co.uk>
Thread-Topic: [nwcrg] RG Last Call for draft "Network coding and satellites"
Thread-Index: AQHU9amHZep+JDQP4UyME7aRMxqQGKZYIQ+g
Date: Thu, 2 May 2019 21:13:55 +0000
Message-ID: <BL0PR11MB33941ECA07714F1024DCAD6290340@BL0PR11MB3394.namprd11.prod.outlook.com>
References: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr>
In-Reply-To: <F25D9E85-DC2E-48F5-8864-95DC6C280FB2@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.85.223.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3899d3cf-ea0a-4fa1-acec-08d6cf4315f9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BL0PR11MB3218;
x-ms-traffictypediagnostic: BL0PR11MB3218:
x-microsoft-antispam-prvs: <BL0PR11MB3218D6D3FCC460681AC4534A90340@BL0PR11MB3218.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(136003)(396003)(366004)(199004)(189003)(51874003)(13464003)(53754006)(86362001)(53546011)(316002)(102836004)(54906003)(6506007)(26005)(52536014)(1730700003)(68736007)(81156014)(8676002)(8936002)(99286004)(81166006)(256004)(76176011)(7696005)(486006)(76116006)(5024004)(14444005)(2351001)(30864003)(11346002)(446003)(66446008)(66476007)(64756008)(476003)(66556008)(71200400001)(71190400001)(33656002)(5660300002)(66946007)(73956011)(6116002)(966005)(74316002)(478600001)(72206003)(3846002)(25786009)(7736002)(66066001)(305945005)(2501003)(6246003)(4326008)(6306002)(53936002)(186003)(2906002)(229853002)(14454004)(6436002)(55016002)(5640700003)(9686003)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR11MB3218; H:BL0PR11MB3394.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: hughes.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wjUn029k21Q+d/AZ9SzgtWrgd6K7NVuE1YrpThJDK65rOXxqYgGexEOgDLDy5rMfdimE6eAkKxvXqeO8umQaFRKG6Qy3Su46LqC88bn9JDGbQv+CRPsDb7W8Qv3zEmOe9qqybBZMxLdav2VrK0hwBexIH8eMvxcd6hAMINdsU2/LtYmvBsyzEcCuujbABUVw/UqMLVyz9Kq4DokTQYdEvKnWilZ8F4Q+jByHxNc01aRYOaxWoooldwbyAhSa99RmkXIy1irIew7381dHiSzfL4XGfusg3BeJyLfLWK1akleqfgsoc4eJWR36FsvL8Y9x5hpu3qVaGzGmw8PUBZEPk+uXiTOa8HTKumMssHOw9+QTuqK/mwlGxGswsbMO8laFMd6tHdYDa5VMt+CbHS/u5uKIAfYtHXvvlIaSlL9Svvc=
Content-Type: multipart/alternative; boundary="_000_BL0PR11MB33941ECA07714F1024DCAD6290340BL0PR11MB3394namp_"
MIME-Version: 1.0
X-OriginatorOrg: hughes.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3899d3cf-ea0a-4fa1-acec-08d6cf4315f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 21:13:55.7546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e1f3187-4610-4ce2-bad1-b92f4ba36ab3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3218
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-02_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905020132
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/mTcLQM_SEZqlOhgd32iaBvfipiQ>
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: Thu, 02 May 2019 21:14:08 -0000

Some comments on the document...

      I definitely agree with Lloyd that the discussion needs to always be clear what is being referred to by "coding".  Forward Error Correction (FEC) coding below the network layer takes us a long way.  At the same time, I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough.  I do see that the referenced taxonomy document includes Forward Erasure Correction.  This “FEC” is described as an application layer technique.  The overlapping use of “FEC” is unfortunate for those of who work down at the lower layers.  In any case, it is not always clear which “FEC” the document is referring to.

      Not that important but…  500 milliseconds is kind of high for the one way delay.  Congestion can get it there (and beyond).  But, we typically talk about 350 milliseconds.

      Section 4.2, 2nd Paragraph

            "Unidirectional" implies (to me) no ACKs.  Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost.  This seems different enough to me to be explained separate from NORM.

      In Sections 4.3 an 4.4, some additional discussion is needed explaining how network coding helps.

      Re Lloyd's comment about Section 4.4…

            I think the point (which needs to be much clearer) is that packets can be lost with sudden link condition changes when ACM cannot react fast enough.  Network coding could be use to compensate for this.  (However, usually this is a rare enough occurrence that the network coding overhead might not be worth it if that was the only thing it was doing.  This leads to the observation that it might take a combination of use cases to justify a particular network coding solution.)

      Section 9

            There is one security consideration that I think needs some discussion.  Theoretically, without some authentication protection, at least with some network coding approaches, an attacker could generate repair packets that alter the original data or at least cause denial of service.

Beyond the document…

      I have talked about this with Nicolas (et al.)…  I am not personally aware of the use of network coding to do any of the things mentioned over satellite networks.  I know of a couple of cases where the equivalent of network coding was used at the application layer.  But, I am hoping something can be developed to use this kind of coding to reduce the impact of recovering from packet loss faster than can be done via end to end retransmission over satellite. This is necessary because encrypted transports such as QUIC eliminate the ability to use PEPs to do the same thing.  I think any such mechanism, though, would require some ability to adapt to changes in latency and packet loss rate.


John


A few document nits…

      Section 2, 1st and 2nd Sentences

            “in satellite system” should be “in a satellite system”.  Not clear what “lays” means here.

            “multi-gateway satellites network” should be “multi-gateway satellite network”.  (Most of the uses cases have nothing to do with multi-gateway, though.)

      Section 3, 2nd Sentence

            Delete the duplicate “where”.

      Section 6, 2nd Sentence

            “that the some scenarios” should be “that some scenarios”.

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

WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dirtf-2Dnwcrg-2Dnetwork-2Dcoding-2Dsatellites_&d=DwIGaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=xPjBNRNdH_plOZd3f1NHC2zBjIGeGVJHWaC71SSw38Y&s=32zN_mPt7oUxDtLocIctXP50qy7zOeyVdjvNk59Flhk&e=

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_nwcrg&d=DwIGaQ&c=dIKa1mMv92xhhFzVXv5A3Q&r=9F44ji63_2hvW5HufmlpP-DFKXuFy4jDtL5PXwKlTqg&m=xPjBNRNdH_plOZd3f1NHC2zBjIGeGVJHWaC71SSw38Y&s=YeRZHRydTmylC7Wm-bPvydTuvdHuUghSRUax72-cCQw&e=