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

Commentary: Abstract p 1 " cope from " -"cope with " S 1 Introduction p 2 " cope from " -"cope with " S 1 Introduction p 2 " link layers " -"link layer " S 1 Introduction p 3 " an non - negligible " -"a non - negligible " S 1 Introduction p 3 " FEC ... operate " -"FEC ... operates " S 1 Introduction p 3 " Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document ... considers coding ... as a linear combination and not as a content coding " do n't we want to use the standard terms " channel coding " and " source coding " as in RFC 8406 section 3 ? also do we want to restrict solution approaches in the Abstract and Introduction of what appears to be a problem space overview ? S 1 Introduction p 3 Figure 1 E2E , NC , IntraF , InterF , SPC , MPC abbrevations / acronyms neither spelled out on first use ( as they were in earlier versions of this draft ) , included in this draft 's glossary , nor defined in RFC 8406 S 1 Introduction p 4 " PEP ... include " -"PEP ... including " S 2 A note on satellite topology p 5 acronyms DVB etc . not spelled out on first use etc . S 2 A note ... p 6 Figure 2 seems to cover only the case where a single [ simple ] user device is connected by the satellite terminal ( leaves out e.g. firewall / router on user end of satellite link ) ; if this is intentional just to avoid unnecessary complication of the figure , a note explaining this would be in order S 3.1 Two - way channel mode p 7 " computationnal " -"computational " S 3.2 Reliable multicast p 8 NORM does not require a feedback link , although it benefits significantly from one , and a single receiver with a feedback link can NACK on behalf of all receivers for all commonly experienced impairments ; also " for security purpose " -"for security purposes " or " for a security purpose " S 3.1 & S 3.2 Do we want to consider more general multi - source multi - sink multicast topologies than the base case in 3.1 , or combinations of 3.1 & 3.2 ? S 3.3 Hybrid access p 9 " transport level " -"transport layer " , " using multiple path does not " -"using multiple paths does not " , " appart " -"apart " , " envisionned " -"envisioned " S 3.4 Dealing with LAN losses p 9 " cope from " -"cope with " S 3.4 Dealing with LAN losses p 10 Figure 6 is confusing : it omits explicitly showing the WiLAN ; it uses an undefined label " C " ( presumably indicating something relating to encryption , but why would that end at the Access Gateway ? ) S 3.5 Dealing with varying channel conditions p 10 " cope from " -"cope with " S 3.5 Dealing with varying ... p 10 " physical - layer codes could not guarantee " -"physical - layer codes could not efficiently guarantee " as heavy FEC could be used always even when channel conditions are good S 3.5 Dealing with varying ... p 10 " mechanisms that is " -"mechanisms that are " , " higher layers redundancy " -"higher layer redundancy " , " chosen band induce a required " -"chosen band induces a required " or " chosen band requires a " S 3.5 Dealing with varying ... p 10 discussion of use cases and deployment use cases is confusing S 3.5 Dealing with varying ... p 10 Figure 7 again uses undefined label " C " S 3.6 Improving the gateway handovers p 11 " The control plane manager is in charge of taking the decision to change the communication gateway and the consequent routes . " There may not always be an explicit control plane manager . S 4 Research challenges p 11 " This section proposes to discuss few research challenges related to the introduction and the use of ... " Do we mean " This section identifies a few research challenges related to the introduction and the use of ... " or " This section proposes a few potential approaches to introduce and use ... " ? S 4.1 On the joint - use of coding techniques and congestion control in SATCOM systems p 12 transparent transport layer PEPs are increasingly difficult to insert due to TLS ; the NORM Proxy ( NORP ) might deserve a mention here ; also " leads to research question " -"leads to research questions " S 4.2 On the efficient usage of satellite ressource p 12 HARQ / incremental redundancy ARQ / adaptive FEC might deserve a mention here ; also " ressource " -"resource " S 4.3 Interaction with virtualized satellite gateways and terminals p 12 " VNF functions deployment " -"VNF deployment " , " an efficient radio usage " -"efficient radio usage " , " a virtualized SATCOM terminals " -"virtualized SATCOM equipment " , " limited buffered equipments " -"limited buffer capacities " S 4.4 Delay / Disruption Tolerant Networks p 12 " In the context of deep - space communications , establishing communications from terrestrial gateways to satellite platforms " -"Communications among deep - space platforms and terrestrial gateways " S 4.4 DTN p 12 - 13 " such links " -"such paths " ; " disruptions . " -"disruptions ; indeed , contemporaneous   may be available only intermittently or never . " ? S 4.4 DTN p 13 dtnrg members have been experimenting with NORM as a DTN Bundle Protocol convergence layer ( bundle transport protocol for an E2E Internet path comprising a single hop in a DTN ) 5 Conclusion p 13 " ' network function ' block gather " -"'network function ' block gathers " 8 Security Considerations p 14 " togething " -"together " 
 Discussed by PR
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  This document follows the
taxonomy document RFC8406 and considers coding as a linear
combination of packets that operate above the network layer.  In this
context, this memo details a multi-gateway satellite system to
identify use-cases where coding is relevant.  As example, coding
operating above the network layer can be exploited to cope from
residual losses or provide reliable multicast services.  The
objective is to contribute to a larger deployment of such techniques
in SATCOM systems.  This memo also identifies open research issues
related to the deployment of coding in SATCOM systems, such as the
interaction between congestion controls and coding techniques.
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  This document follows the
taxonomy document RFC8406 and considers coding as a linear
combination of packets that operate in and above the network layer.
In this context, this memo details a multi-gateway satellite system
to identify use-cases where coding is relevant.  As example, coding
operating in and above the network layer can be exploited to cope
with residual losses or provide reliable multicast services.  The
objective is to contribute to a larger deployment of such techniques
in SATCOM systems.  This memo also identifies open research issues
related to the deployment of coding in SATCOM systems, such as the
interaction between congestion controls and coding techniques.
Guaranteeing both physical-layer robustness and efficient usage of
the radio resource has been in the core design of SATellite
COMmunication (SATCOM) systems.  The trade-off often resided in how
much redundancy a system adds to cope from link impairments, without
reducing the goodput when the channel quality is good.  There is
usually enough redundancy to guarantee a Quasi-Error Free
transmission.  The recovery time depends on the encoding block size.
Considering for instance geostationary satellite system (GEO),
physical or link layers erasure coding mechanisms recover
transmission losses within a negligible delay compared to link delay.
However, when retransmissions are triggered, this leads to an non-
negligible additional delay in particular over GEO link.  Further
exploiting coding techniques at application or transport layers is an
opportunity for releasing constraints on the physical layer and
improving the performance of SATCOM systems.
Guaranteeing both physical-layer robustness and efficient usage of
the radio resource has been in the core design of SATellite
COMmunication (SATCOM) systems.  The trade-off often resided in how
much redundancy a system adds to cope with link impairments, without
reducing the goodput when the channel quality is good.  There is
usually enough redundancy to guarantee a Quasi-Error Free
transmission.  The recovery time depends on the encoding block size.
Considering for instance geostationary satellite system (GEO),
physical or link layer erasure coding mechanisms recover transmission
losses within a negligible delay compared to link delay.  However,
when retransmissions are triggered, this leads to a non-negligible
additional delay in particular over GEO link.  Further exploiting
coding techniques at application or transport layers is an
opportunity for releasing constraints on the physical layer and
improving the performance of SATCOM systems.
FEC (also called Application-Level FEC) operate in and above the
network layer.
FEC (also called Application-Level FEC) operates in and above the
network layer.
This section details use-cases where coding techniques could provide
interesting features for SATCOM systems.
This section details use-cases where coding techniques could provide
interesting features for SATCOM systems.  Combination of the
presented use-cases could also be relevant.
Satellite terminal A sends a flow A and satellite terminal B sends a
flow B to a coding server.  The coding server sends a combination of
both terminal flows.  This results in non-negligible capacity savings
and has been demonstrated ASMS2010.  In the proposed example, a
dedicated coding server is introduced.  Its location could be changed
depending on the deployment use-case.  With On-Board Processing
satellite payloads, the coding operations could be done at the
satellite level; although this would require lots of computationnal
ressource on-board and may not be relevant with today's payloads.
Satellite terminal A sends a flow A and satellite terminal B sends a
flow B to a coding server.  The coding server sends a combination of
both terminal flows.  This results in non-negligible capacity savings
and has been demonstrated ASMS2010.  In the proposed example, a
dedicated coding server is introduced.  Its location could be changed
depending on the deployment use-case.  With On-Board Processing
satellite payloads, the coding operations could be done at the
satellite level; although this would require lots of computational
ressource on-board and may not be relevant with today's payloads.
This could be achieved by using other multicast or broadcast systems,
such as NACK-Oriented Reliable Multicast (NORM) RFC5740 in situations
where a feedback link is available, or File Delivery over
Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both
NORM and FLUTE are limited to block coding, none of them supporting
sliding window encoding schemes RFC8406.  Note that although FLUTE is
defined as an unidirectional protocol, the RFC proposes a
bidirectional communication method to enable full reliability
transfer and for security purpose.
This use-case considers the use of multiple path management with
coding at the transport level to increase the reliability and/or the
total capacity (using multiple path does not guarantee an improvement
of both the reliability and the total capacity).  We propose an
illustration for this scenario in fig:hyb_access.  This use-case is
inspired from the Broadband Access via Integrated Terrestrial
Satellite Systems (BATS) project and has been published as an ETSI
Technical Report ETSITR2017.  This kind of architecture is also
discussed in the TCPM working group I-D.ietf-tcpm-converters.
To cope with packet loss (due to either end-user mobility or
physical-layer impairments), coding techniques could be introduced
both at the CPE and at the concentrator.  Appart from packet losses,
other gains could be envisionned, such as a better tolerance to out-
of-order packets which occur when exploited links exhibit high
asymetry in terms of RTT.  Depending on the ground architecture I-
D.chin-nfvrg-cloud-5g-core-structure-yang SAT2017, some equipments
might be hosting both SATCOM and cellular functions.
This could 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.  Note that
both NORM and FLUTE are limited to block coding, none of them
supporting sliding window encoding schemes RFC8406.  Note that
although FLUTE is defined as an unidirectional protocol, the RFC
proposes a bidirectional communication method to enable full
reliability transfer and for security purposes.
This use-case considers the use of multiple path management with
coding at the transport layer to increase the reliability and/or the
total capacity (using multiple paths does not guarantee an
improvement of both the reliability and the total capacity).  We
propose an illustration for this scenario in fig:hyb_access.  This
use-case is inspired from the Broadband Access via Integrated
Terrestrial Satellite Systems (BATS) project and has been published
as an ETSI Technical Report ETSITR2017.  This kind of architecture is
also discussed in the TCPM working group I-D.ietf-tcpm-converters.
To cope with packet loss (due to either end-user mobility or
physical-layer impairments), coding techniques could be introduced
both at the CPE and at the concentrator.  Apart from packet losses,
other gains could be envisioned, such as a better tolerance to out-
of-order packets which occur when exploited links exhibit high
asymetry in terms of RTT.  Depending on the ground architecture I-
D.chin-nfvrg-cloud-5g-core-structure-yang SAT2017, some equipments
might be hosting both SATCOM and cellular functions.
This use-case considers the usage of coding techniques to cope from
cases where the end user connects to the satellite terminal with a
Wi-Fi link that exhibits losses.  In the case of encrypted end-to-end
applications based on UDP, PEP cannot operate.  The Wi-Fi losses
result in an end-to-end retransmission that would harm the quality of
experience of the end user.
This use-case considers the usage of coding techniques to cope with
cases where the end user connects to the satellite terminal with a
Wi-Fi link that exhibits losses.  In the case of encrypted end-to-end
applications based on UDP, PEP cannot operate.  The Wi-Fi losses
result in an end-to-end retransmission that would harm the quality of
experience of the end user.
This use-case considers the usage of coding techniques to cope from
cases where channel condition can change in less than a second and
where the physical-layer codes could not guarantee a Quasi-Error-Free
(QEF) transmission.
The architecture is recalled in fig:varying_capa.  In these cases,
the mechanisms that is exploited to adapt the physical-layer codes
(Adaptative Coding and Modulation (ACM)) may adapt the modulation and
coding in time: remaining errors could be recovered with higher
layers redundancy packets.  Coding may be applied on IP packets or on
layer-2 proprietary format packets.
This use-case is mostly relevant when mobile users are considered or
when the chosen band induce a required physical-layer coding that may
change over time (Q/V bands, Ka band, etc.).  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 block), the relevance of adding coding techniques is
different.
This use-case considers the usage of coding techniques to cope with
cases where channel condition can change in less than a second and
where the physical-layer codes could not efficiently guarantee a
Quasi-Error-Free (QEF) transmission.
The architecture is recalled in fig:varying_capa.  In these cases,
the mechanisms that are exploited to adapt the physical-layer codes
(Adaptative Coding and Modulation (ACM)) may adapt the modulation and
coding in time: remaining errors could be recovered with higher layer
redundancy packets.  Coding may be applied on IP packets or on
layer-2 proprietary format packets.
This use-case is mostly relevant when mobile users are considered or
when the chosen band induces a required physical-layer coding that
may change over time (Q/V bands, Ka band, etc.).  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 block), the relevance of adding coding techniques is
different.
the network function block.  The control plane manager is in charge
of taking the decision to change the communication gateway and the
consequent routes.
the network function block.  A potential control plane is in charge
of taking the decision to change the communication gateway and the
consequent routes.
This section proposes to discuss few research challenges related to
the introduction and the use of coding techniques in SATCOM systems.
This section proposes a few potential approaches to introduce and use
coding techniques in SATCOM systems.
Deploying coding schemes at the TCP level in these equipment could be
relevant and independent from the specific characteristics of a
SATCOM link.  This leads to research question on the interaction
between coding schemes and TCP congestion controls.
The recurrent trade-off in SATCOM systems remains: how much overhead
from redundant reliability packets can be introduced to guarantee a
better end-user QoE while optimizing capacity usage ?
Deploying coding schemes at the TCP level in these equipment could be
relevant and independent from the specific characteristics of a
SATCOM link.  This leads to research questions on the interaction
between coding schemes and TCP congestion controls.
The recurrent trade-off in SATCOM systems remains: how much overhead
from redundant reliability packets can be introduced to guarantee a
better end-user QoE while optimizing capacity usage ? At which layer
this supplementary coding could be added ?
Related to the foreseen virtualized network infrastructure, coding
techniques could be easily deployed as VNF.  Next generation of
SATCOM ground segments could rely on a virtualized environment.  This
trend can also be seen in cellular networks, making these discussions
extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g-
core-structure-yang.  As one example, the coding VNF functions
deployment in a virtualized environment is presented in I-D.vazquez-
nfvrg-netcod-function-virtualization.
A research challenge would be the optimization of the NFV service
function chaining, considering a virtualized infrastructure and other
SATCOM specific functions, to guarantee an efficient radio usage and
easy-to-deploy SATCOM services.  Moreover, another challenge related
to a virtualized SATCOM terminals is the management of limited
buffered equipments.
In the context of the deep-space communications, establishing
communications from terrestrial gateways to satellite platforms can
be a challenge.  Reliable end-to-end (E2E) communications over such
links must cope with long delay and frequent link disruptions.
Delay/Disruption Tolerant Networking 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 the data
between a central PEP and a remote PEP.
Related to the foreseen virtualized network infrastructure, coding
techniques could be easily deployed as VNF.  Next generation of
SATCOM ground segments could rely on a virtualized environment.  This
trend can also be seen in cellular networks, making these discussions
extendable to other deployment scenarios I-D.chin-nfvrg-cloud-5g-
core-structure-yang.  As one example, the coding VNF deployment in a
virtualized environment is presented in I-D.vazquez-nfvrg-netcod-
function-virtualization.
A research challenge would be the optimization of the NFV service
function chaining, considering a virtualized infrastructure and other
SATCOM specific functions, to guarantee efficient radio usage and
easy-to-deploy SATCOM services.  Moreover, another challenge related
to a virtualized SATCOM equipment is the management of limited
buffered capacities.
Communications among deep-space platforms and terrestrial gateways
can be a challenge.  Reliable end-to-end (E2E) communications over
such paths must cope with long delay and frequent link disruptions;
indeed, contemporaneous E2E connectivity may be available only
intermittently or never.  Delay/Disruption Tolerant Networking
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 the data between a central PEP and a
remote PEP.
Even though this document focuses on satellite systems, it is worth
pointing out that some scenarios proposed may be relevant to other
wireless telecommunication systems.  As one example, the generic
architecture proposed in fig:sat_gateway may be mapped to cellular
networks as follows: the 'network function' block gather 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 be also relevant for cellular networks.
Even though this document focuses on satellite systems, it is worth
pointing out that some scenarios proposed may be relevant to other
wireless telecommunication systems.  As one example, the generic
architecture proposed in fig:sat_gateway may be mapped to 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 be also relevant for cellular networks.