Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What do we do if special packets are lost #241

Closed
siyengar opened this issue Jan 26, 2017 · 4 comments
Closed

What do we do if special packets are lost #241

siyengar opened this issue Jan 26, 2017 · 4 comments
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@siyengar
Copy link

For example if the version negotiation packet is lost, there's no ACK frame for the receiver to signal anything to the sender, we should specify what the loss recovery behavior for version negotiation and other special packets is.

@MikeBishop
Copy link
Contributor

I think this is already dealt with -- the server responds with a Version Negotiation packet to every packet from the client. If any packet and its response make it through, the client will know what to do. If no packet pair makes it through the whole round trip and the client gets no response, the client will assume that its packet was lost and retransmit it.

@martinthomson
Copy link
Member

There are three cases of interest here: the initial handshake packet from a client (if lost retry on a timer), the version negotiation packet (send in response to every packet that arrives with the wrong version number ...maybe limiting it to those that are plausibly an initial handshake packet), and a public reset (I don't know what the rule might be here, but I suspect there is a timer involved as well).

@ianswett
Copy link
Contributor

ianswett commented Feb 2, 2017

Agreed on the first two.

Public reset currently is, and I believe should continue to be, like the version negotiation packet. Send (at most) one per packet received. Public resets need to be stateless, and timers add state.

@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Feb 3, 2017
martinthomson added a commit that referenced this issue Apr 27, 2017
1. Version negotiation is stateless (this was implied but not made explicit)

2. Client ignores version negotiation packets if it has already done version
   negotiation.

3. Client ignores version negotaition packets if they list the version it is
   using.

Closes #284, #294, #241.
@mnot mnot added this to Reliability in QUIC Apr 28, 2017
@martinthomson
Copy link
Member

Closing after #474. I will open an issue regarding the generation of public reset in response to short form headers and other packets that are clearly not starting a handshake. Those packets that shouldn't arrive should be ignored.

@martinthomson martinthomson removed this from Reliability in QUIC May 4, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Sep 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

5 participants