Subject: [nwcrg] Spencer Dawkins' Yes on draft-irtf-nwcrg-network-coding-satellites-13: (with COMMENT)

From: Spencer Dawkins via Datatracker <[email-masked]>
Date: Fri, 22 May 2020 07:55:40 -0700

Spencer Dawkins has entered the following ballot position for
draft-irtf-nwcrg-network-coding-satellites-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

----------------------------------------------------------------------
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?

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 23 May 2020 01:52:39 +0000 (UTC)

Spencer,

ack spoofing has gone away in PEPs -- when the Savage attacks were addressed in TCP stacks. See Stefan Savage's papers, the relevant section of RFC5681, etc.

TCP connection splicing assumes an unencrypted TCP flow. That's going away, very rapidly. Compression and caching (typically for http) also assume unencrypted flows, and they're going away very quickly. Typical PEPs for satellite acceleration are stripping out this code as not worth maintaining. Yes, PEP proxying for a security endpoint and going full man-in-middle to recreate TLS etc. so that they could do compression and caching is technically possible, but the benefits generally aren't worth the security concerns and code complexity. (Though Riverbed will try to do it, bless their hearts.)

So, those technical terms of art are imo not worth being referred to at this point.

TCP congestion window sizing to ameliorate slow start remains, and is the go-to strength of PEPs for TCP that can be called out as a typical technical feature. It's slightly clearer than the generic 'TCP acceleration' imo, and is a substitution I'd recommend.

L.

we really need to accelerate the speed of light.

Lloyd Wood [email-masked] http://about.me/lloydwood

On Saturday, 23 May 2020, 12:56:25 am AEST, Spencer Dawkins via Datatracker <[email-masked]> wrote: 

In this text,

                                                                ^^^

      acceleration;

      ^^^^^^^^^^^^

3GPP term?

---

From: "Stuart W. Card" <[email-masked]>
Date: Sat, 23 May 2020 15:23:55 -0400

This is merely a comment on a comment, not a ballot, thus the reduced
email distribution.

Encryption, especially E2E, precludes direct application of many
traditional transparent transport PEP techniques. However, some old
tricks are still viable, although some of them need to be done in
trickier ways, in some cases facilitated by network coding.

What kills TCP performance more than anything else are packet losses and
RTT variance. These can be reduced, even with encrypted flows, at the
cost of increasing average RTT (which also has negative TCP performance
impacts, but less severe for latency insensitive applications). A PEP
can network encode an encrypted IP flow, buffer it on the receive side,
deliver reconstructed packets only after a fixed (long) timer expires
(even if it could have done so much sooner in many instances). It can
even set the timer long enough to do one "link" retransmission if needed
over the sending PEP to receiving PEP path segment. TCP will be annoyed
at first, but once it converges on the long average RTT and small RTT
variance, it will be happy, and resend only when it really needs to. The
problem with this trick, of course, is that latency sensitive (probably
UDP) microflows may be mixed with the TCP microflows in the opaque
encrypted macroflow; but that may be avoidable depending on where/how
the encryption is done (e.g. policy based routing of traffic with
different QoS requirements through different encrypted tunnels).

Sadly, I've never had funding to implement this trick properly, so I
can't report any results.

On 5/22/2020 9:52 PM, [email-masked] wrote:
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg
> 

-- 
Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email-masked]> www.critical.com

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 23 May 2020 22:14:15 +0000 (UTC)

Stuart,

FWIW, the 'if path delay is held constant, even if it's slightly
longer, performance will increase' theory was tested over a decade
ago in deployment with Cisco's Rate-Based Satellite Control
Protocol (RBSCP) tunneling. The tunnel was the 'link' that could
do retransmissions; a delay-expiry buffer-send timer could be
configured, along with the usual ack splitting and window stuffing
techniques. Access lists to send only TCP in the clear through the
tunnel and delay that, and skip UDP, were easy enough.

https://web.archive.org/web/20110706144353/http://cisco.biz/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_rbscp.html

https://patents.google.com/patent/US7388836B2 

Results from the field for added delay were not that favourable.
The ack splitting and window stuffing were more immediately useful,
so ack splitting was later separated from the tunnel mode, as it
had far less overhead than the buffering needed for windowing. Now
that TCP widely does appropriate byte counting (ABC), splitting won't
be that useful.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/12-4t/sec-data-acl-12-4t-book/sec-accs-list-rdscp.html

(This added delay is slightly different from the reorder wait delay
on e.g. Silver Peaks to ensure an ordered TCP flow - which also matters
less with TCP SACK selective acknowledgements.)

No network coding here, but I don't think it would help. I doubt that
network coding across a path including a satellite link can beat the
coding and modulation that can be dynamically applied to the satellite
link. A satellite PEP really needs good integration with and knowledge
of the satellite link, and network coding can't easily provide that.

L.

On Sunday, 24 May 2020, 05:24:48 GMT+10, Stuart W. Card <[email-masked]> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 May 2020 00:37:21 +0200

> On 2020-05-24, at 00:14, [email-masked] <lloyd.wood=[email-masked]> wrote:
> 
> I doubt that
> link.

Very likely so.  But the keyword is “can be applied”.  Is it?
When is the clunky sat terminal written off and up for renewal?

This is the (not so unlikely) situation where LOOPS-style in-network recovery can be useful even for satellite losses.

Grüße, Carsten

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 25 May 2020 00:04:44 +0000 (UTC)

Carsten,

it strikes me that justifying work on LOOPS to benefit old
satellite terminals that lack adaptive coding and modulation
is akin to justifying work on PEPs because there are still
some Windows XP boxes out there with ancient TCP stacks
that will benefit most from TCP acceleration.

In both cases, the network is doing work to benefit the
endpoints -- yet the design of the Internet is that innovation
is supposed to happen most rapidly at the endpoints.

Focusing the IETF/IRTF on work to benefit legacy endpoints
does not seem that productive to me.

best

L.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 May 2020 02:41:01 +0200

Hi Lloyd,

> that will benefit most from TCP acceleration.

Except that the sat terminals are in the network.

> is supposed to happen most rapidly at the endpoints.

In the one use case I was talking about, the endpoints can innovate as much as they want; they are being held back by network components that are expensive and don’t get updated on Internet timelines.

More generally speaking, in-network techniques such as LOOPS tend to be most useful on networks parts of which are run by different stakeholders whose preparedness/motivation/capability to invest in upgrades differs.  If everything is homogenous, it is less clear where the benefit of LOOPS lies.

> does not seem that productive to me.

Everything is legacy as soon as we have finished typing the spec.
(Improving the endpoints also is a good idea, no disagreement there, but I thought we were already doing that.)

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 May 2020 10:21:03 -0500

Hi, Lloyd,

On Fri, May 22, 2020 at 8:52 PM [email-masked] <
[email-masked]> wrote:

> Spencer,
>
>
> ack spoofing has gone away in PEPs -- when the Savage attacks were
> addressed in TCP stacks. See Stefan Savage's papers, the relevant section
> of RFC5681, etc.
>
>
> TCP connection splicing assumes an unencrypted TCP flow. That's going
> away, very rapidly. Compression and caching (typically for http) also
> assume unencrypted flows, and they're going away very quickly. Typical PEPs
> for satellite acceleration are stripping out this code as not worth
> maintaining. Yes, PEP proxying for a security endpoint and going full
> man-in-middle to recreate TLS etc. so that they could do compression and
> caching is technically possible, but the benefits generally aren't worth
> the security concerns and code complexity. (Though Riverbed will try to do
> it, bless their hearts.)
>
>
> TCP congestion window sizing to ameliorate slow start remains, and is the
> go-to strength of PEPs for TCP that can be called out as a typical
> technical feature. It's slightly clearer than the generic 'TCP
> acceleration' imo, and is a substitution I'd recommend.
>

Thanks for the suggestion. It's very much in line with what I was shooting
for with my comment, and is actually more helpful :-)

Best,

Spencer, who has been trying to forget everything I've heard about "TCP
acceleration" since I heard Savage talk about TCP Daytona in 1999 ...
https://cseweb.ucsd.edu/~savage/papers/CCR99.pdf

---

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 29 May 2020 09:37:32 +0000

Thank you all for your comments and this discussion. 
We are working on an updated version of the draft. 
In the meantime, I wanted to comment on this.
See inline

Nico
-----Message d'origine-----
De : nwcrg <[email-masked]> De la part de Carsten Bormann
Envoyé : dimanche 24 mai 2020 00:37
À : [email-masked] <lloyd.wood=[email-masked]>
Cc : [email-masked]; Spencer Dawkins <[email-masked]>; Stuart W. Card <[email-masked]>
Objet : Re: [nwcrg] Spencer Dawkins' Yes on draft-irtf-nwcrg-network-coding-satellites-13: (with COMMENT)

> coding and modulation that can be dynamically applied to the satellite 

[NK] There are cases where there are residual errors - such as mentioned in the section 3.5 of the draft. In mobile users cases or when you use optical links, the physical layer coding and modulation schemes may not be adequate and the residual errors are very impacting on GEO use-cases. 

Grüße, Carsten