Skip to main content

Network Coding for Satellite Systems
draft-irtf-nwcrg-network-coding-satellites-15

Revision differences

Document history

Date Rev. By Action
2021-01-19
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-01-08
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-12-22
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-12-01
15 (System) RFC Editor state changed to EDIT
2020-11-30
15 (System) IANA Action state changed to No IANA Actions
2020-11-30
15 Colin Perkins IRTF state changed to Sent to the RFC Editor from Waiting for IRTF Chair
2020-11-30
15 Colin Perkins Sent request for publication to the RFC Editor
2020-11-16
15 Vincent Roca IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-11-03
15 Vincent Roca
This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network …
This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network coding techniques above the network OSI layer in satellite communication systems.

The document went through two RG Last Calls (April 2019 and October 2019), it has been shared on the dtn@ietf.org list as well (which generated many challenging yet useful comments from one of the participants), and has been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review.

Following the IESG evaluation, and more particularly Benjamin Kaduk comment, the authors added in v15 related works on VSAT (in)security that calls for traffic encryption. The other comment on related IETF work is well known by the IRTF group and authors. There is no direct reference in this document, but this is the case in RFC 8406 (cited) for instance.
2020-10-30
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-10-30
15 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-15.txt
2020-10-30
15 (System) New version approved
2020-10-30
15 (System) Request for posting confirmation emailed to previous authors: Emmanuel Lochin , Nicolas Kuhn
2020-10-30
15 Nicolas Kuhn Uploaded new revision
2020-10-27
14 Colin Perkins
IESG conflict review completed: "The IESG has concluded that this work is related to IETF work done  in the rmt, tsvwg, and quic WGs, but …
IESG conflict review completed: "The IESG has concluded that this work is related to IETF work done  in the rmt, tsvwg, and quic WGs, but this relationship does not prevent publishing".

There is a comment from Benjamin Kaduk in the datatracker at https://datatracker.ietf.org/doc/conflict-review-irtf-nwcrg-network-coding-satellites/ballot/ – does this require a document update?
2020-10-27
14 Colin Perkins Tag IESG Review Completed set.
2020-10-27
14 Colin Perkins IRTF state changed to Waiting for Document Shepherd from In IESG Review
2020-06-24
14 (System) IANA Review state changed to IANA OK - No Actions Needed
2020-06-24
14 Michelle Cotton
(Via drafts-eval-comment@iana.org): IESG/Authors/IRTF Chair:

The IANA Functions Operator has reviewed draft-irtf-nwcrg-network-coding-satellites-14 and has the following comments:

We understand that this document doesn't require any …
(Via drafts-eval-comment@iana.org): IESG/Authors/IRTF Chair:

The IANA Functions Operator has reviewed draft-irtf-nwcrg-network-coding-satellites-14 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services
2020-06-23
14 Colin Perkins IETF conflict review initiated - see conflict-review-irtf-nwcrg-network-coding-satellites
2020-06-23
14 Colin Perkins -14 addressed IRSG final poll comments; sending for IESG conflict review.
2020-06-23
14 Colin Perkins IRTF state changed to In IESG Review from Waiting for Document Shepherd
2020-05-29
14 (System) Revised ID Needed tag cleared
2020-05-29
14 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-14.txt
2020-05-29
14 (System) New version approved
2020-05-29
14 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2020-05-29
14 Nicolas Kuhn Uploaded new revision
2020-05-25
13 Colin Perkins IRSG poll completed. Needs updated draft to address nits, then ready to progress.

Poll results at https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ballot/irsg/
2020-05-25
13 Colin Perkins Tag Revised I-D Needed set.
2020-05-25
13 Colin Perkins IRTF state changed to Waiting for Document Shepherd from In IRSG Poll
2020-05-25
13 Colin Perkins Closed "IRSG Approve" ballot
2020-05-22
13 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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?
2020-05-22
13 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2020-05-22
13 Lars Eggert
[Ballot comment]
Section 3.4., paragraph 1:
>    This use-case considers using network coding in the scenario where a
>    lossy WIFI link is …
[Ballot comment]
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.)
2020-05-22
13 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2020-05-20
13 Carsten Bormann
[Ballot comment]
I'm always a bit surprised when people are still paying lip service to
the OSI model (and then call it ISO model); in …
[Ballot comment]
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!
2020-05-20
13 Carsten Bormann [Ballot Position Update] New position, Yes, has been recorded for Carsten Bormann
2020-05-19
13 Jianfei(Jeffrey) HE
[Ballot comment]
I reviewed it and think it is ready to go.
The use cases are clearly described and helpful to understand the application of …
[Ballot comment]
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.
2020-05-19
13 Jianfei(Jeffrey) HE [Ballot Position Update] New position, Yes, has been recorded for Jianfei He
2020-05-15
13 Rodney Van Meter
[Ballot comment]
I skimmed it.  Other than my uncertainty as to whether "this is not an IETF product" is appropriate and accurate, I have no …
[Ballot comment]
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.
2020-05-15
13 Rodney Van Meter [Ballot Position Update] New position, No Objection, has been recorded for Rodney Van Meter
2020-05-14
13 Dirk Kutscher [Ballot Position Update] New position, Yes, has been recorded for Dirk Kutscher
2020-05-11
13 Melinda Shore
[Ballot comment]
This is not my area of expertise but I thought it was clear and easily understandable and that it did not contain any …
[Ballot comment]
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.
2020-05-11
13 Melinda Shore [Ballot Position Update] New position, Yes, has been recorded for Melinda Shore
2020-05-05
13 David Oran
[Ballot comment]
I reviewed this during last call and thought it was essentially ready then. I quickly skimmed the new version and I think it's …
[Ballot comment]
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.
2020-05-05
13 David Oran [Ballot Position Update] New position, No Objection, has been recorded for David Oran
2020-05-05
13 Mirja Kühlewind
[Ballot comment]
Comments were already sent by mail; repeating here for the record:

I reviewed this document and think it is ready to go.

A …
[Ballot comment]
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…?
2020-05-05
13 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2020-05-05
13 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2020-05-04
13 Colin Perkins IRTF state changed to In IRSG Poll from Waiting for IRTF Chair
2020-05-04
13 Colin Perkins Created IRSG Ballot
2020-05-04
13 Colin Perkins IRSG review completed. Ready for final poll.
2020-05-04
13 Colin Perkins IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-04-27
13 (System) Revised ID Needed tag cleared
2020-04-27
13 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-13.txt
2020-04-27
13 (System) New version accepted (logged-in submitter: Nicolas Kuhn)
2020-04-27
13 Nicolas Kuhn Uploaded new revision
2020-04-27
12 Colin Perkins Minor revision needed, to address review from Mirja.
2020-04-27
12 Colin Perkins Tag Revised I-D Needed set.
2020-04-27
12 Colin Perkins IRTF state changed to Waiting for Document Shepherd from Awaiting IRSG Reviews
2020-04-20
12 Colin Perkins IRTF state changed to Awaiting IRSG Reviews from Waiting for Document Shepherd
2020-04-14
12 (System) Revised ID Needed tag cleared
2020-04-14
12 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-12.txt
2020-04-14
12 (System) New version approved
2020-04-14
12 (System) Request for posting confirmation emailed to previous authors: irtf-chair@irtf.org, nwcrg-chairs@ietf.org, Emmanuel Lochin , Nicolas Kuhn
2020-04-14
12 Nicolas Kuhn Uploaded new revision
2020-04-13
11 Colin Perkins Revised I-D needed to address editorial nits, before IRSG review.
2020-04-13
11 Colin Perkins Tag Revised I-D Needed set.
2020-04-13
11 Colin Perkins IRTF state changed to Waiting for Document Shepherd from Waiting for IRTF Chair
2020-04-13
11 Colin Perkins Changed consensus to Yes from Unknown
2020-04-05
11 Vincent Roca Intended Status changed to Informational from None
2020-03-26
11 Vincent Roca IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-03-25
11 Vincent Roca
This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network …
This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network coding techniques above the network OSI layer in satellite communication systems.

The document went through two RG Last Calls (April 2019 and October 2019), it has been shared on the dtn@ietf.org list as well (which generated many challenging yet useful comments from one of the participants), and has been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review.
2020-03-09
11 Vincent Roca IRTF state changed to Waiting for Document Shepherd from In RG Last Call
2020-02-28
11 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-11.txt
2020-02-28
11 (System) New version approved
2020-02-28
11 (System) Request for posting confirmation emailed to previous authors: Emmanuel Lochin , Nicolas Kuhn
2020-02-28
11 Nicolas Kuhn Uploaded new revision
2020-02-27
10 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-10.txt
2020-02-27
10 (System) New version approved
2020-02-27
10 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2020-02-27
10 Nicolas Kuhn Uploaded new revision
2019-12-11
09 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-09.txt
2019-12-11
09 (System) New version approved
2019-12-11
09 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-12-11
09 Nicolas Kuhn Uploaded new revision
2019-11-18
08 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-08.txt
2019-11-18
08 (System) New version approved
2019-11-18
08 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-11-18
08 Nicolas Kuhn Uploaded new revision
2019-10-30
07 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-07.txt
2019-10-30
07 (System) New version approved
2019-10-30
07 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-10-30
07 Nicolas Kuhn Uploaded new revision
2019-08-20
06 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-06.txt
2019-08-20
06 (System) New version approved
2019-08-20
06 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-08-20
06 Nicolas Kuhn Uploaded new revision
2019-06-04
05 (System) Revised ID Needed tag cleared
2019-06-04
05 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-05.txt
2019-06-04
05 (System) New version approved
2019-06-04
05 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-06-04
05 Nicolas Kuhn Uploaded new revision
2019-05-13
04 Vincent Roca RG Last Call started April 18th for 3 weeks till May 9th.
2019-05-13
04 Vincent Roca Tag Revised I-D Needed set.
2019-05-13
04 Vincent Roca IRTF state changed to In RG Last Call
2019-05-13
04 Vincent Roca Notification list changed to Vincent Roca <vincent.roca@inria.fr>
2019-05-13
04 Vincent Roca Document shepherd changed to Vincent Roca
2019-01-03
04 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-04.txt
2019-01-03
04 (System) New version approved
2019-01-03
04 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2019-01-03
04 Nicolas Kuhn Uploaded new revision
2018-12-11
03 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-03.txt
2018-12-11
03 (System) New version approved
2018-12-11
03 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2018-12-11
03 Nicolas Kuhn Uploaded new revision
2018-11-12
02 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-02.txt
2018-11-12
02 (System) New version approved
2018-11-12
02 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2018-11-12
02 Nicolas Kuhn Uploaded new revision
2018-11-11
01 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-01.txt
2018-11-11
01 (System) New version approved
2018-11-11
01 (System) Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin
2018-11-11
01 Nicolas Kuhn Uploaded new revision
2018-10-17
00 Vincent Roca This document now replaces draft-kuhn-nwcrg-network-coding-satellites instead of None
2018-10-05
00 Nicolas Kuhn New version available: draft-irtf-nwcrg-network-coding-satellites-00.txt
2018-10-05
00 (System) WG -00 approved
2018-10-05
00 Nicolas Kuhn Set submitter to "Nicolas Kuhn ", replaces to (none) and sent approval email to group chairs: nwcrg-chairs@ietf.org
2018-10-05
00 Nicolas Kuhn Uploaded new revision