Subject: DRAFT minutes from IETF103 Bangkok

From: Mark Nottingham <[email-masked]>
Date: Sun, 11 Nov 2018 12:01:07 +1100

... are available at:
  https://github.com/quicwg/wg-materials/blob/master/ietf103/minutes.md

As always, corrections and suggestions welcome, ideally as a Pull Request (but e-mail is acceptable).

Thanks to our scribes.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Roberto Peon <[email-masked]>
Date: Mon, 12 Nov 2018 19:06:30 +0000

Can anyone fill in with some more color what was discussed in:

  "length prefixed frames considered irksome"

-=R

On 11/10/18, 5:01 PM, "QUIC on behalf of Mark Nottingham" <[email-masked] on behalf of [email-masked]> wrote:

    .... are available at:

    Thanks to our scribes.
    
    Cheers,
    
    --
    Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=6D8zx2bDm7HnVQ8e-7zETo0lTGDV1ZlbHb8R7fjUbAM&s=xsnYRE4Joi6vK2D2L1kkBekSOHmDT_vW_JpaPsXJDDE&e=

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Nov 2018 12:01:23 -0800

I wasn’t there, but based on previous discussions on github there is an
issue with sending large content and streaming content where you don’t know
the end in advance. You are forced to buffer up chunks. It would be
convenient (or less irksome) to just write content until done, then end a
stream, but that can’t happen if you must store a length prefix. It was
then proposed to use 0 as such a marker in place of length prefix to allow
this. Somebody then proposed doing that for all frame types because it
seemed nice/symmetric, but others thought that would just complicate
general frame handling and nobody really had a strong need for general
frame support. So the idea floated that perhaps it made sense to use 0 as
sentinel just for data frames the continue to the end of the stream as much
as special values are disliked in some circles. I believe that was the
entry point for that bullet.

On 12 November 2018 at 20.06.48, Roberto Peon ([email-masked]) wrote:

-=R

On 11/10/18, 5:01 PM, "QUIC on behalf of Mark Nottingham" <
[email-masked] on behalf of [email-masked]> wrote:

.... are available at:

As always, corrections and suggestions welcome, ideally as a Pull Request
(but e-mail is acceptable).

Thanks to our scribes.

Cheers,

-- 
Mark Nottingham
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=6D8zx2bDm7HnVQ8e-7zETo0lTGDV1ZlbHb8R7fjUbAM&s=xsnYRE4Joi6vK2D2L1kkBekSOHmDT_vW_JpaPsXJDDE&e=

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 12 Nov 2018 15:04:26 -0500

On Mon, Nov 12, 2018 at 12:01:23PM -0800, Mikkel Fahnøe Jørgensen wrote:
> It was then proposed to use 0 as such a marker in place of length
> prefix to allow this. Somebody then proposed doing that for all frame
> types because it seemed nice/symmetric, but others thought that would
> just complicate general frame handling and nobody really had a strong
> need for general frame support. So the idea floated that perhaps it
> made sense to use 0 as sentinel just for data frames the continue to
> the end of the stream as much as special values are disliked in some
> circles.

I don't believe we came to a conclusion, though: will all frames be
extensible to EOS or just the DATA frame?  I vote for the former if
it's not too late.

  - Dmitri.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 12 Nov 2018 20:04:10 +0000

I didn’t see that github discussion. That makes sense.
Thanks Mikkel!

-=R

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Monday, November 12, 2018 at 12:01 PM
To: QUIC IETF mailing list <[email-masked]>, Roberto Peon <[email-masked]>, Mark Nottingham <[email-masked]>
Subject: Re: DRAFT minutes from IETF103 Bangkok

I wasn’t there, but based on previous discussions on github there is an issue with sending large content and streaming content where you don’t know the end in advance. You are forced to buffer up chunks. It would be convenient (or less irksome) to just write content until done, then end a stream, but that can’t happen if you must store a length prefix. It was then proposed to use 0 as such a marker in place of length prefix to allow this. Somebody then proposed doing that for all frame types because it seemed nice/symmetric, but others thought that would just complicate general frame handling and nobody really had a strong need for general frame support. So the idea floated that perhaps it made sense to use 0 as sentinel just for data frames the continue to the end of the stream as much as special values are disliked in some circles. I believe that was the entry point for that bullet.

On 12 November 2018 at 20.06.48, Roberto Peon ([email-masked]<mailto:[email-masked]>) wrote:
Can anyone fill in with some more color what was discussed in:

-=R

On 11/10/18, 5:01 PM, "QUIC on behalf of Mark Nottingham" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

.... are available at:

Thanks to our scribes.

Cheers,

---

From: Ian Swett <[email-masked]>
Date: Mon, 12 Nov 2018 15:06:51 -0500

I agree with Dmitri, that is both consistent and uses the currently invalid
length value of 0.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Nov 2018 12:14:52 -0800

So, I’m not sufficiently into H3 to have a qualified opinion on this, but
my take on this (which was reflected by others as well AFAIR) is that
testing for 0 in a lot of frame types that don’t have a logical until end
of stream semantic just complicates stream processing and allows for a new
error case. OTOH, being able to stream data until end of stream is highly
valuable, bordering necessary. So it is appealing to have a special
encoding for streamed data.

But I also agree that having 0 special, for a special frame, is special.

Perhaps it could be a different DATA frame type instead?

On 12 November 2018 at 21.07.05, Ian Swett ([email-masked]) wrote:

---

From: Roberto Peon <[email-masked]>
Date: Mon, 12 Nov 2018 20:25:16 +0000

I’d settle for ‘good enough, it works.’
For partial reliability-related stuff, neither of these work particularly well anyway due to address-space interpretation problems.
-=R

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Monday, November 12, 2018 at 12:15 PM
To: IETF QUIC WG <[email-masked]>, Roberto Peon <[email-masked]>, Ian Swett <[email-masked]>, Mark Nottingham <[email-masked]>
Subject: Re: DRAFT minutes from IETF103 Bangkok

So, I’m not sufficiently into H3 to have a qualified opinion on this, but my take on this (which was reflected by others as well AFAIR) is that testing for 0 in a lot of frame types that don’t have a logical until end of stream semantic just complicates stream processing and allows for a new error case. OTOH, being able to stream data until end of stream is highly valuable, bordering necessary. So it is appealing to have a special encoding for streamed data.

On 12 November 2018 at 21.07.05, Ian Swett ([email-masked]<mailto:[email-masked]>) wrote:
I agree with Dmitri, that is both consistent and uses the currently invalid length value of 0.

On Mon, Nov 12, 2018 at 3:04 PM Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>> wrote:

  - Dmitri.

---

From: Ian Swett <[email-masked]>
Date: Mon, 12 Nov 2018 15:31:06 -0500

Actually, for partial reliability, you have to get the HTTP/3 framing
right(enough) as well as the application framing if lengths are present.
Whereas you only have to get the application framing right if there are no
lengths.

On Mon, Nov 12, 2018 at 3:25 PM Roberto Peon <[email-masked]> wrote:

> For partial reliability-related stuff, neither of these work particularly
> well anyway due to address-space interpretation problems.
>
> -=R
>
>
>
> *From: *Mikkel Fahnøe Jørgensen <[email-masked]>
> *Date: *Monday, November 12, 2018 at 12:15 PM
> *To: *IETF QUIC WG <[email-masked]>, Roberto Peon <[email-masked]>, Ian
> Swett <[email-masked]>, Mark Nottingham <[email-masked]>
> *Subject: *Re: DRAFT minutes from IETF103 Bangkok
>
>
>
>
>
> On Mon, Nov 12, 2018 at 3:04 PM Dmitri Tikhonov <
> [email-masked]> wrote:
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Nov 2018 12:38:05 -0800

Just for the record, the discussion I was referring to also touched upon an
optional trailing part which must come after the main data out of
synchronisation concerns. This makes stream until end more complicated in
that situation.

Mikkel

On 12 November 2018 at 21.31.19, Ian Swett ([email-masked]) wrote:

On Mon, Nov 12, 2018 at 3:25 PM Roberto Peon <[email-masked]> wrote:

> *From:* Mikkel Fahnøe Jørgensen <[email-masked]>
> *Date:* Monday, November 12, 2018 at 12:15 PM
> *To:* IETF QUIC WG <[email-masked]>, Roberto Peon <[email-masked]>, Ian
> *Subject:* Re: DRAFT minutes from IETF103 Bangkok
>
>
>
>
>

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 12 Nov 2018 15:43:02 -0500

That's true.  We can:

    A) Do nothing;
    B) Make all HQ^H3 frames extensible to EOS; or
    C) Make the DATA frame extend to EOS if its size is zero.

My preference is B, A, C, in this order.

  - Dmitri.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 12 Nov 2018 13:04:24 -0800

D) Add an SDATA frame that always extends to EOS.

On 12 November 2018 at 21.43.05, Dmitri Tikhonov (
[email-masked]) wrote:

That's true. We can:

A) Do nothing;

- Dmitri.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Nov 2018 16:34:52 +0000

If a stream contains only payload (or always includes the payload offset at the start of every packet), then PR is workable. I think I’m agreeing? ☺
TBH, PR (and especially application-layer invariant PR) is a whole new can of worms that involves other changes.

I’d rather we not really think about it until we’ve finalized “v1.”
-=R

From: Ian Swett <[email-masked]>
Date: Monday, November 12, 2018 at 12:31 PM
To: Roberto Peon <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>, IETF QUIC WG <[email-masked]>, Mark Nottingham <[email-masked]>
Subject: Re: DRAFT minutes from IETF103 Bangkok

Actually, for partial reliability, you have to get the HTTP/3 framing right(enough) as well as the application framing if lengths are present.  Whereas you only have to get the application framing right if there are no lengths.

On Mon, Nov 12, 2018 at 3:25 PM Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
I’d settle for ‘good enough, it works.’
For partial reliability-related stuff, neither of these work particularly well anyway due to address-space interpretation problems.
-=R

From: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 12, 2018 at 12:15 PM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>, Roberto Peon <[email-masked]<mailto:[email-masked]>>, Ian Swett <[email-masked]<mailto:[email-masked]>>, Mark Nottingham <[email-masked]<mailto:[email-masked]>>
Subject: Re: DRAFT minutes from IETF103 Bangkok

  - Dmitri.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Nov 2018 16:58:27 +0000

There was also a discussion offline after the meeting about another option: create a different frame type / redefine DATA to reference a unidirectional stream which will carry nothing but payload and no framing.  Thus you have the request stream giving you the ordering amongst chunks and other request-related frames, while the unidirectional stream carries the actual body (or portion of the body) unframed.

There are certain advantages to that – besides not having to length-prefix anything, future partial reliability becomes easier (and you can select it on a per-portion basis).  The main difficulty I see is that a client can’t start opening the flow control window wider until you’ve received the stream ID for the response body, where otherwise it would be able to increase flow control selectively in parallel to sending a request.

From: QUIC <[email-masked]> On Behalf Of Roberto Peon
Sent: Tuesday, November 13, 2018 8:35 AM
To: Ian Swett <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; IETF QUIC WG <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: DRAFT minutes from IETF103 Bangkok

From: Ian Swett <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 12, 2018 at 12:31 PM
To: Roberto Peon <[email-masked]<mailto:[email-masked]>>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>, IETF QUIC WG <[email-masked]<mailto:[email-masked]>>, Mark Nottingham <[email-masked]<mailto:[email-masked]>>
Subject: Re: DRAFT minutes from IETF103 Bangkok

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 13 Nov 2018 12:37:26 -0500

We should go with the simplest solution that will satisfy those who find
framing problematic.  Adding ability to extend frames -- existing or new
-- to the end of the stream is the most straightforward approach to the
issue at hand.

Splitting frame headers and data between streams is throwing out the baby
with the bathwater when all we need is a simple, efficient way to
packetize payload.

  - Dmitri.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Nov 2018 18:15:30 +0000

That’d certainly be my strong preference.
-=R

From: Mike Bishop <[email-masked]>
Date: Tuesday, November 13, 2018 at 8:58 AM
To: Roberto Peon <[email-masked]>, Ian Swett <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>, IETF QUIC WG <[email-masked]>, Mark Nottingham <[email-masked]>
Subject: RE: DRAFT minutes from IETF103 Bangkok

  - Dmitri.