Subject: Return of the alternate header proposal

From: Jana Iyengar <[email-masked]>
Date: Mon, 6 Mar 2017 17:16:18 -0800

Hi all,

Based on the (very constructive) discussion around the previous alternate
header proposal
<https://www.ietf.org/mail-archive/web/quic/current/msg01012.html>, I've
crafted PR #361 <https://github.com/quicwg/base-drafts/pull/361> that
incorporates mailing-list feedback. This PR does not attempt to be the
final form of the header, but it hopes to be a significant way forward in
that direction.

This PR closes a large number of issues. I'd like to get this merged into
the draft by the draft deadline (a week from now), with the understanding
that this format may still change as we discuss issues further. Please read
and provide feedback.

The PR is a bit invasive and unfortunately large, so I'll summarize a few
salient points about it here.

- The PR includes a header-form bit that allows easy distinction between
long and short headers. It also delineates version-independent fields from
version-specific ones.

- The PR introduces use of Server-selected Connection ID, and specifies
rules for distinguishing it from the client-selected one. In summary,
server-selected Connection IDs are used for the final handshake packet
(ServerHello) and all subsequent packets. Everything before it uses the
client-selected Connection ID, including intermediate server handshake
packets (those carrying HelloRetryRequests).

- Connection ID in a packet is available to a stateless load balancer:
always present in long headers and indicated via a CONNECTION_ID flag in
short headers. In all cases, the connection ID field is in the same
location.

- Public Reset packets are required to include a Proof, but the proof is
TBD.

Thanks,
- jana

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Mar 2017 11:20:53 -0800

Hi Jana,

I sent a bunch of comments in the PR. I think this is in the right
direction, but I also
have some concerns. To summarize my technical comments:

- I don't think the key phase bit mechanism works correctly.
- I'm not thrilled about having the packet # and conn id length depend on a
per-packet
  basis. Why can't we negotiate these?

Plus, I have a bunch of editorial comments.

-Ekr

On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar <[email-masked]> wrote:

> that this format may still change as we discuss issues further. Please
> read and provide feedback.
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 7 Mar 2017 14:25:17 -0500

On Tue, Mar 7, 2017 at 2:20 PM, Eric Rescorla <[email-masked]> wrote:

> - I'm not thrilled about having the packet # and conn id length depend on
> a per-packet

The major negative of negotiating the packet number length is that it makes
it impossible for passive observers to know what the length is.  Which
would make monitoring and features such as packet number echo impractical.

>> Based on the (very constructive) discussion around the previous
>> alternate header proposal

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 7 Mar 2017 11:41:39 -0800

>> I sent a bunch of comments in the PR. I think this is in the right
Thanks, will respond on PR.

>> - I don't think the key phase bit mechanism works correctly.
I'll take a look at your comments.

> The major negative of negotiating the packet number length is that it
> makes it impossible for passive observers to know what the length is.
> Which would make monitoring and features such as packet number echo
> impractical.
>

I'll add that without these bits, we need middleboxes (including load
balancers) to look into the handshake stream frames to determine what's
being negotiated. This means that we either require middleboxes to change
if we change the stream frame or the handshake format in the future, or we
make those bits version-independent.

I also have concerns with middleboxes getting this parsing wrong, which can
ossify bits inside the handshake stream frames in quite unfortunate ways.

Thanks! Will take a look.

- jana

>>> <https://www.ietf.org/mail-archive/web/quic/current/msg01012.html>,
>>> I've crafted PR #361 <https://github.com/quicwg/base-drafts/pull/361> that
>>> This PR closes a large number of issues. I'd like to get this merged
>>> into the draft by the draft deadline (a week from now), with the
>>> understanding that this format may still change as we discuss issues
>>> further. Please read and provide feedback.
>>>
>>> The PR is a bit invasive and unfortunately large, so I'll summarize a
>>> few salient points about it here.
>>>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 8 Mar 2017 23:27:50 -0800

I've received many helpful comments on the PR, which I've now incorporated
and I've gotten one approval. I've also gotten go-aheads from almost
everyone, so I'd like to land this PR on Thursday (PST), if possible. I'm
giving a heads-up to those who may not have had a chance to go over it yet:
please do it soon.

If I don't hear otherwise, I plan to land this PR at noon on Thursday (PST).

On Tue, Mar 7, 2017 at 11:41 AM, Jana Iyengar <[email-masked]> wrote:

> I also have concerns with middleboxes getting this parsing wrong, which
> can ossify bits inside the handshake stream frames in quite unfortunate
> ways.
>
>>>> - The PR includes a header-form bit that allows easy distinction
>>>> between long and short headers. It also delineates version-independent
>>>> fields from version-specific ones.
>>>>
>>>> - Public Reset packets are required to include a Proof, but the proof
>>>> is TBD.
>>>>
>>>> Thanks,
>>>> - jana
>>>>
>>>
>>>
>>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Mar 2017 19:50:59 +1100

> If I don't hear otherwise, I plan to land this PR at noon on Thursday (PST).

I think that this is a good idea.  I don't think that we need to have
consensus on every detail of this (and I don't think we do), but I
think that this will unblock a bunch of other work.  I hope that this
is acceptable to chairs process-wise.

On that point, a question for the chairs in light of Mark's recent
email regarding consensus decisions.  I expect that this single change
will result in a bunch of issues being closed.  A lot of those will be
closed as now being irrelevant, but some might not be fully "closed"
in the sense that the underlying concern wasn't addressed.  I hope
that the people reviewing this will identify new issues where this PR
fell short of meeting their goals.  Is that an acceptable process
here?  Do you want to avoid marking the issues we close as a result of
this change with "has-consensus"?

---

From: Ian Swett <[email-masked]>
Date: Thu, 9 Mar 2017 07:59:19 -0500

Sounds good to me as well.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 9 Mar 2017 08:04:01 -0500

On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson <[email-masked]>
wrote:

> hope
> here?

I completely agree with this. At this relatively early stage we need to
lean harder into landing stuff and then opening follow-on issues.. right
now there is a significant body of work that you have to hold in your head
"I know roughly how this is going to change" to meaningfully use even the
editor's copy - closing that gap would be very helpful. Obviously the
header is a big one.

For something like this I would suggest marking it consensus and perhaps
just commenting on any known caveats to help with paper trail.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 06:10:03 -0800

As Martin notes, I think there are a number of things that need discussion
here, but I'm happy to land it as a step in the right direction.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 9 Mar 2017 17:46:27 +0100

+1 to land it.

Cheers,

Brian

> On 09 Mar 2017, at 15:10, Eric Rescorla <[email-masked]> wrote:
> 
> As Martin notes, I think there are a number of things that need discussion here, but I'm happy to land it as a step in the right direction.
> 
> On Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus <[email-masked]> wrote:
> 
> On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson <[email-masked]> wrote:
> hope
> I completely agree with this. At this relatively early stage we need to lean harder into landing stuff and then opening follow-on issues.. right now there is a significant body of work that you have to hold in your head "I know roughly how this is going to change" to meaningfully use even the editor's copy - closing that gap would be very helpful. Obviously the header is a big one.
> 
> For something like this I would suggest marking it consensus and perhaps just commenting on any known caveats to help with paper trail.
>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 9 Mar 2017 12:00:16 -0800

Landed.

On Thu, Mar 9, 2017 at 8:46 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> > As Martin notes, I think there are a number of things that need
> discussion here, but I'm happy to land it as a step in the right direction.
> >