Subject: Fwd: New Version Notification for draft-trammell-quic-spin-00.txt

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Nov 2017 00:18:35 +0900

Greetings, all,

We've submitted an initial -00 version of a draft detailing the spin bit, as requested by the chairs under the new process to be applied to changes to the information content of the wire image.

This describes the mechanism and its intended usage, our experiments to date with it, and the privacy analysis undertaken by the RTT DT. We have a few open issues, mainly on the completion of section 4, adding additional use cases beyond basic interdomain troubleshooting.

Cheers,

Brian

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-trammell-quic-spin-00.txt
> Date: 30 November 2017 at 00:13:52 GMT+9
> To: "Emile Stephan" <[email-masked]>, "Giuseppe Fioccola" <[email-masked]>, "Piet De Vaere" <[email-masked]>, "Thomas Fossati" <[email-masked]>, "Piet Vaere" <[email-masked]>, "Al Morton" <[email-masked]>, "Brian Trammell" <[email-masked]>, "Roni Even" <[email-masked]>, "Marcus Ihlar" <[email-masked]>, "Stephan Emile" <[email-masked]>
> 
> 
> A new version of I-D, draft-trammell-quic-spin-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
> 
> Name:		draft-trammell-quic-spin
> Revision:	00
> Title:		The Addition of a Spin Bit to the QUIC Transport Protocol
> Document date:	2017-11-30
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-trammell-quic-spin-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-trammell-quic-spin/
> Htmlized:       https://tools.ietf.org/html/draft-trammell-quic-spin-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-00
> 
> 
> Abstract:
>   This document summarizes work to date on the addition of a "spin
>   bit", intended for explicit measurability of end-to-end RTT on QUIC
>   flows.  It proposes a detailed mechanism for the spin bit, describes
>   how to use it to measure end-to-end latency, discusses corner cases
>   and workarounds therefor in the measurement, describes experimental
>   evaluation of the mechanism done to date, and examines the utility
>   and privacy implications of the spin bit.  As the overhead and risk
>   associated with the spin bit are negligible, and the utility of a
>   passive RTT measurement signal at higher resolution than once per
>   flow is clear, this document advocates for the addition of the spin
>   bit to the protocol.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 29 Nov 2017 10:31:37 -0800

On 11/29/2017 7:18 AM, Brian Trammell (IETF) wrote:

> Greetings, all,
>
> We've submitted an initial -00 version of a draft detailing the spin
> bit, as requested by the chairs under the new process to be applied to
> changes to the information content of the wire image.
>
> This describes the mechanism and its intended usage, our experiments
> to date with it, and the privacy analysis undertaken by the RTT DT. We
> have a few open issues, mainly on the completion of section 4, adding
> additional use cases beyond basic interdomain troubleshooting.

I am reading your draft, and I notice that you propose reserving the 2nd
most significant bit of the UDP payload as the spin bit. This is fine if
you are considering only QUIC, and indeed it matches my original PR. But
I wonder whether there is something more general hiding there. All the
arguments for adding reserved bits to QUIC apply equally well to other
UDP based protocols that encrypt their payload, such as for example DTLS
based transports, or encrypted RTP video. Wouldn't it be nice if the
operators could use the spin bit, or maybe some other management bits,
without first having to identify the specific transport protocol used
inside UDP?

My first reaction was that, if we want generalization, maybe we should
reserve the N most significant bits of the UDP payload, instead of
arbitrary bit positions. It breaks compatibility with previous versions,
but the change in position of the version field already does that in
draft 08, so maybe we should do it right now. Maybe.

But then, I was thinking of our discussions about multiplexing QUIC,
STUN, and maybe also DTLS and RTP on a single port. Twiddling bits in
the first payload byte has a cost. If we want a general solution, maybe
we should move these bits to a generally visible space, i.e. either the
UDP header or the IP header. Of course, there is no space left in the
UDP header, so it would have to be the IP header. The ECN bits are
already there, so the spin bit could fit there too. In IPv6, we could
even use that in conjunction with the flow identifier. What do you think?

-- Christian Huitema

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Nov 2017 05:21:25 +0900

hi Christian, Colin,

We probably should have said (and will say) this in the draft directly, but we wrote section 2 to match the state of the editor's copy pre-956. Where, exactly, the spin bit appears in the short header is

> On 30 Nov 2017, at 03:31, Christian Huitema <[email-masked]> wrote:
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Nov 2017 05:31:45 +0900

> On 30 Nov 2017, at 05:21, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi Christian, Colin,
> 
> We probably should have said this in the draft directly (and will say so in -01), but we wrote section 2 to match the state of the editor's copy pre-956. Where, exactly, the spin bit appears in the short header is ...

... less important than the fact it shows up in the short header only. Given that the short header structure probably hasn't finished changing (e.g., will we varint the packet numbers?), we'll keep the draft up to date, but we don't expect to have a definitive bit position until either (1) we add the spin bit to -transport or (2) we reserve one (or two) measurement bits in -transport.

( Good morning, everyone. The close button and the send button aren't *that* close to each other... :| )

Cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 30 Nov 2017 10:59:31 +0900

hi Christian,

sorry, I didn't respond to your second proposal here...

> even use that in conjunction with the flow identifier. What do you think?

Intriguing, but I'm pessimistic about it working.

The ECN bits in IP are already quite a bit overloaded. First, there's still a some configured hardware out there that treats the whole old ToS byte as the ToS byte, and uses it for ECMP entropy, etc. Which means CE-marked packets go down a different path than non-CE-marked packets, which is... fun. Second, we're already looking at tearing down the equivalence between ECT0 and ECT1 with L4S, to mark different congestion control expectations of a CE mark, and therefore to request alternate treatment from an AQM. See https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 section A.1.

Sticking the spin bit in the flow label has the same ECMP problem as spinning ECT0/ECT1, but worse, since that's an *expected* use of the flow label, not a deprecated one.

Architecturally, I fully agree that something like this belongs in a network-layer header. Indeed, IPPM just published an IPv6 DO based measurement signal, RFC 8250. But doing any of this in the IP header means you need to deploy kernels to make it happen, so the deployment story looks less like QUIC and more like SCTP; 8250, I suspect, will only ever see deployment in specific single network / datacenter scenarios.

Thanks, cheers,

Brian