Network Coding for Satellite Systems
Note: This ballot was opened for revision 13 and is now closed.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
Carsten Bormann Yes
Comment (2020-05-20 for -13)
I'm always a bit surprised when people are still paying lip service to the OSI model (and then call it ISO model); in the I*TF context by now I'm expecting references to the Internet layer model (RFC 1122). Other nits have been sent to the authors. Thank you for compiling this information!
Spencer Dawkins Yes
Comment (2020-05-22 for -13)
My ballot was previously sent to the IRSG via e-mail, but I'm recording it here, since the datatracker now allows at-large IRSG members to enter their own ballots. A nit - "A glossary is proposed in Section 6 to clarify the terminology use throughout the document." should probably be something like "A glossary is included in Section 6 to clarify the terminology use throughout the document." I'm not sure I can parse While there is an active research Community working on network coding techniques above the network layer in general and in SATCOM in particular, not much of this work made it to commercial systems in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the satellite industry. Is "made it to commercial systems" something like "has been deployed in commercial systems"? Now that you are requesting publication, you can probably change In this context, this document aims at ^^^^^^ identifying opportunities for further usage of network coding in ^^^^^^^^^^^ commercial SATCOM networks. to In this context, this document identifies opportunities for further usage of network coding in ^^^^^^^^^ commercial SATCOM networks. I know it's hard to say clearly, but o Forward Erasure Correction (FEC) (also called Application-Level FEC) operates in and above the network layer and targets packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ loss recovery. "in and above the network layer" is ambiguous. I think it means "in, above, or both", but it's hard to read. Perhaps o Forward Erasure Correction (FEC) (also called Application-Level FEC) operates above the PHYsical (PHY) layer and targets packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ loss recovery. (since you used that term in the previous bullet), or "above the link payer" if that term is more accurate. Using ISO terms to describe an Internet protocol stack is hard ("subnetwork layer" is another choice) :-) In There are multiple SATCOM systems, for example broadcast TV, point to point communication or IoT and monitoring ^^^^^^^^^^^^^^^^^^ Is "IoT and monitoring" one term or two? If "two", "monitoring" is vague (would this include medical monitoring?) If you can qualify "monitoring" in any way, that would be clearer to me. In This could also be achieved by using other multicast or broadcast systems, such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or File Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Both NORM and FLUTE are limited to block coding, none of them supporting ^^^^^^^^^^^^^^ more flexible sliding window encoding schemes that allow decoding before receiving the whole block an added delay benefit [RFC8406][RFC8681]. should probably be "; neither of them" with a semicolon. This text Depending on the use-case (e.g., very high frequency bands, mobile users) or ^^^^^^^^ depending on the deployment use-cases (e.g., performance of the ^^^^^^^^^ network between each individual data block), the relevance of adding network coding is different. uses the same term in two very different contexts, and only one is qualified. Is there a qualifier you can attach to the first use? Or could these examples be merged into one list of use case examples? In this text, Many SATCOM systems typically use Performance Enhancing Proxy (PEP) RFC 3135 [RFC3135]. PEPs usually split end-to-end connections and forward transport or application layer packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulation. ^^^^^^^^^^^^^^^^^^^ PEPs contribute to mitigate congestion in a SATCOM systems by limiting the impact of long delays on Internet protocols. A PEP mechanism could also include network coding operation and thus support the use-cases that have been discussed in the Section 3 of this document. Are these PHY (used previously) and Link Layers? Or something else? If this is a new term for the same thing, it would be great to pick one term and use it consistently. I think this Communications among deep-space platforms and terrestrial gateways can be a challenge. Reliable end-to-end (E2E) communications over such paths must cope with very long delays and frequent link disruptions; indeed, E2E connectivity may be available only ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ intermittently. Delay/Disruption Tolerant Networking (DTN) [RFC4838] ^^^^^^^^^^^^^^ is a solution to enable reliable internetworking space communications where both standard ad-hoc routing and E2E Internet protocols cannot be used. Moreover, DTN can also be seen as an alternative solution to transfer data between a central PEP and a remote PEP. is more correctly "E2E connectivity may only be available intermittently, if at all" - there may not be a continuous end-to-end path at all in DTN, or do I misunderstand? In this text, o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for satellite communications include compression, caching and TCP ^^^ acceleration; ^^^^^^^^^^^^ I know "TCP acceleration" is the correct marketing term (I worked at a company that sold them, in my darkest past), but would it be correct to say something like "TCP ACK spoofing", or "TCP connection splicing", which is I think the 3GPP term?
Jianfei(Jeffrey) HE Yes
Comment (2020-05-19 for -13)
I reviewed it and think it is ready to go. The use cases are clearly described and helpful to understand the application of network coding in Satellite systems. One minor thing in its reference part somehow comes to my attention : ) It looks strange to quote a draft written in 2017 with "work in progress". Should these (as below) be changed to "expired" to keep consistent with their status in the datatracker? [I-D.chin-nfvrg-cloud-5g-core-structure-yang] Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G Core structure", draft-chin-nfvrg-cloud-5g-core-structure- yang-00 (work in progress), December 2017. [I-D.vazquez-nfvrg-netcod-function-virtualization] Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, "Network Coding Function Virtualization", draft-vazquez- nfvrg-netcod-function-virtualization-02 (work in progress), November 2017.
Dirk Kutscher Yes
Mirja Kühlewind Yes
Comment (2020-05-05 for -13)
Comments were already sent by mail; repeating here for the record: I reviewed this document and think it is ready to go. A few small editorial points: Based on the RFC style guide you cannot have references in the abstract (meaning just remove the actual reference and only write RFC8406). Also I think the abstract could be a bit short and more crisp. And while there is an nice and quiet extensive glossary at the end, there are a couple of mostly well-know acronyms which might still be worth spelling out on first occurrence, given the desired audience: mainly FEC, CPE, RTT, and DTN. And finally the security considerations section is quite short, which is fine as. I don’t think there is much to discuss, but maybe there is a good reference to give to another NC document that has more discussion about security implication…?
Melinda Shore Yes
Comment (2020-05-11 for -13)
This is not my area of expertise but I thought it was clear and easily understandable and that it did not contain any obviously problematic material. One minor typo in the last sentence of section 3.4: "In this use-case, adding network coding techniques will prevent the end-to-end retransmission from occurring since the packet losses would probably recovered." I don't know if that should be "recover" or "be recovered" (or something else entirely). I'm also curious how various network coding mechanisms would or would not work for encrypted traffic (for example, mixing), but I am comfortable with that being out-of-scope for this document.
Lars Eggert No Objection
Comment (2020-05-22 for -13)
Section 3.4., paragraph 1: > This use-case considers using network coding in the scenario where a > lossy WIFI link is used to connect to the SATCOM network. When > encrypted end-to-end applications based on UDP are used, a > Performance Enhancing Proxy (PEP) cannot operate hence other > mechanism need to be used. The WIFI packet losses will result in an > end-to-end retransmission that will harm the end-user quality of > experience and poorly utilize SATCOM bottleneck resource for non- > revenue generating traffic. In this use-case, adding network coding > techniques will prevent the end-to-end retransmission from occurring > since the packet losses would probably recovered. It's 2020. 802.11 reaches multiple Gs of application-level goodput. It couldn't do that if it didn't handle L2 loss efficiently already. Where are these hypothetical lossy WLANs? Also, if this were an issue it wouldn't be a satcom-specific one, so it's not clear why it needs to be discussed in this draft (the WAN RTT is >> the LAN one, even without a sat link involved.)
David Oran No Objection
Comment (2020-05-05 for -13)
I reviewed this during last call and thought it was essentially ready then. I quickly skimmed the new version and I think it's ready to go.
Rodney Van Meter No Objection
Comment (2020-05-15 for -13)
I skimmed it. Other than my uncertainty as to whether "this is not an IETF product" is appropriate and accurate, I have no objections. I will say I found the ASCII art system figures a little harder to parse than most such, largely because I found it took quite a bit of attention to parse which are unidirectional, high-latency links and which are bidirectional, low-latency links.