Subject: Spin bit discussion today

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Mar 2018 09:24:35 +0000

FWIW, I cannot attend today’s meeting due to a conflicting meeting at the same time. But I wanted to express my preference for moving this idea forward as part of the QUIC standard(s). The information it provides is useful. I’ve looked at the specifications and issues and believe the design is quite reasonable and safe.

Jari

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Mar 2018 10:02:25 +0000

> FWIW, I cannot attend today’s meeting due to a conflicting meeting at the same time. But I wanted to express my preference for moving this idea forward as part of the QUIC standard(s). The informat…

And here is some implementation guidance:
https://www.wikihow.com/Do-a-Pirouette

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Mar 2018 10:43:35 +0000

> https://www.wikihow.com/Do-a-Pirouette

More seriously -- a scheduling conflict forced me to leave the room
before the end of the spin bit discussion, so here is what I would have
said on the microphone: I believe that it is important to start reducing
the tension between encryption and network management. I understand that
there are unknowns, essentially the risk that specifying a spin bit will
lead to some form of ossification, with network elements expecting
specific patterns of traffic and misbehaving when the pattern change.
Even with that, I would rather enable experimenting in the real world. I
support reserving 3 bits for SPIN + VET experiments, and making the
implementation experimental.

How we do that in practice may be to just mark the bits as reserved in
the main spec, and have someone write an experimental RFC specifying the
usage. The experimental RFC should have a time limit, at which actual
real world results should be presented. Based on the results of the
experiment, we would either move the SPIN and VET to the main spec, or
make the bits available for another usage.

-- Christian Huitema