Subject: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering

From: Ariel Otilibili Anieli <[email-masked]>
Date: Sun, 08 Apr 2018 20:01:58 +0200

Hi Jana, Hi Martin,

Here is my review of the draft:

1. The document defines QUIC, but nowhere have I come across the  
definition of its acronym: it would help readers to get it from the  
abstract, or no later than the introduction.

2. Section 2 lays out the Conventions and Definitions, but does not  
state the meaning of frames (though they are used many times). Section  
2 should also define what is a frame, and how it relates with a  
streams and a packet.

3. Some typos; the text contains abbreviations (e.g, "isn't" for "is  
not", "don't" for "do not"), and also considers technical terms as  
legal persons ("QUIC's ACK frames", "TCP's retransmission"). See them  
in the attachment.

Finally, on the QUIC version numbering: I think it would ease readers  
to have a human-friendly representation, as IPv4 and IPv6 do; I  
propose to follow the example of MAC and IPv6 addresses:

     * 00:00:00:00 for 0x00000000
     * 00:00:00:01 for 0x00000001
     * ff:00:00:00D for 0xff00000D

And allow double-dotted notation as in IPv6 (so sequence of zeros be grouped):

     * ::0 for 0x00000000
     * ::1 for 0x00000001
     * ff::0D for 0xff00000D

What do you think?

Regards,
Ariel

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 8 Apr 2018 11:16:06 -0700

Hi Ariel,

on the proposed dotted QUIC version numbers - I think it would be to easy
to confuse with an IP number.
There are many internal hex codes such as frame header types in a QUIC
implementation and the
supported version list would fit naturally in plain hex.

For public / human communication I believe some informal name would be
associated with each version - current QUIC v1 and QUIC v2 similar to IPV4
and IPv6. Also custom versions like gQUICxx are being used informally.
Perhaps this could be more formalized, at least for v1 and v2?

Kind Regards,
Mikkel Fahnøe Jørgensen

On 8 April 2018 at 20.02.12, Ariel Otilibili Anieli ([email-masked])
wrote:

Hi Jana, Hi Martin,

And allow double-dotted notation as in IPv6 (so sequence of zeros be
grouped):

* ::0 for 0x00000000
* ::1 for 0x00000001
* ff::0D for 0xff00000D

What do you think?

Regards,
Ariel

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Sun, 08 Apr 2018 20:27:18 +0200

Hi Mikkel,

My comments in line.

Regards,
Ariel

> Perhaps this could be more formalized, at least for v1 and v2?
I go for your proposal; the document should declare a formal,  
human-friendly name (QUICv1 for instance), or explicitly says  
somewhere "0x00000001 corresponds to the version 1 of QUIC".

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Apr 2018 11:18:51 +1000

Hi Ariel,

Thanks for the input.

On Mon, Apr 9, 2018 at 4:01 AM, Ariel Otilibili Anieli
<[email-masked]> wrote:
> 1. The document defines QUIC, but nowhere have I come across the definition
> of its acronym: it would help readers to get it from the abstract, or no
> later than the introduction.

QUIC is not an acronym.  You are expected to shout it ;)

> 2. Section 2 lays out the Conventions and Definitions, but does not state
> the meaning of frames (though they are used many times). Section 2 should
> also define what is a frame, and how it relates with a streams and a packet.

A pull request would be welcome.

> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is not",
> "don't" for "do not"), and also considers technical terms as legal persons
> ("QUIC's ACK frames", "TCP's retransmission"). See them in the attachment.

I don't consider use of contractions to be typos.  I do try to avoid
the possessive form, but I suspect that I or other contributors slip
on occasion.  Again, a pull request is the best way to make this
contribution.

> Finally, on the QUIC version numbering: I think it would ease readers to
> have a human-friendly representation

I think that "1" is perfectly human friendly.  It's just a number.  We
use the full, unambiguous form in a specification because we believe
our audience is capable of handling that.  Feel free to use whatever
numerical representation you feel suits you best.

Unambiguous textual representations are not a goal here, as it is
(unfortunately) for addresses.  If the number is presented to a human,
I sincerely hope that they are an engineer and therefore capable of
coping.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Apr 2018 14:52:18 +0900

> QUIC is not an acronym.  You are expected to shout it ;)

Good to know. Maybe the text (introduction) could say so?

Regards,   Martin.

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Mon, 09 Apr 2018 09:02:33 +0200

Hi Martin, hi Martin,

A comment in line.

Regards,
Ariel

> Good to know. Maybe the text (introduction) could say so?
"QUIC (Quick UDP Internet Connections, pronounced quick) is an  
experimental transport layer" says Wikipedia,  
https://en.wikipedia.org/wiki/QUIC

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Apr 2018 17:05:06 +1000

On Mon, Apr 9, 2018 at 5:02 PM, Ariel Otilibili Anieli
<[email-masked]> wrote:
> "QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental
> transport layer" says Wikipedia, https://en.wikipedia.org/wiki/QUIC

Yes.  That is an expansion that has been used.  We explicitly decided
not to use that.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 9 Apr 2018 08:26:09 +0000

In day to day talk I tell people that QUIC is the KFC of transport protocols, and has similar levels of GREASE.

Lucas
________________________________________
From: QUIC [[email-masked]] on behalf of Martin Thomson [[email-masked]]
Sent: 09 April 2018 08:05
To: Ariel Otilibili Anieli
Cc: Jana Iyengar; Martin J. Dürst; QUIC WG
Subject: Re: Review of draft-ietf-quic-transport-10, and a proposal for a human-friendly QUIC version numbering

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 04:31:11 -0400

http://fortune.com/2018/02/23/kfc-chicken-shortage-apology/

I guess the equivalent would be to write ICUQ when running out of UDP
packets.

Mikkel

On 9 April 2018 at 10.26.22, Lucas Pardue ([email-masked]) wrote:

In day to day talk I tell people that QUIC is the KFC of transport
protocols, and has similar levels of GREASE.

Lucas

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Mon, 09 Apr 2018 10:42:08 +0200

Hi,

My comments inline.

Regards,
Ariel

> protocols, and has similar levels of GREASE.
I will propose a pull request: "QUIC used to be known as 'Quick UDP  
Internet Connections', but the present RFC advises it be used no more:  
QUIC does not stand for an acronym".

What do you think?

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Apr 2018 18:11:46 +0900

> QUIC does not stand for an acronym".

"QUIC does not stand for an acronym" -> "QUIC is not an acronym" and/or 
"QUIC does not stand for anything".

Regards,   Martin.

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Mon, 09 Apr 2018 11:24:05 +0200

Hi all,

Inline the pull request I will propose in the Introduction. Does  
everyone agree with it?

Regards,
Ariel

Quoting "Martin J. Dürst" <[email-masked]>:

>>  Internet Connections', but the present RFC advises it be used no   
>> more: QUIC does not stand for an acronym".
>
Fixed: "QUIC is not an acronym: it does not stand for anything."

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Apr 2018 09:43:38 -0700

I would drop the part about past backronym. If you repeat it, you perpetuate it. If you want history, you have to explain the lineage from FAST    to QUIC, and an RFC is not the place to do that.

-- Christian Huitema 

> On Apr 9, 2018, at 2:24 AM, Ariel Otilibili Anieli <[email-masked]> wrote:
> 
> Hi all,
> 
> Inline the pull request I will propose in the Introduction. Does everyone agree with it?
> 
> Regards,
> Ariel
> 
>>> I will propose a pull request: "QUIC used to be known as 'Quick UDP  Internet Connections', but the present RFC advises it be used no  more: QUIC does not stand for an acronym".
>>

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Tue, 10 Apr 2018 10:34:51 +0200

Hi all,

Herewith the pull request; it sums up the discussion on the meaning of QUIC:

https://github.com/quicwg/base-drafts/pull/1282

Regards,
Ariel

Quoting Christian Huitema <[email-masked]>:

> I would drop the part about past backronym. If you repeat it, you   
> perpetuate it. If you want history, you have to explain the lineage   
> from FAST    to QUIC, and an RFC is not the place to do that.
>
> -- Christian Huitema
>
>>>> I will propose a pull request: "QUIC used to be known as 'Quick   
>>>> UDP  Internet Connections', but the present RFC advises it be   
>>>> used no  more: QUIC does not stand for an acronym".
>>>

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Tue, 10 Apr 2018 16:32:50 +0200

Hi Martin,

A comment inline. And another thing on this draft:

QUIC defines PING frames, and relies at the same time on TLS. TLS has  
already the Heartbeat protocol (https://tools.ietf.org/html/rfc6520);  
it provides the same functions than PING frames.

Section 8.9 should clarify: which layer dominates the other: PING  
frames, or TLS Heartbeat?

Regards,
Ariel

> QUIC is not an acronym.  You are expected to shout it ;)
Stated in https://github.com/quicwg/base-drafts/pull/1282

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 10 Apr 2018 11:30:04 -0400

TLS is only used for handshake and for periodic rekeying.

Everything else is fully managed by QUIC, so a TLS heartbeat would not be
useful. PING also serves other purposes including asking for ACK messages
to be sent.

Even crypto is not handled by TLS after handshake although it does provide
the keys and although TLS libraries likely implement the required
functionality.

On 10 April 2018 at 16.33.02, Ariel Otilibili Anieli ([email-masked])
wrote:

Hi Martin,

Regards,
Ariel

>> 1. The document defines QUIC, but nowhere have I come across the
definition
>> 2. Section 2 lays out the Conventions and Definitions, but does not
state
>> 3. Some typos; the text contains abbreviations (e.g, "isn't" for "is
not",
>> ("QUIC's ACK frames", "TCP's retransmission"). See them in the
attachment..

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Apr 2018 17:59:11 +0000

It’s not even used for rekeying any more – that’s done at the QUIC layer as well.  The only post-handshake use of TLS is the NewSessionTicket message.

From: QUIC [mailto:[email-masked]] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Tuesday, April 10, 2018 8:30 AM
To: Martin Thomson <[email-masked]>; Ariel Otilibili Anieli <[email-masked]>; Jana Iyengar <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: Comments draft-ietf-quic-transport-10

Everything else is fully managed by QUIC, so a TLS heartbeat would not be useful. PING also serves other purposes including asking for ACK messages to be sent.

Even crypto is not handled by TLS after handshake although it does provide the keys and although TLS libraries likely implement the required functionality.

On 10 April 2018 at 16.33.02, Ariel Otilibili Anieli ([email-masked]<mailto:[email-masked]>) wrote:
Hi Martin,

Regards,
Ariel

Quoting Martin Thomson <[email-masked]<mailto:[email-masked]>>:

> <[email-masked]<mailto:[email-masked]>> wrote:
>> ("QUIC's ACK frames", "TCP's retransmission"). See them in the attachment..
>