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

Fix Recovery Pseudocode #2907

Merged
merged 25 commits into from
Sep 4, 2019
Merged

Fix Recovery Pseudocode #2907

merged 25 commits into from
Sep 4, 2019

Conversation

ianswett
Copy link
Contributor

Fixes #2906

@ianswett ianswett added editorial An issue that does not affect the design of the protocol; does not require consensus. -recovery labels Jul 17, 2019
@martinthomson
Copy link
Member

When do you use parentheses?

@ianswett
Copy link
Contributor Author

It appears most conditionals have parentheses currently, except for 1177. Are you suggesting to add them there or something else?

@martinthomson
Copy link
Member

Pick one. Be consistent.

@ianswett
Copy link
Contributor Author

SG, done. I also fixed some missing ':'

// in flight and the endpoint is a server or has
// completed the handshake.
if (no ack-eliciting packets in flight &&
(endpoint is server or has 1-RTT keys)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

endpoint is server or has received hs ack or an ack of an 1-RTT packet (not a 1-RTT packet, this could be an ack of 0RTT)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, just add "has received HS ack" and we're good. There's a case where the server flight doesn't fit in a cwnd and the extra text may save us a crypto timeout.

draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
@janaiyengar
Copy link
Contributor

You'll need to rebase to get the changes from #2912 in here.

Copy link
Contributor

@janaiyengar janaiyengar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, module rebasing and working out the conflicts.

ianswett added a commit that referenced this pull request Aug 1, 2019
ianswett added a commit that referenced this pull request Aug 6, 2019
draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
if (no ack-eliciting packets in flight &&
(endpoint is server ||
has 1-RTT keys ||
has received Handshake ACK)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chatting about this at the editors meeting, @martinthomson pointed out that this isn't quite right. Here's my reformulation that I believe is the right condition:
"endpoint is server || until the handshake is confirmed || has received Handshake ACK"

if (no ack-eliciting packets in flight &&
(endpoint is server ||
has 1-RTT keys ||
has received Handshake ACK)):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The prose I would use here is:

An endpoint always keeps the timer running if it has an ack-eliciting packet that has not been acknowledged.

A client keeps the timer running during the handshake until it has confirmed that the server is no longer limited in how much it can send. The server needs to acknowledge a Handshake packet or a 1-RTT packet from the client to demonstrate this.

draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
ianswett and others added 4 commits September 3, 2019 18:43
if (no ack-eliciting packets in flight &&
(endpoint is server ||
has received Handshake ACK ||
has received 1-RTT ACK)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: if !(ack-eliciting packet in flight || (endpoint is client && has not received handshake ACK && has not received 1-RTT ACK))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a code reviewer, I'd request a method like PeerAwaitingAddressValidation() and say

if (no ack-eliciting packets in flight &&
!PeerAwaitingAddressValidation()):

ianswett and others added 2 commits September 3, 2019 19:04
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Copy link
Contributor

@janaiyengar janaiyengar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the change -- looks MUCH better now.

draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
draft-ietf-quic-recovery.md Outdated Show resolved Hide resolved
@martinthomson
Copy link
Member

martinthomson commented Sep 4, 2019

I shouldn't have commented on the changeset. Here's my alternative to Jana's:

# Whether the peer has provided evidence that their
# path validation is complete during the handshake.
PeerCompletedAddressValidation():
  # Assume that clients always validate the server implicitly.
  if endpoint is server:
    return true
  # Otherwise path validation is completed when a
  # protected packet is received, so look for an ACK.
  return has received Handshake ACK ||
           has received 1-RTT ACK
...

  if (no ack-eliciting packets in flight &&
      PeerCompletedAddressValidation()): 

@ianswett ianswett merged commit a51a418 into master Sep 4, 2019
@ianswett ianswett deleted the ianswett-fix-loss-detection branch September 4, 2019 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-recovery editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pseudo-code for SetLossDetectionTimer looks odd
4 participants