Draft: draft-irtf-nwcrg-network-coding-satellites-10

Commentary: Section 1 : typo : ... retransmissions add significant delays because especially in geostationary system with over 0.7 second round - trip delays . I think " because " should be removed . Section 2 : typo : " that one single gateway support . " = supports Section 3.2 : typo : " to better utilize a satellite broadcast capabilities . " = remove " a"Reference : flexible sliding window encoding schemes that allow decoding before receiving the whole block an delay benefit [ RFC8406 ] . I suggest you now reference : RFC 8681 Sliding Window Random Linear Code ( RLC ) Forward Erasure Correction ( FEC ) Schemes for FECFRAME as it is available . Section 3.4 : maybe the following sentence is too strong : adding network coding techniques will prevent the end - to - end retransmission from occurring since the packet losses will be recovered . I 'd rather say " will reduce the need for end - to - end retransmissions since packet losses would probably be recovered . " Section 4.1 : Last sentence : adding a reference to the coding and CC document makes sense here . Section 4.2 : typo : " discussed on the previous section . " = " discussed in section 3.5 . " Section 4.3 : Could you check whether this is VNF or NFV ? Both are used . Please , also add an expansion of those acronyms . Throughout the document : please replace " draft " by " document " as you probably expect it not to remain in the " draft " status forever ... 
 Closed by PR 
 It is said : The objective is to contribute to a larger deployment of network coding techniques in SATCOM to complement already implemented loss recovery mechanisms . I 'm just wondering what " already implemented loss recovery mechanisms " refer to . I know there are bit error detection / recovery mechanism , of course TCP will recover from losses , but what do you mean here exactly ? 
 Covered by PR
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  It conforms to the directions
found in the NWCRG taxonomy RFC8406.  Thus, the scope of the document
is network coding as a linear combination of packets in and above the
network layer.  Physical and MAC layer coding are beyond the scope of
the document.  The draft focuses on a multi-gateway satellite system
and identifies the use-cases where network coding provides
significant performance improvements.  The objective is to contribute
to a larger deployment of network coding techniques in SATCOM to
complement already implemented loss recovery mechanisms.  The draft
also identifies open research issues related to the deployment of
network coding in SATCOM systems.
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  It conforms to the directions
found in the NWCRG taxonomy RFC8406.  Thus, the scope of the document
is network coding as a linear combination of packets in and above the
network layer.  Physical and MAC layer coding are beyond the scope of
the document.  The document focuses on a multi-gateway satellite
system and identifies the use-cases where network coding provides
significant performance improvements.  The objective is to contribute
to a larger deployment of network coding techniques in and above the
network layer in satellite communication systems.  These systems
generally exploit PHY layer loss recovery mechanisms.  The document
also identifies open research issues related to the deployment of
network coding in satellite communication systems.
As will be shown in this draft, the implementation of network coding
techniques above the network layer of the ISO model, at application
or transport layers, offers an opportunity for improving the end-to-
end performance of SATCOM systems.  While physical- and link-layer
coding error protection is usually enough to provide Quasi-Error Free
transmission thus minimizing packet loss, when the physical and link
layers coding fail or that residual errors create packet losses that
greatly interfere with Internet protocols, retransmissions add
significant delays because especially in geostationary system with
over 0.7 second round-trip delays.  Hence the use of network coding
at the upper layers can improve the quality of service in SATCOM
subnetworks and eventually favorably impact the experience of end
users.
As will be shown in this document, the implementation of network
coding techniques above the network layer of the ISO model, at
application or transport layers, offers an opportunity for improving
the end-to-end performance of SATCOM systems.  While physical- and
link-layer coding error protection is usually enough to provide
Quasi-Error Free transmission thus minimizing packet loss, when the
physical and link layers coding fail or that residual errors create
packet losses that greatly interfere with Internet protocols,
retransmissions add significant delays, in particular in
geostationary system with over 0.7 second round-trip delays.  Hence
the use of network coding at the upper layers can improve the quality
of service in SATCOM subnetworks and eventually favorably impact the
experience of end users.
There are multiple SATCOM systems, for example broadcast TV, point to
point communication or IoT and monitoring.  Therefore, depending on
the purpose of the system, the associated ground segments
architecture will be different.  This section focuses on a satellite
system that follows the ETSI DVB standards to provide broadband
Internet access via ground-based gateways.  One must note that the
overall data capacity of one satellite may be higher than the
capacity that one single gateway support.  Hence, there are usually
multiple gateways for one unique satellite platform.
There are multiple SATCOM systems, for example broadcast TV, point to
point communication or IoT and monitoring.  Therefore, depending on
the purpose of the system, the associated ground segments
architecture will be different.  This section focuses on a satellite
system that follows the ETSI DVB standards to provide broadband
Internet access via ground-based gateways.  One must note that the
overall data capacity of one satellite may be higher than the
capacity that one single gateway supports.  Hence, there are usually
multiple gateways for one unique satellite platform.
The use of multicast servers is one way to better utilize a satellite
broadcast capabilities.  Multicast is proposed in the SHINE ESA
project I-D.vazquez-nfvrg-netcod-function-virtualization SHINE.  This
use-case considers adding redundancy to a multicast flow depending on
what has been received by different end-users, resulting in non-
negligible savings of the scarce SATCOM resources.  This scenario is
shown in fig:rel_multi.
The use of multicast servers is one way to better utilize satellite
broadcast capabilities.  Multicast is proposed in the SHINE ESA
project I-D.vazquez-nfvrg-netcod-function-virtualization SHINE.  This
use-case considers adding redundancy to a multicast flow depending on
what has been received by different end-users, resulting in non-
negligible savings of the scarce SATCOM resources.  This scenario is
shown in fig:rel_multi.
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.
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 RFC8681.
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 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 will be
recovered.
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 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.
Deploying network coding in the PEP could be relevant and be
independent from the specifics of a SATCOM link.  This however leads
to research questions dealing with the potential interaction between
network coding and congestion control.
This problem has been tackled in the past by the deployment of
physical-layer error-correction codes, but there remains questions on
adapting the coding overhead and added delay for, e.g., the quickly
varying channel conditions use-case where ACM may not be reacting
quickly enough as was discussed on the previous section.
In the emerging virtualized network infrastructure, network coding
could be easily deployed as a VNF.  The next generation of SATCOM
ground segments will rely on a virtualized environment to integrate
to terrestrial networks.  This trend towards NFV is also central to
5G and next generation cellular networks, making this research
applicable to other deployment scenarios I-D.chin-nfvrg-cloud-5g-
core-structure-yang.  As one example, the network coding VNF
deployment in a virtualized environment has been presented in I-
D.vazquez-nfvrg-netcod-function-virtualization.
This problem has been tackled in the past by the deployment of
physical-layer error-correction codes, but there remains questions on
adapting the coding overhead and added delay for, e.g., the quickly
varying channel conditions use-case where ACM may not be reacting
quickly enough as was discussed in subsec:varying.
In the emerging virtualized network infrastructure, network coding
could be easily deployed as a Virtual Network Functions (VNF).  The
next generation of SATCOM ground segments will rely on a virtualized
environment to integrate to terrestrial networks.  This trend towards
Network Function Virtualization (NFV) is also central to 5G and next
generation cellular networks, making this research applicable to
other deployment scenarios I-D.chin-nfvrg-cloud-5g-core-structure-
yang.  As one example, the network coding VNF deployment in a
virtualized environment has been presented in I-D.vazquez-nfvrg-
netcod-function-virtualization.
Even though this document focuses on satellite systems, it is worth
pointing out that some scenarios proposed here may be relevant to
other wireless telecommunication systems.  As one example, the
generic architecture proposed in fig:sat_gateway may be mapped onto
cellular networks as follows: the 'network function' block gathers
some of the functions of the Evolved Packet Core subsystem, while the
'access gateway' and 'physical gateway' blocks gather the same type
of functions as the Universal Mobile Terrestrial Radio Access
Network.  This mapping extends the opportunities identified in this
draft since they may also be relevant for cellular networks.
Even though this document focuses on satellite systems, it is worth
pointing out that some scenarios proposed here may be relevant to
other wireless telecommunication systems.  As one example, the
generic architecture proposed in fig:sat_gateway may be mapped onto
cellular networks as follows: the 'network function' block gathers
some of the functions of the Evolved Packet Core subsystem, while the
'access gateway' and 'physical gateway' blocks gather the same type
of functions as the Universal Mobile Terrestrial Radio Access
Network.  This mapping extends the opportunities identified in this
document since they may also be relevant for cellular networks.
VNF: Virtual Network Function.
VNF: Virtual Network Function - implementation of a network
function using software.