Subject: The first octet

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Aug 2018 15:55:36 +1000

It appears as though we're about to get some information about how
deployable the QUIC invariants are.  Ian tells me that Google are most
of the way to deploying a protocol that uses QUIC invariants and
should be able to confirm that this works by the interim.  Well,
either that or to be able to tell us what doesn't work, which I'm
hoping isn't a problem we have to deal with.

I'd like to spend some time at the interim on what we do with the type
bits in the protocol.  This email is an attempt to thoroughly cover
the constraints that we have here and attempt to describe a process
that I hope should get us to a conclusion shortly after Bangkok.

Looking at open design issues, this cluster is the one that is the
biggest threat to our schedule.

Design Status and Constraints

Long Header

The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we
have are currently allocated to the 4 types of long header packet,
using only 252-255.  All other values are currently unused.

With respect to design constraints, there is only one that I'm aware
of and that is a potential collision with RTP (and RTCP) on this octet
(see RFC 7983), which use 0x10xxxxxx (128-191).

The open question here is what we do with unused types.  We might
debate creating a registry for unused values.  We might want to grease
values.  We could even decide to encrypt these values (though the
design of Retry makes that more difficult, because the contents of
that packet aren't encrypted at all).

I'm not aware of any plans to use these bits, except perhaps what
might be done to be consistent with the short header changes, so we
might have some latitude here.

Short Header

The short header uses the 0b0xxxxxxx pattern (0-127).  This is far
more complex and we have a bunch of open questions that will make this
difficult.

Right now, we use the 0b0K110RRR as the pattern, with K being the key
phase, and RRR being reserved for the spin bit experiment.

Those fixed bits are (largely) temporary, and might be reclaimed once
existing deployments of Google QUIC (pre-44) are phased out, so I
think that we might want to reclaim some or all of them.

There is a chance that the reserved bits will also become available
(if not all, then maybe 2 of them).  That will be decided in Bangkok,
but we might want to have a plan for those bits.

The constraints that I am then aware of are these:

1. RFC 7983 has the lower half of the first octet fairly densely
populated for demux.  Of the protocols there, my understanding of
their relative importance puts STUN (0-4) as fairly critical, if not
mandatory, then TLS (20-63) as optional.  ZRTP (16-19) and TURN
channels (64-79) are both apparently unimportant, though each might be
opportunistically accommodated.

2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits.  I
suggest that we allow for this, not counting on having any more bits
than N-3, or assuming that only that many bits will be available.

3. Kazuho points out that the key phase is a linkability vector.  We
might want to consider encrypting that.  We could do that by fixing
the packet number key and not updating it after key updates and using
more output from that process to mask the bit (and maybe other bits in
this field).

4. I realize that we don't have to put a key phase in every packet if
we are less concerned about being able to update immediately.  If we
adopt a scheme to what was proposed in DTLS, then a longer encoding
can be used during the preparation and signaling phase.    I'll follow
up with another email on this subject.

One thing that we could use extra bits for is to move the packet
number size back into this octet.  We could even move packet number
bits back, depending on available space.  That might make some
difference to the number of bytes we allocate for packet numbers.

Process

Given that we don't have answers to some questions we might conclude
several ways.  I proposed that we agree on principles, starting with:

0. (This should already be agreed, but I'm repeating it because it's
important.)  The low 7 bits of the first octet are version-specific
and can change in the next version of the protocol.

A. What do we want to do with unused bits?  Do we want to ensure that
they are always used?  Or can they be reserved?  If so, how would they
be reserved (fixed values, random values, greasing, etc...)?

B. Should things in the first octet be encrypted where possible (for
example, using an extension of packet number encoding).

C. Should packet number encodings should be consistent between long
and short header forms?

D. What should we do with key phase?  This was an open issue from the
stream 0 design team, which might alter the outcome here.  I have
another email that covers this in more detail.

E. How should we accommodate multiplexing?  For me, the big questions
here are whether we allow for RTP to collide with the long header and
which of the protocols we privilege by avoiding with the short header.

My hope is that reaching conclusion on those principles should allow
us to to agree on designs that allow for 0, 1, or 3 bits of spin bit.
That way we know what to do with the outcome of the discussions we
plan to have in Bangkok and can implement the changes relatively
quickly.

For those who read this far, if you have opinions on what principles
should drive this design, please respond here.  If you have a proposed
design (or designs) and can explain the principles that are expressed,
that's OK too.  If this gets enough feedback, I might arrange a call
for interested parties.

I don't expect that we'll reach a conclusion before the interim, but I
don't think that we can let this go unresolved much beyond that point.

---

From: Dirkjan Ochtman <[email-masked]>
Date: Mon, 6 Aug 2018 10:10:37 +0200

> that's OK too.  If this gets enough feedback, I might arrange a call

I haven't dug deeply into this, but I have been wondering about enabling
alternatives to TLS for integrity and confidentiality. Notably, I think the
Noise protocol variants are looking very interesting into this space.
Assuming that the current stream 0 design makes it possible to somewhat
generically swap out TLS for something and that Noise provides the right
primitives to fit that conceptual API, it seems reserving some bits in the
long header packets might help enable this?

Regards,

Dirkjan

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Aug 2018 19:37:43 +1000

> long header packets might help enable this?

QUIC v1 will use TLS. All the questions I am asking relate specifically to
that version. I made it clear in my original email that these are
version-specific bits.

A protocol that uses a different cryptographic handle has to use a
different version number.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Aug 2018 10:05:50 -0700

> might have some latitude here.

We are actually greasing these bits with the version negotiation packets
-- the 7 unused bits of the VN packets are supposedly set to random
values. Of course, VN are special purpose packets and should not be used
all that often in production, but it is something...

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Aug 2018 10:24:58 -0700

> and can change in the next version of the protocol.
Yes.
> be reserved (fixed values, random values, greasing, etc...)?

My fast-brain response would be to use random values, 0b1RRRRRxx, and do
T=octet|0b01111100 when decoding the long header. But that's probably
wrong, because of side channels, etc. The next alternative is to define
several QUIC versions, with different codes for the four long header
types. That would grease both the types and the version field, and would
probably be a better way to teach middle-boxes not to make assumptions.

> example, using an extension of packet number encoding).

That's tempting, but the decryption key is function of the packet type:
epoch 0 for initial, epoch 1 for 0rtt, epoch 2 for handshake, clear text
for retry. Encrypting the packet type means trial decryption. Do we
really want to do that?

> C. Should packet number encodings should be consistent between long

Took me some time to parse what you wanted to say. I think you mean
something like, "if we move the number length bits to first octet of the
short header, should we also reserve the same two bits to encode the
number length bits in the first octet of the long header?" Maybe. Or
just say that packet numbers in the long header are always encoded on 32
bits, which might be even simpler.

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 6 Aug 2018 12:36:09 -0700

Hi Martin,

Thanks for raising these questions. I agree that we should at least agree
as a group on the principles for resolving these questions, so I'll respond
on the ones you've suggested.

> and can change in the next version of the protocol.

Agreed.

> be reserved (fixed values, random values, greasing, etc...)?

I would strongly encourage us to always use unused bits. I think what we so
far is quite good, and for the rest of the unused bits, I'm starting to
like Christian's idea of using different versions.

> example, using an extension of packet number encoding).

Yes, but we need to do something where the first octet is not greased
(Initial, for instance). And what we do there could also be done where
encrypting is inconvenient.

> and short header forms?

I don't think I have a strong opinion on this yet, but I am leaning towards
consistency. Let's not add another type of parsing if we don't need it.

> another email that covers this in more detail.

(I assume we'll discuss this in the other email thread then.)

> which of the protocols we privilege by avoiding with the short header.

So some thoughts, and I'll admit to still not fully being able to reason
about this clearly. It seems to me that the connection ID in short header
packets ought to be adequate for demux. For long header packets, again,
after the Initial and 0RTT packets, the DCID ought to be enough. If that's
true, then we want to avoid conflicting Initial and 0RTT types with RFC
7983 types, which at least reduces the problem. We can figure out where to
go from here, but does this agree with your understanding of the world, or
am I off in the weeds?

- jana

---

From: Mike Bishop <[email-masked]>
Date: Mon, 6 Aug 2018 19:57:05 +0000

…but the definition of that version could Very Closely Resemble QUIC v1 (or whatever version we wind up calling this) with a different protocol carried in CRYPTO frames / providing keys.

From: QUIC <[email-masked]> On Behalf Of Martin Thomson
Sent: Monday, August 6, 2018 2:38 AM
To: Dirkjan Ochtman <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: The first octet

On Mon, 6 Aug. 2018, 18:10 Dirkjan Ochtman, <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Aug 6, 2018 at 7:56 AM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
For those who read this far, if you have opinions on what principles
should drive this design, please respond here.  If you have a proposed
design (or designs) and can explain the principles that are expressed,
that's OK too.  If this gets enough feedback, I might arrange a call
for interested parties.

I haven't dug deeply into this, but I have been wondering about enabling alternatives to TLS for integrity and confidentiality. Notably, I think the Noise protocol variants are looking very interesting into this space. Assuming that the current stream 0 design makes it possible to somewhat generically swap out TLS for something and that Noise provides the right primitives to fit that conceptual API, it seems reserving some bits in the long header packets might help enable this?

QUIC v1 will use TLS. All the questions I am asking relate specifically to that version. I made it clear in my original email that these are version-specific bits.

A protocol that uses a different cryptographic handle has to use a different version number.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 6 Aug 2018 13:17:53 -0700

You could also overlay with a mask based on PN encryption. If the mask
doesn’t match the PN that packet is invalid and can be discarded early -
useful for DoS rejection.

I know there are arguments about timing attacks etc. but I think really
fast packet rejection can be valuable defense.

I don’t like the masking idea so much if it works against removing PNE from
AEAD so decoding can happen without buffer mutation, however, if that fails
to land, the space might be as well be used constructively.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 7 Aug 2018 14:39:48 +0900

> be reserved (fixed values, random values, greasing, etc...)?

As Jana has suggested, I think that the bits must look like random to
observers, based on our agreement that the bits are version-dependent.

Unless we make them look like random, there is fair chance that they
will be ossified.

> example, using an extension of packet number encoding).

I would rather rephrase the question to "do we need to encrypt foo?" I
think that we should decide what will go into the first octet based on
the agreement of what needs to be encrypted.

Having that said, I think that we need to encrypt packet number,
packet number length, and the key-phase bit. The packet type bits and
the spin bit(s) need to be in cleartext. Unused bits can be
seemingly-randomized as an output of encryption, or could be a random
value.

My preference regarding the design will be to have the packet number
length bits and the key-phase bit in the first-octet next to each
other, encrypting the two using the PNE key.

Having packet number length at a different location than the packet
number itself will simplify the implementation, gives us more chance
to use shorter encodings for packet numbers.

For example, the long and short packet header will look like below (e
- encrypted values of PN length and key-phase, t - long header type
bits, s - spin bit, R - reserved bit).

long: 1 e e e R R t t
short: 0 e e e R s s s

I do not have a preferred way of randomizing the R bits. They could be
randomized by PNE along with the e bits, or we could require them to
be randomized separately.

Yes.

I do not think that we need to be clever in saving one bit or two. We
already waste certain number of bits. The fact that we are using
varint encoding that changes the length at octet-level (i.e., 8 bits,
16 bits, 32 bits, ...) means that we are wasting something like 4 bits
by average per varint. We are also wasting 2 bits per frame,
considering the fact that the upper 2 bits of a frame is not used.

> another email that covers this in more detail.

I think we should the bit in every packet as an encrypted value. The
reason why having I consider that the bit in every packet is stated
above.

> which of the protocols we privilege by avoiding with the short header.

I would prefer not caring about multiplexing.

We do not guarantee multiplexing between QUICvX and other protocols.
Considering that, I am inclined to not discussing about
multiplexability of  QUICv2 (formerly v1), because that would raise
the chance of QUIC becoming ossified.

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Aug 2018 17:17:02 +1000

Thanks for sharing your perspective Kazuho, I have a slightly
different view, but it's fairly consistent with yours.  Reformulating
the second question is good, and I too would like to encrypt this
stuff.  It should be easy enough to do so.

I too like the common form for packet number lengths.  I can even see
adding key phase to long header packets for the purposes of
consistency.

This is my preferred layout for the case we have three bits for spin.

1 t t t t p p p
0 1 s s s p p p

Where p p p is an encrypted key phase bit and two-bit packet number
length (1,2,3,4).  I think that we can afford to have fix tttt values
with no greasing.  Allocating four bits and using two of them isn't so
bad.  By doing that we can choose types that don't conflict with RTP.
It's not necessary, but it's very cheap.  The fixed bit keeps the
short header away from most of the RFC 7983 protocols without costing
much (you had a reserved bit anyway).

The extra fixed bit here makes QUIC short header packets conflict only
with TURN channels from 7983.  That's totally acceptable and fairly
cheap from our perspective.  If you are concerned about ossification
of this bit, we could give it to the spin bit(s) and force the people
who want this sort of demux to negotiate the spin bit into a fixed
value if they care to have good demux.

If we have two fewer bits of spin, that's where things get
interesting.  I would prefer to keep the same ppp bits, but leave the
two spare bits unallocated, but encrypted along with ppp.  Encrypting
means they can be forced to be zero unless agreed otherwise (MBZ
normally means MUST send zero, MUST ignore non-zero, but I prefer MUST
reject non-zero here):

1 t t z z p p p
0 1 s z z p p p

The hit here is RTP.  We would need all type values so we end up using
0b10xxxxxx.  We can limit the damage by changing codepoints for 0-RTT
and Retry packets, which can be avoided in most scenarios that use RTP
(signaling FTW).

If we have no spin bits, then we might as well change the single s bit
to a fixed 1.  Then we avoid TURN channels as well.

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 8 Aug 2018 16:41:44 +0900

2018-08-08 16:17 GMT+09:00 Martin Thomson <[email-masked]>:
> different view, but it's fairly consistent with yours.

Martin, thank you for sharing your view and how you think we might
encode the bits.

I agree that our views are mostly consistent.

IMO, the only disagreement is if we should try to avoid conflict with
other protocols.

My understanding is that we do not avoid conflict in the invariants,
but you suggest to avoid them in v2.

Would you mind elaborating why you think we should make such a decision?

For example, is it the case that you think avoiding conflict in the
short term is worthwhile, at the same time keeping the possibility to
change the decision in the future versions of QUIC?

Honestly, I do not have a strong opinion here, although I worry about
ossification when we decide not to grease the bits. Therefore, I would
like to understand why you think avoiding conflict in v2 but not in
invariant is worth considering.

Thank you in advance.

> Reformulating

-- 
Kazuho Oku

---

From: <[email-masked]>
Date: Wed, 8 Aug 2018 09:50:32 +0200

Hello Martin,

Since you're discussing spin bit allocation variants, maybe it's worth taking a 
step back: how strong is the "bit pressure" really ? Are we really fighting over 
the last single bits in an otherwise optimally packed protocol ? Or could the 
~70 bytes of a typical ACK-only packet afford an extra byte without endangering 
polar bears ?

The reason I'm asking is I'm wondering about the set of arguments that will be 
used to decide the final number of "s" bits:

  - space: it's a sheer coincidence that, at some point, the first byte happened 
to have three seemingly spare bits, and that the "spin bit + VEC" approach also 
needs three. Your message seems to indicate that might no longer be the case, 
since you've got a use case for the spare.

  - ossification and linkability vs need for measurement: this is the real name 
of the game, will be discussed in due time.

I'm concerned that the second set might somehow be masked by the first one.
How about the following alternative: (1) decide how many bits to allocate to 
measurement, fully focusing on the trade-off between manageability and key QUIC 
goals above; (2) decide where to fit them, including in a possible extra, hum, byte.

What do you think ?

> to a fixed 1.  Then we avoid TURN channels as well.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Aug 2018 10:38:58 +0100

> On 6 Aug 2018, at 06:55, Martin Thomson <[email-masked]> wrote:
> 
> be reserved (fixed values, random values, greasing, etc…)?

I suggest either random or greased somehow, but with a note that implementations that know they’ll be multiplexing another protocol on the same port will need to take care to avoid collisions with that other protocol when doing so.

> …

I think we have two demultiplexing concerns: in the longer-term how to do NAT binding discovery for peer-to-peer QUIC, and in the short term how to demux with RTP, DTLS, etc.

As a long term issue, if we want to support peer-to-peer use of QUIC, then we’ll need a NAT binding discovery protocol. STUN provides such a mechanism that we could re-use, or we could choose to re-invent a similar mechanism inside QUIC. I’d prefer not to reinvent the wheel here, but that’s a decision the group will need to make.

If we use STUN, we must ensure it can be de-multiplexed from QUIC. STUN packets have their first two bits set to 0b00 and bits 32-63 set to the magic number 0x2112A442. It’s trivial to demultiplex STUN from QUIC long header and version negotiation packets, since those packets have their first bit set to 1. 

To demultiplex STUN and QUIC short header packets, we could change the invariant for QUIC short header packets to start 0b01. This is the smallest change needed to guarantee trivial demuxing with STUN, and doesn’t significantly constrain future evolution of QUIC. Alternatively, we could specify something based on the STUN magic number and QUIC DCID, but that seems unnecessarily complex to me.

As a short term issue, we also need to consider demuxing with RTP, DTLS, and so on (I expect that media will run over QUIC in time, so demuxing with these protocols will gradually become less important). 

RTP packets have their first two bits set to 0b10, so are simple to demux with both QUIC short header packets and with the currently defined QUIC long header packet types. I think this is sufficient, and we can revisit in future versions of QUIC if we decide to change the QUIC long header packet types.

A DTLS handshake is used to key secure RTP flows, so we also need to demultiplex DTLS. The RFC 7983 heuristic for this demuxing is that packets with first octet in the range 20-63 are DTLS. That doesn’t conflict with QUIC long header packets, or short header packets as defined in the -13 QUIC drafts, but we’ll need to be careful to avoid collisions if we rearrange the bits in the short header (the above suggestion to make short header packets start 0b01 avoids conflicts).

RFC 7983 also defines demuxing with TURN and ZRTP. My opinion is that this is not important, but I accept that others may disagree.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Aug 2018 19:51:11 +1000

> but you suggest to avoid them in v2.

v1.

Yes, that was the idea.  The protocols we're talking about could have
the luxury of being able to negotiate versions carefully, and avoid
any version that doesn't suit.

> change the decision in the future versions of QUIC?

That is certainly true.  See Colin's response too.  He managed to
summarize the thinking here fairly well.

> invariant is worth considering.

Yes, the risk exists.  We could, for example decide to try to mitigate
this risk by choosing something maximally bad for 7983 demux and force
folks who want to do that to define a new version, thereby generating
two variants in relatively quick succession and pinning our hopes on
that helping.  I tend to think that things ossify on longer timescales
than that and so am willing to risk those bits sticking for this gain.
For the short header, it would be exactly one bit.

Invariants is part of our protection here.  It might turn out to be
futile, I don't know.  But I would be very happy to define a new
variant that set that bit to zero.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Aug 2018 20:05:28 +1000

> goals above; (2) decide where to fit them, including in a possible extra, hum, byte.

We agreed to reserve 3 bits.  If we decide not to use those bits, we
need to do something with them (octets don't get smaller after all,
and an octet used is better safeguarded than one that is not).  The
intent of this discussion is to prepare for the outcome of the
discussion in Bangkok.

I know you discussed taking more bits and even bytes, but the case
hasn't been made in this working group to my knowledge.  I certainly
don't think that's justified; it improved fidelity of measurements,
but the spin bit appears to be pretty good at that without the extra
overheads.  And overheads do matter (on that point, your claim of 70
seems overly large, if it's based on ACK encoding in gQUIC, the
differences are now significant enough that it might not be
representative - my estimation is that you might get as low as 28
octets, plus connection ID size for a typical, unpadded ACK, certainly
not more than double that).

---

From: <[email-masked]>
Date: Wed, 8 Aug 2018 15:22:31 +0200

On 08/08/18 12:05, Martin Thomson wrote:
> overheads.

Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin bit + VEC) 
for RTT measurements, right.

However, measurements also include packet loss, which is typically more 
widespread than delay in big pipes (which don't have enough RAM to keep a packet 
for too long at line rate). And spin+VEC do not address packet loss at all, 
hence our 7-bit spin counter proposal shown in London.

I admit that 7 is hefty if you're starting from Christian's songle spin bit ; 
however:

  - I assume nobody will emit any doubt about the criticality of 
non-delay-related (big pipe) loss location. Unless everybody here has perfect 
networks and ideal reporting, that is.

  - Stick the spin bit on top of these 7, make that an extra easurement byte and 
you've got your three spare bits again in the first byte.

---

From: Ian Swett <[email-masked]>
Date: Wed, 8 Aug 2018 09:29:38 -0400

I'm having a hard time understanding why you'd need 7 bits to measure
packet loss(1 seems sufficient in most cases), can you send a link to the
spin + VEC and 7 bit proposals you mentioned?

I'll also note I think the chances the WG will agree to 7 bits is extremely
close to 0, but I'm curious why you'd even want them.

On Wed, Aug 8, 2018 at 9:22 AM <[email-masked]> wrote:

> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 8 Aug 2018 13:42:00 +0000

+1

If  in the future there will be consensus that an extra byte is needed it is not related to the first octet as an invariant.  It does not conflict with the invariant draft since it will be version dependent, it only means that it will have to be after the invariants parts of the short header.

Roni

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Wednesday, August 08, 2018 4:30 PM
To: [email-masked]
Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: The first octet

I'm having a hard time understanding why you'd need 7 bits to measure packet loss(1 seems sufficient in most cases), can you send a link to the spin + VEC and 7 bit proposals you mentioned?

I'll also note I think the chances the WG will agree to 7 bits is extremely close to 0, but I'm curious why you'd even want them.

On Wed, Aug 8, 2018 at 9:22 AM <[email-masked]<mailto:[email-masked]>> wrote:

---

From: <[email-masked]>
Date: Wed, 8 Aug 2018 15:44:21 +0200

Sure:

  - spin+VEC are documented in draft-trammel-spin-03

  - 7 bits for packet loss were presented at
      http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf

Re "I'm curious why you'd even want them": please clarify which applies:

  (a) you recognize the criticality of loss location, but you have a cleverer 
algorithm to do the same with fewer than 7 bits

  (b) you don't believe network operators need to locate losses

On 08/08/18 15:29, Ian Swett wrote:
> I'm having a hard time understanding why you'd need 7 bits to measure packet 
> loss(1 seems sufficient in most cases), can you send a link to the spin + VEC 
> and 7 bit proposals you mentioned?
> 
> On Wed, Aug 8, 2018 at 9:22 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>     ce message par erreur, veuillez le signaler

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 8 Aug 2018 13:54:43 +0000

Hi,
In London the spin bit and VEC were not discussed in the session, my take from the offline discussions we had was that currently we experimented with good results only the spin bit. It also seemed that the current VEC as proposed in Brians's draft is not good enough and we intend to look at other algorithms that will provide better results for packet loss using the 2 bits.
I think that this discussion is pre mature and that it should be discussed in the future
Roni 

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 08, 2018 4:44 PM
To: Ian Swett
Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: The first octet

Sure:

  (a) you recognize the criticality of loss location, but you have a cleverer algorithm to do the same with fewer than 7 bits

On 08/08/18 15:29, Ian Swett wrote:
> packet
> loss(1 seems sufficient in most cases), can you send a link to the 
> I'll also note I think the chances the WG will agree to 7 bits is 
> extremely close to 0, but I'm curious why you'd even want them.
> 
> ______________________________________________________________________
> ___________________________________________________
> 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ian Swett <[email-masked]>
Date: Wed, 8 Aug 2018 09:56:52 -0400

Thanks Roni, agreed, let's focus on the issues Martin raised.

On Wed, Aug 8, 2018 at 9:55 AM Roni Even (A) <[email-masked]> wrote:

> Hi,
> In London the spin bit and VEC were not discussed in the session, my take
> from the offline discussions we had was that currently we experimented with
> good results only the spin bit. It also seemed that the current VEC as
> proposed in Brians's draft is not good enough and we intend to look at
> other algorithms that will provide better results for packet loss using the
> 2 bits.
>   (a) you recognize the criticality of loss location, but you have a
> cleverer algorithm to do the same with fewer than 7 bits
>
> >     widespread than delay in big pipes (which don't have enough RAM to
> keep a
> >     packet
> >        - Stick the spin bit on top of these 7, make that an extra
> easurement
> >     byte and
> >     Orange decline toute responsabilite si ce message a ete altere,
> deforme ou
> >     falsifie. Merci.
> >
> >     If you have received this email in error, please notify the sender
> and
> >     delete this message and its attachments.
> >     As emails may be altered, Orange is not liable for messages that
> have been
> >     modified, changed or falsified.
> >     Thank you.
> >
>
>
>
>
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 8 Aug 2018 14:17:09 +0000

Hi,
I meant Montreal not London

From: Ian Swett [mailto:[email-masked]]
Sent: Wednesday, August 08, 2018 4:57 PM
To: Roni Even (A)
Cc: [email-masked]; IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: The first octet

On Wed, Aug 8, 2018 at 9:55 AM Roni Even (A) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
In London the spin bit and VEC were not discussed in the session, my take from the offline discussions we had was that currently we experimented with good results only the spin bit. It also seemed that the current VEC as proposed in Brians's draft is not good enough and we intend to look at other algorithms that will provide better results for packet loss using the 2 bits.
I think that this discussion is pre mature and that it should be discussed in the future
Roni

-----Original Message-----
From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, August 08, 2018 4:44 PM
To: Ian Swett
Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: The first octet

Sure:

On 08/08/18 15:29, Ian Swett wrote:
> On Wed, Aug 8, 2018 at 9:22 AM <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 8 Aug 2018 23:25:09 +0900

Hi Martin,

Thank you for the clarifications.

I now better understand the intent of your proposal. I think I'm fine
with providing a way to demux the protocols without making that an
invariant.

I tend to agree with Colin that it is a good idea to have some form of
randomization / greasing for endpoints that do not need to demux. We
could potentially send a signal that instructs the peer to grease the
demux bits by using TP. Or, a server could send a signal that tells
the client it is free to grease the bits when it resumes a connection.

But that is a slight preference. What is at stake here is just few
bits. They do not expose the state of the connection, so the risk of
ossification is simply that we might not be able to use the bits in
the future. Considering how few the number of bits on the table are, I
do not care much.

-- 
Kazuho Oku

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 8 Aug 2018 18:00:25 +0200

+1 to this is a separate thread we should pick up later.
Note we (at ETH) are actively working on a few techniques for loss/congestion measurement/exposure in QUIC. I've just seen an MSc presentation on one part of this work, and another MSc thesis project will begin in October. We aim to pull all this together into a coherent proposal for v2, which might also propose (distinguishable on the wire) alternate uses for the spin and/or VEC bits in v2.

In any case I see the measurement experiment bits in v1 as a form of greasing *in themselves*; techniques such as probabilistic non-participation should keep the semantics of the bits themselves from getting stuck.

>   - spin+VEC are documented in draft-trammel-spin-03

The canonical reference for this now (sorry, it's confusing) is draft-trammell-tsvwg-spin-00; this now includes the spin bit for TCP as well (which we've implemented for Linux, there's an short paper to follow on this at IMC).

Cheers,

Brian