Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Christian Huitema <[e-mail]>]

On 10/21/2019 7:31 AM, Tom Herbert wrote:
> Igor,
>
> That misses the point of the statement. There are many protocols that
> don't have ubiquitous support over the Internet-- EH, IP
> fragmentation, any transport protocol other than TCP and sometimes
> UDP, and even IPv6. If "ubiquitous support" is required for deployment
> then we can never deploy new protocols or any protocol that is
> atypical to intermediate devices. So, unless we're planning on never
> doing anything new on the Internet, we need to address this.
>
>
>     The goal of any "for the network" signal is improved QoS.  Hence,
>     if there is a non-trivial chance that inclusion of such signal
>     will actually degrade QoS (by causing packets with the signal to
>     be dropped), no sender will include such signals (and "happy
>     eyeballs" style code is too complex and risky for the benefit).
>
>     As architecturally "ugly" as it sounds, I can only see the QUIC
>     header and the most significant TTL bits as viable alternatives to
>     be deployable widely on the Internet for IPv4.  For IPv6, even HBH
>     and Dest Options are still too "risky" for packets, but that is
>     likely to be improving.
>
>
> You forgot to mention efforts to encode information in IP addresses,
> overload bits in the flow label, or other DPI parsing of UDP payload
> (like tunnels over UDP), and other creative ways to "find" bits that
> can be repuposed. There're all hacks! IP is designed to be an
> extensible protocol without the need for these. Pursuing such hacks,
> instead of using the defined mechanisms of extensibility, ostensibly
> solves some short term problems, but in the long run perpetuates
> protocol ossification and stifles evolution of the Internet.


If we want to not rely on hacks, I believe that we have to somehow
change the network protocol. I have followed the development of the spin
bit in QUIC, and the attempts to use more bits and provide for example
indications of packet losses. There are typically two issues: privacy
and practicality. Let's not discuss privacy here, except by assuming
that privacy-sensitive deployments will find a need to "bleach" the
signals. The signals are still useful for connection management as long
as a large enough fraction of the connections are not bleached.

I think that solving the "practicality" issue requires moving the signal
to the IP layer. The experiments by Orange show that you only need a
small number of bits to monitor latency and loss rate from within the
network - 2 or maybe 3 bits would do. If these bits are in the transport
header, the network monitor has first to find out what transport
protocol is in use, and possibly what version. With encrypted
transports, that could soon become a daunting task. On the other hand,
if the bits are at some fixed position in the IP header, monitoring
becomes much simpler.

My personal preference would be to associate these bits with an IPv6
"flow" label, or for IPv4 the five-tuple. Latency is associated with
routing and with applications, and in theory all packets in a flow share
the same routing and the same kind of end-to-end processing. Of course,
there are deployment issues, bleaching issues, etc. But the logic
remains: associating latency and loss measurement with a packet flow
makes the most sense. Moving that to the IP header also makes sense --
after all, it is very similar to ECN signals. The broad line of the
solution would thus be:

1) Steal a couple of end to end bits, or maybe just 4 to 8 Diffserv code
points

2) Use these bits to encode the "spin" and "loss" indications, and
distinguish them from the "bleached" signal

3) Compute the "spin" and "loss" indications per end-to-end flow, and
make that part of the spec.

There are obvious deployment issue, bleaching paths and all that. But at
the same time, the information is meant to benefit network management,
so there will be a strong incentive for network managers to ensure that
it flows freely. Thus, it is not hopeless.

-- Christian Huitema