Subject: [quicwg/base-drafts] Treat client and server as equals (#462)

From: MikkelFJ <[email-masked]>
Date: Tue, 25 Apr 2017 11:00:40 -0700

The draft appears to be focusing on a client server model such as an http server, but client and server can be peers, for example in peer to peer file sharing networks.

This becomes visible in 
https://github.com/quicwg/base-drafts/issues/170
where the client may experience highly likely collisions because the server is not required to generate random identifiers. The client is then forced to rely on dest address, but this ties the protocol to IP/UDP more than necessary.

It can also be seen in the assymetric direction of PUBLIC_RESET. A client cannot, in the current draft, shut down a connection like a server can, after a crash. Mentioned here
https://github.com/quicwg/base-drafts/issues/442

-- 
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/462

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Apr 2017 23:54:05 -0700

Note that this latter point is incorrect.  I was careful to make public reset symmetric.  Now, the utility of that is pretty low for HTTP, and is probably even lower in p2p cases based on my experience with the NAT traversal systems that are needed there (see ICE).

The notion that the client might use a non-unique source address and port for a new connection is really stretching the design too much for me.

-- 
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/462#issuecomment-297257194

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Apr 2017 00:39:15 -0700

>  I was careful to make public reset symmetric. 
Good, I just seem to the recall the wording "a server can send... "

If you cannot associate initial state based on connection id, what is the point of doing it later on?

-- 
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/462#issuecomment-297270492

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Apr 2017 00:46:31 -0700

> A Public Reset packet is only sent by servers and is used to abruptly terminate communications. Public Reset is provided as an option of last resort for a server that does not have access to the state of a connection.

-- 
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/462#issuecomment-297273516

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Apr 2017 05:08:07 -0700

Hmm, we definitely need to sort that out.  Arguably the server is the only peer that matters here.  If you have a case where a client needs to send a public reset, then you should make a case for that (preferably in a new issue).

-- 
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/462#issuecomment-297383356

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Apr 2017 06:18:33 -0700

I provided a use case for public reset in the above issue.

A use case for connection id based connection id binding with non-unique ports is: Using the netmap highperformance network interface, all traffic goes directly to the QUIC connection handler and ports do not really exist other than because UDP is used to punch through firewalls. Many, or at least several, connections may be created to a peer, and maitaining unique port numbers here is just overhead. In addition, for symmetric peer-to-peer, this allows middleboxes on either side to only allow UDP traffic to/from a specified port. But the main point, is the being able to just rely on a single connection ID simplifies issues significantly for implementations that are not wedded to traditional socket operation.

-- 
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/462#issuecomment-297404690