Subject: Call for Adoption: Invariants

From: Mark Nottingham <[email-masked]>
Date: Mon, 5 Feb 2018 17:07:45 +1100

At the Melbourne meeting, there was strong support for adopting Martin's invariants draft:

https://tools.ietf.org/html/draft-thomson-quic-invariants-00

Any objections / concerns about doing so? Unless we hear otherwise, we'll adopt at the end of the week.

Cheers,

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 5 Feb 2018 07:51:34 +0000

Only concern is when it takes effect since it likely needs adjustments. And perhaps a procedure to handle invariant changes since everything changes.
________________________________
From: QUIC <[email-masked]> on behalf of Mark Nottingham <[email-masked]>
Sent: Monday, February 5, 2018 7:07:45 AM
To: QUIC WG
Cc: Lars Eggert
Subject: Call for Adoption: Invariants

Cheers,

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 5 Feb 2018 09:33:33 +0100

Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> Only concern is when it takes effect since it likely needs adjustments.

I'd presume that invariants is published simultaneously with the version 1 spec.

> And perhaps a procedure to handle invariant changes since everything changes.

Noted, though the point of declaring something an invariant is to say "the meaning of this part of the wire image, expressed as a bit offset, will never change". You can add constraints to the invariants, but if you think you might remove a constraint, then it's not an invariant by definition.

Cheers,

Brian

---

From: Ian Swett <[email-masked]>
Date: Mon, 5 Feb 2018 09:04:35 -0500

>From the perspective of someone intending to deploy draft versions, the
invariants need to be stable, ideally at least in a last call state, sooner
than the version 1 spec, otherwise there's no guarantee a server can
migrate from one version to another.

> Noted, though the point of declaring something an invariant is to say "the
> meaning of this part of the wire image, expressed as a bit offset, will
> never change". You can add constraints to the invariants, but if you think
> you might remove a constraint, then it's not an invariant by definition.
>
> Cheers,
>
> Brian
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 5 Feb 2018 08:18:10 -1000

Yes, invariants are useful, and the draft too.

Take the example of the omit CID bit in the short header. If it were version dependent, you could not understand it without first retrieving the connection context to find which version is used. But to do that you need to parse the CID, so you need to know whether it is present.

That said, what about the 17 bytes CID PR?

-- Christian Huitema 

> On Feb 5, 2018, at 4:04 AM, Ian Swett <[email-masked]> wrote:
> 
>> On Mon, Feb 5, 2018 at 3:33 AM, Brian Trammell (IETF) <[email-masked]> wrote:
>> Hi, all,
>> 
> From the perspective of someone intending to deploy draft versions, the invariants need to be stable, ideally at least in a last call state, sooner than the version 1 spec, otherwise there's no guarantee a server can migrate from one version to another.
> 
>>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 5 Feb 2018 19:00:53 +0000

I support adoption.  The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC.  If it happens to be startlingly similar, all well and good.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Lars Eggert <[email-masked]>; Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Call for Adoption: Invariants

Hi, all,

Cheers,

Brian

---

From: Roberto Peon <[email-masked]>
Date: Mon, 5 Feb 2018 19:05:14 +0000

Supported.
-=R

On 2/5/18, 11:01 AM, "QUIC on behalf of Mike Bishop" <[email-masked] on behalf of [email-masked]> wrote:

    
    -----Original Message-----

    

    
    Hi, all,

    

    

    

    Cheers,

    Brian

    

    

    
    
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dthomson-2Dquic-2Dinvariants-2D00&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=n2lIH7zPwu1fqpBUDcWUjVP95HAbaY7C09E0GkdeyCw&s=c3G4obrjxpXIoksS1cIl2limGbhBHXDkvvv3znFlpH8&e=

    

    
    
    > Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=n2lIH7zPwu1fqpBUDcWUjVP95HAbaY7C09E0GkdeyCw&s=gYxNCWYpVzWg2A4bb8Dzq9r4M7EtUPpc8QcUpMnYyqI&e=

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 5 Feb 2018 19:05:22 +0000

It could be called QUID ...

________________________________
From: Mike Bishop <[email-masked]>
Sent: Monday, February 5, 2018 8:00:53 PM
To: Brian Trammell (IETF); Mikkel Fahnøe Jørgensen
Cc: Lars Eggert; Mark Nottingham; QUIC WG
Subject: RE: Call for Adoption: Invariants

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Lars Eggert <[email-masked]>; Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Call for Adoption: Invariants

Hi, all,

Cheers,

Brian

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 5 Feb 2018 12:15:52 -0800

+1 for adoption.

As Ian pointed out, once published, any changes to the invariants will be a
significant uphill task for active deployments. That's the entire point of
having these invariants. I would very much like to publish the invariants
ahead of the rest of the documents, so that active deployment of IETF-QUIC
can start, but that's a matter for a different thread, not this one.

On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahnøe Jørgensen <[email-masked]

> ------------------------------
> *From:* Mike Bishop <[email-masked]>
> *Sent:* Monday, February 5, 2018 8:00:53 PM
> *To:* Brian Trammell (IETF); Mikkel Fahnøe Jørgensen
> *Cc:* Lars Eggert; Mark Nottingham; QUIC WG
> *Subject:* RE: Call for Adoption: Invariants
>
> I support adoption.  The way to change the invariants will be to mint a
> new protocol, and not claim that your new protocol is a version of QUIC.
> If it happens to be startlingly similar, all well and good.
>
> From: QUIC [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Brian Trammell (IETF)

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 5 Feb 2018 20:45:05 +0000

+1 for the adoption.

The adoption does not mean that the draft will be published exactly like it is right now.  But, as Jana said, I really hope we can settle this one before we settle v1 drafts.

From: Jana Iyengar [mailto:[email-masked]]
Sent: Monday, February 05, 2018 3:16 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Brian Trammell (IETF) <[email-masked]>; Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: Call for Adoption: Invariants

+1 for adoption.

As Ian pointed out, once published, any changes to the invariants will be a significant uphill task for active deployments. That's the entire point of having these invariants. I would very much like to publish the invariants ahead of the rest of the documents, so that active deployment of IETF-QUIC can start, but that's a matter for a different thread, not this one.

On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
It could be called QUID ...

From: Mike Bishop <[email-masked]<mailto:[email-masked]>>

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Cc: Lars Eggert <[email-masked]<mailto:[email-masked]>>; Mark Nottingham <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Call for Adoption: Invariants

Hi, all,

> On 5 Feb 2018, at 08:51, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
>

Cheers,

Brian

> From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Mark Nottingham <[email-masked]<mailto:[email-masked]>>
> https://tools.ietf.org/html/draft-thomson-quic-invariants-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dthomson-2Dquic-2Dinvariants-2D00&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=KX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s&s=bwNKnbE0d5ngNnELVEa6-RApXxOsA3r9ZZJ9OF448lk&e=>
>
> Mark Nottingham   https://www.mnot.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=KX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s&s=WabB1dQco52dWkhJg2dixu9nSahr_7BJChphDgHF-Cs&e=>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 5 Feb 2018 21:05:24 +0000

+1 for adoption

From: QUIC [mailto:[email-masked]] On Behalf Of Lubashev, Igor
Sent: Monday, February 5, 2018 12:45 PM
To: Jana Iyengar <[email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Brian Trammell (IETF) <[email-masked]>; Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>; Lars Eggert <[email-masked]>
Subject: RE: Call for Adoption: Invariants

+1 for the adoption.

Cc: Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; Mark Nottingham <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>

+1 for adoption.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Cc: Lars Eggert <[email-masked]<mailto:[email-masked]>>; Mark Nottingham <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Call for Adoption: Invariants

Hi, all,

Cheers,

Brian

> https://tools.ietf.org/html/draft-thomson-quic-invariants-00<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dthomson-2Dquic-2Dinvariants-2D00%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo%26m%3DKX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s%26s%3DbwNKnbE0d5ngNnELVEa6-RApXxOsA3r9ZZJ9OF448lk%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Ce96f6ed5ccf8441255f808d56cd961b8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636534603270020761&sdata=u3ud%2BPLfNMYQAh3bb2aAWKFbDBQlYuX9xFDwIGJHtaw%3D&reserved=0>
>
> Mark Nottingham   https://www.mnot.net/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.mnot.net_%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo%26m%3DKX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s%26s%3DWabB1dQco52dWkhJg2dixu9nSahr_7BJChphDgHF-Cs%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Ce96f6ed5ccf8441255f808d56cd961b8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636534603270020761&sdata=atLCZwPjicaw%2BuHfeJg5facYPLAW7jK7cYWsbRIhRa0%3D&reserved=0>

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 05 Feb 2018 15:04:25 -0800

+1 for adoption. 

Thanks,
Eric

> On Feb 5, 2018, at 1:05 PM, Praveen Balasubramanian <[email-masked]> wrote:
> 
> +1 for adoption
>  
> From: Jana Iyengar [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>>; Mark Nottingham <[email-masked] <mailto:[email-masked]>>; QUIC WG <[email-masked] <mailto:[email-masked]>>; Mike Bishop <[email-masked] <mailto:[email-masked]>>; Lars Eggert <[email-masked] <mailto:[email-masked]>>
> On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>> wrote:
> From: Mike Bishop <[email-masked] <mailto:[email-masked]>>
> From: QUIC [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Trammell (IETF)
> To: Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>>
> Cc: Lars Eggert <[email-masked] <mailto:[email-masked]>>; Mark Nottingham <[email-masked] <mailto:[email-masked]>>; QUIC WG <[email-masked] <mailto:[email-masked]>>
> > On 5 Feb 2018, at 08:51, Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > From: QUIC <[email-masked] <mailto:[email-masked]>> on behalf of Mark Nottingham <[email-masked] <mailto:[email-masked]>>
> > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dthomson-2Dquic-2Dinvariants-2D00%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo%26m%3DKX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s%26s%3DbwNKnbE0d5ngNnELVEa6-RApXxOsA3r9ZZJ9OF448lk%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Ce96f6ed5ccf8441255f808d56cd961b8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636534603270020761&sdata=u3ud%2BPLfNMYQAh3bb2aAWKFbDBQlYuX9xFDwIGJHtaw%3D&reserved=0>
> > 
> > Mark Nottingham   https://www.mnot.net/ <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.mnot.net_%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo%26m%3DKX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s%26s%3DWabB1dQco52dWkhJg2dixu9nSahr_7BJChphDgHF-Cs%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Ce96f6ed5ccf8441255f808d56cd961b8%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636534603270020761&sdata=atLCZwPjicaw%2BuHfeJg5facYPLAW7jK7cYWsbRIhRa0%3D&reserved=0>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Feb 2018 08:54:51 -0600

Asking with no hat, but ...

> If it happens to be startlingly similar, all well and good.

If you roll a new protocol, that's not a version of QUIC, is it obvious to
everyone but me whether you can run both protocols on UDP/443?

I thought I remembered that UDP/443 was chosen because firewalls often pass
port 443, so that aids deployment. Hence, my question.

Thanks,

Spencer

---

From: joel jaeggli <[email-masked]>
Date: Tue, 6 Feb 2018 08:36:25 -0800

On 2/6/18 6:54 AM, Spencer Dawkins at IETF wrote:
> On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I support adoption.  The way to change the invariants will be to
>     mint a new protocol, and not claim that your new protocol is a
>     version of QUIC.  If it happens to be startlingly similar, all
>     well and good.
>
>
> If you roll a new protocol, that's not a version of QUIC, is it
> obvious to everyone but me whether you can run both protocols on UDP/443? 
>
> I thought I remembered that UDP/443 was chosen because firewalls often
> pass port 443, so that aids deployment. Hence, my question.
In my experience as a vendor of and consumer of commercial firewalls.
UDP and TCP port numbers receive separate treatment.

So a decision to pass TCP 80/443  or UDP 443 would be undertaken
independently.

Outgoing UDP through a stateful NAT/PAT tends to create state for a
binding which will be used to map incoming packets with obverse 5-tuple
to the original sender. unsolicited incoming UDP (for which no binding
or rule exists) will be dropped.

There is the complexity with UDP of determining when you can remove the
state since connection oriented signaling may well be (is) opaque to the
stateful device. if you have to fall back to a timer or some kind of LRU
policy for state entries you will tend break long lived flows that don't
use keep-alives.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Feb 2018 17:59:49 +0000

At that point, you’re back in the “demuxing UDP protocols” discussion.  If there’s a way to differentiate the two protocols, then an endpoint could implement both and route incoming packets to the correct parser.

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Tuesday, February 6, 2018 6:55 AM
To: Mike Bishop <[email-masked]>
Cc: Brian Trammell (IETF) <[email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>; Lars Eggert <[email-masked]>; Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Call for Adoption: Invariants

On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
I support adoption.  The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC.  If it happens to be startlingly similar, all well and good.

If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443?

I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question.

Thanks,

Spencer

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Feb 2018 10:57:03 -0800

> everyone but me whether you can run both protocols on UDP/443?
Mike Bishop's PR defining httpq as a scheme (
https://github.com/quicwg/base-drafts/pull/348) defines UDP 443 as the
default for httpq.  I think that pretty much asserts that UDP/443 is QUIC,
not a forked variant.

> pass port 443, so that aids deployment. Hence, my question.
Yes.  That may cause us to consider carefully whether UDP/443 ought to be
defined for QUIC more rather than HTTP over QUIC, or even more generally.

Ted

---

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Feb 2018 19:09:59 +0000

Two notes, one against interest:  That PR is old and currently parked, because we don’t have consensus and it’s less urgent.  And secondly, UDP/443 is already allocated by IANA for HTTP over UDP.

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, February 6, 2018 10:57 AM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>; QUIC WG <[email-masked]>; Mark Nottingham <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: Call for Adoption: Invariants

On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Asking with no hat, but ...

Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/base-drafts/pull/348) defines UDP 443 as the default for httpq.  I think that pretty much asserts that UDP/443 is QUIC, not a forked variant.

Yes.  That may cause us to consider carefully whether UDP/443 ought to be defined for QUIC more rather than HTTP over QUIC, or even more generally.
Ted

Thanks,

Spencer

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 6 Feb 2018 11:26:07 -0800

What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not
required for HTTP/QUIC. The HTTP mapping document currently says (in Section
2.1
<https://quicwg.github.io/base-drafts/draft-ietf-quic-http.html#rfc.section.2.1>)
"Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but
let's move that discussion to where it belongs, on #495
<https://github.com/quicwg/base-drafts/issues/495>.

The QUIC transport draft specifically does not say anything about which UDP
ports are to be used -- QUIC is a transport after all, and there is no
reason to tie the entire transport to a port.

On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <[email-masked]> wrote:

> Two notes, one against interest:  That PR is old and currently parked,
> because we don’t have consensus and it’s less urgent.  And secondly,
> UDP/443 is already allocated by IANA for HTTP over UDP.
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Tuesday, February 6, 2018 10:57 AM
> *To:* Spencer Dawkins at IETF <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; Brian Trammell (IETF) <
> [email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>; QUIC WG <
> [email-masked]>; Mark Nottingham <[email-masked]>; Lars Eggert <
> [email-masked]>
> *Subject:* Re: Call for Adoption: Invariants
>
>
>
> Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/
> base-drafts/pull/348) defines UDP 443 as the default for httpq.  I think
> that pretty much asserts that UDP/443 is QUIC, not a forked variant.
>
>
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 6 Feb 2018 20:48:08 +0000

+1 on “The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.”

From: QUIC [mailto:[email-masked]] On Behalf Of Jana Iyengar
Sent: Tuesday, February 6, 2018 11:26 AM
To: Mike Bishop <[email-masked]>
Cc: Ted Hardie <[email-masked]>; Mark Nottingham <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; Lars Eggert <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Mikkel Fahnøe Jørgensen <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Call for Adoption: Invariants

What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not required for HTTP/QUIC. The HTTP mapping document currently says (in Section 2.1<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.github.io%2Fbase-drafts%2Fdraft-ietf-quic-http.html%23rfc.section.2.1&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805671598&sdata=%2B0h%2B1meATs8rcF%2F66Tb%2BvxshTFFULLfwqwoHxuy6Cb0%3D&reserved=0>) "Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but let's move that discussion to where it belongs, on #495<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F495&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=ams4Bh5t3rldzh4uok6YJvGlnx8o0R7ELAogQ8iIK54%3D&reserved=0>.

The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.

On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Two notes, one against interest:  That PR is old and currently parked, because we don’t have consensus and it’s less urgent.  And secondly, UDP/443 is already allocated by IANA for HTTP over UDP.

From: Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, February 6, 2018 10:57 AM
To: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>; Mark Nottingham <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>
Subject: Re: Call for Adoption: Invariants

Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/base-drafts/pull/348<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F348&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=wTDG5fmupXJRRSFroNyBRpcbuwjQzz5fXs%2B41F6DheA%3D&reserved=0>) defines UDP 443 as the default for httpq.  I think that pretty much asserts that UDP/443 is QUIC, not a forked variant.

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 8 Feb 2018 05:10:46 -0600

Still with no hat ...

On Feb 6, 2018 14:48, "Praveen Balasubramanian" <[email-masked]> wrote:

+1 on “The QUIC transport draft specifically does not say anything about
which UDP ports are to be used -- QUIC is a transport after all, and there
is no reason to tie the entire transport to a port.”

Thanks to multiple people who have replied.

I understand that QUIC isn't tied to a single UDP port number. I was
thinking about the deployability story for a non-backward-compatible QUIC
version that can't be demuxed from previous versions - what I think I'm
hearing is that such a new QUIC version would require thought about getting
a new UDP port opened the way 443 seems to be today.

I'll shut up and let you guys do QUIC now :-)

Spencer

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *Jana Iyengar
*Sent:* Tuesday, February 6, 2018 11:26 AM
*To:* Mike Bishop <[email-masked]>
*Cc:* Ted Hardie <[email-masked]>; Mark Nottingham <[email-masked]>;
Spencer Dawkins at IETF <[email-masked]>; Lars Eggert <
[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Mikkel Fahnøe
Jørgensen <[email-masked]>; QUIC WG <[email-masked]>

What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not
required for HTTP/QUIC. The HTTP mapping document currently says (in Section
2.1
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.github.io%2Fbase-drafts%2Fdraft-ietf-quic-http.html%23rfc.section.2.1&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805671598&sdata=%2B0h%2B1meATs8rcF%2F66Tb%2BvxshTFFULLfwqwoHxuy6Cb0%3D&reserved=0>)
"Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but
let's move that discussion to where it belongs, on #495
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F495&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=ams4Bh5t3rldzh4uok6YJvGlnx8o0R7ELAogQ8iIK54%3D&reserved=0>
.

I support adoption.  The way to change the invariants will be to mint a new
protocol, and not claim that your new protocol is a version of QUIC.  If it
happens to be startlingly similar, all well and good.

Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/
base-drafts/pull/348
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F348&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=wTDG5fmupXJRRSFroNyBRpcbuwjQzz5fXs%2B41F6DheA%3D&reserved=0>)
defines UDP 443 as the default for httpq.  I think that pretty much asserts
that UDP/443 is QUIC, not a forked variant.

Ted

Thanks,

Spencer

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 14 Feb 2018 04:59:54 +0000

Having seen nothing but support, this document is adopted.

Lars

> On 2018-2-5, at 7:07, Mark Nottingham <[email-masked]> wrote:
>