Subject: [quicwg/base-drafts] Why MUST a server use the same port for HTTP/QUIC? (#929)

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 Nov 2017 07:53:01 +0000 (UTC)

Section 3 on QUIC advertisement finishes with the following paragraph

> Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the same port across all IP addresses that serve a single domain, and SHOULD NOT change this port.

I have a few questions:

1. Where does the requirement to use the same port come from?
  a) Does this lock server owners into a single port for eternity? (per-user port advertisement seems unlikely to me)
  b) What happens if a server does listen on different ports? Is it a connection error?
  c) I can see some hypothetical problems, e.g. where Alt-Svc is used for load shedding to a different origin that resolves to an anycast IP, leading to violation. Similar to what has been discussed on #560 and #253.
2. Should clients pro-actively ignore non-compliant servers?
3. Why are port changes recommended against?
4. What should clients do if they see an Alt-Svc within the a HTTP/QUIC connection that changes the port.?

I appreciate the connection of this paragraph to QUIC advertisement. However, it actually seems quite fundamental guidance for HTTP/QUIC server deployments on how they should approach domain, IP and port usage. This makes me wonder if it should be broken out into a separate (sub)section or that it would pay to pull this information out into the manageability document.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 08:54:56 +0000 (UTC)

What does it even mean to place servers on specific ports? That a front load balancer ensures that this happens?

In docker based cloud environments such as SWARM and Kubernetes each server instance would be running a random port outside the container and typically some specific port internally, such as port 8080, but often unrelated to the public port number.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-344187859

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Nov 2017 14:45:05 +0000 (UTC)

Basically, it's saying that when the client receives an Alt-Svc advertisement that example.com can be reached at port x and hostname foo.bar, that should (and almost certainly SHOULD, but perhaps not MUST) mean a client can successfully receive example.com's content by connecting on port y to any IP address to which foo.bar resolves.  That you're allowed to pick ports arbitrarily, but you can't effectively expose different ports from multiple endpoints for the same hostname.

There are ways around this -- publish multiple hostnames with multiple Alt-Svc records, for example.  If you want to change ports, you would ideally have a transition period the duration of your Alt-Svc record lifetime in which both ports are accepted, though if you don't, a client that tries to connect could fail back to the origin and get the new record.

I could see an argument for putting this in the manageability draft, but it's almost more about the manageability of Alt-Svc than it is about QUIC or even HTTP/QUIC.  It's pertinent to HTTP/QUIC because Alt-Svc is the only defined way to discover an HTTP/QUIC endpoint, so we want to help implementers get it right.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-344280555

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 Nov 2017 06:08:53 +0000 (UTC)

Ok, I can buy into the justification to keep it in the HTTP mapping document. I think the section could be tightened up a bit; there seems some fuzziness between advertising servers and providing servers. It's not a burning issue and I could prepare some text to improve things (as I see it). 

I think this general topic is exacerbated by the implicit dependence on TCP as a fallback, I don't see any text in core documents that clearly state that. 

I welcome guidance and would highlight that, with my naive QUIC-enabled server deployment hat on, it isn't immediately clear how I should design my Alt-Svc advertisement strategy to be compliant. Or what the failure conditions are if I fail to comply.

Does the case you describe uniquely apply to UDP ports or to TCP too? Is it acceptable to share the number but only across TCP/UDP (I'd say yes because they are distinct spaces)?

> That you're allowed to pick ports arbitrarily, but you can't effectively expose different ports from multiple endpoints for the same hostname.

I'm not sure I see why this is a problem only for HTTP/QUIC, yet I have not seen similar requirements being expressed for other Alt-Svc advertisements.

To replay what I think you're saying, in example form:

| Origin | Alternative | Prohibited | Comment |
| - | -| -| -|
| https://example.com:443 | h2=":443" | No | Conventional h2 case, alternative has same hostname and same port |
| https://example.com:443 | h2=":12345" | Yes? | Conventional h2 case, alternative has same hostname and different port |
| https://example.com:443 | h2="foo.example.com:443" | No | Conventional h2 case, alternative has different hostname and same port|
| https://example.com:443 | h2="foo.example.com:1234" | No | Conventional h2 case, alternative has different hostname and different port |
| https://example.com:443 | h2="foo.example.com:12345", h2="foo.example.com:12346" | Yes? | Two h2 alternatives that share the same hostname but different ports. |
| https://example.com:443 | hq=":443" | No |  Simple hq case, alternative has same hostname and same port number but vary by TCP/UDP |
| https://example.com:443 | hq=":12345" | No |  Simple hq case, alternative has same hostname and different port, permitted by TCP/UDP |
| https://example.com:433 | hq="foo.example.com:443" | No | Simple hq case, alternative has different hostname and same port number, permitted by TCP/UDP and different host |
| https://example.com:433 | hq="foo.example.com:12345" | No | Simple hq case, alternative has different hostname and different port, permitted by TCP/UDP and different host |
| https://example.com:443 | hq="foo.example.com:12345", hq="foo.example.com:12346" | Yes | Two hq alternatives that share the same hostname but different port on UDP |
| https://example.com:12345 (a hq endpoint) | hq=":12346" | Yes | A hq origin is advertising its own hostname with a different port |
| https://example.com:12345 (a hq endpoint talking quic version 0xff00000C) | hq=":12346"; quic=D | Yes | A hq origin talking version C is advertising its own hostname with a different port and the different version D |

I'm tired so may be completely misunderstanding things.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-344495466

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 08:13:55 +0000 (UTC)

None of those examples should be prohibited, from a quick glance, because you seem to be presenting hostnames.  This is a deployment point, and the wording could be tightened (or perhaps dropped).

QUIC or not, if an Alt-Svc alternative has multiple IP addresses, then the port (for that alternative) has to be the same across all of them because you’re advertising a hostname and port combination.  If they’re separate alternatives, they can have separate ports; that’s fine.  TCP and UDP are completely independent spaces, but technically the same advice/requirement would apply to whichever port space an alternative happens to be in.

It’s basically saying that you can and perhaps should randomize your port, but the granularity of that randomization can’t be per-instance.

From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 2:09 PM
To: quicwg/base-drafts <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Comment <[email-masked]>
Subject: Re: [quicwg/base-drafts] Why MUST a server use the same port for HTTP/QUIC? (#929)

Origin

Alternative

Prohibited

Comment

https://example.com:443

h2=":443"

No

Conventional h2 case, alternative has same hostname and same port

https://example.com:443

h2=":12345"

Yes?

Conventional h2 case, alternative has same hostname and different port

https://example.com:443

h2="foo.example.com:443"

No

Conventional h2 case, alternative has different hostname and same port

https://example.com:443

h2="foo.example.com:1234"

No

Conventional h2 case, alternative has different hostname and different port

https://example.com:443

h2="foo.example.com:12345", h2="foo.example.com:12346"

Yes?

Two h2 alternatives that share the same hostname but different ports.

https://example.com:443

hq=":443"

No

Simple hq case, alternative has same hostname and same port number but vary by TCP/UDP

https://example.com:443

hq=":12345"

No

Simple hq case, alternative has same hostname and different port, permitted by TCP/UDP

https://example.com:433

hq="foo.example.com:443"

No

Simple hq case, alternative has different hostname and same port number, permitted by TCP/UDP and different host

https://example.com:433

hq="foo.example.com:12345"

No

Simple hq case, alternative has different hostname and different port, permitted by TCP/UDP and different host

https://example.com:443

hq="foo.example.com:12345", hq="foo.example.com:12346"

Yes

Two hq alternatives that share the same hostname but different port on UDP

https://example.com:12345 (a hq endpoint)

hq=":12346"

Yes

A hq origin is advertising its own hostname with a different port

https://example.com:12345 (a hq endpoint talking quic version 0xff00000C)

hq=":12346"; quic=D

Yes

A hq origin talking version C is advertising its own hostname with a different port and the different version D

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/929#issuecomment-344495466>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hXoFFPp_WLbesVCQJIRBTs9XjwhYks5s2n_0gaJpZM4Qc7ms>.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-344517207

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 Nov 2017 08:37:25 +0000 (UTC)

I need to think some more on this as things still seem a bit unclear.

The test points I've given are analogous to some cases we've tried out. There, the hostnames all resolve to the same set IP addresses - with a single server process listening on different ports and configured with different ghosts.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-344522515

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 20 Nov 2017 15:31:38 +0000 (UTC)

So I've discussed this with a colleague and thought about this some more.

Firstly, the genesis for the text we've got now was not obvious to someone less familiar with the document development. In other words, the randomisation of port number is implicit in the text rather than explicit. For reference sake, the applicable GH items are #424 and #495. 

However, meanwhile on #428 the WG has pursued the allocation of UDP port 443 to the IESG. This was recently closed off as completed.

So I'd say at this point, the paragraph in question is the victim of a higher-level tension that is yet to be resolved. I'd like to keep this ticket open in order for us track the issue such that it can be resolved once the other dependencies have been.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/929#issuecomment-345730399