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

["Border, John" <[e-mail]>]

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 <[e-mail]> On Behalf Of Vincent Roca
Sent: Thursday, April 18, 2019 1:42 AM
To: [e-mail]
Cc: Vincent Roca <[e-mail]>; Marie-Jose Montpetit <[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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=