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

Jump to bottom

Immediate retransmission upon loss detection #3335

Closed
janaiyengar opened this issue Jan 13, 2020 · 1 comment · Fixed by #3443
Closed

Immediate retransmission upon loss detection #3335

janaiyengar opened this issue Jan 13, 2020 · 1 comment · Fixed by #3443
Assignees
@ianswett
Labels
-recovery design has-consensus
Projects
Late Stage Processing

Comments

@janaiyengar
Copy link
Contributor

@janaiyengar janaiyengar commented Jan 13, 2020

TCP recommends that a sender retransmit a packet immediately upon detecting the first loss in a recovery window (see Section 3.2, second para, of RFC 5681; Section 5 of RFC 6675 seems to follow the same idea). QUIC should at least allow the same. Not doing this can delay loss recovery by 0.5 RTT, which is not great.

This replaces #2604; this is a more correct description of the problem, which is a design issue.
@janaiyengar janaiyengar mentioned this issue Jan 13, 2020
Closed
@mnot mnot added this to Triage in Late Stage Processing Jan 15, 2020
@mnot mnot added the design label Jan 17, 2020
@mnot mnot moved this from Triage to Design Issues in Late Stage Processing Jan 17, 2020
@ianswett ianswett self-assigned this Feb 4, 2020
@larseggert
Copy link
Member

@larseggert larseggert commented Feb 5, 2020

Discussed in ZRH. Proposed resolution is to get a PR done.

ianswett added a commit that referenced this issue Feb 9, 2020
@ianswett
MAY send 1 packet entering recovery
ecb7a76 
Similar to TCP as described in Section 5 of RFC 6675

Fixes #3335
@ianswett ianswett mentioned this issue Feb 9, 2020
Merged
@ianswett ianswett added the proposal-ready label Feb 12, 2020
@project-bot project-bot bot moved this from Design Issues to Consensus Emerging in Late Stage Processing Feb 12, 2020
@LPardue LPardue moved this from Consensus Emerging to Consensus Call issued in Late Stage Processing Feb 19, 2020
@LPardue LPardue removed the proposal-ready label Feb 19, 2020
@LPardue LPardue added the call-issued label Feb 26, 2020
@LPardue LPardue added has-consensus and removed call-issued labels Mar 4, 2020
@project-bot project-bot bot moved this from Consensus Call issued to Consensus Declared in Late Stage Processing Mar 4, 2020
Late Stage Processing automation moved this from Consensus Declared to Text Incorporated Mar 5, 2020
@WesleyRosenblum WesleyRosenblum mentioned this issue Oct 5, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ianswett ianswett

Labels
-recovery design has-consensus
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

MAY send 1 packet entering recovery quicwg/base-drafts
5 participants
@mnot @larseggert @LPardue @janaiyengar @ianswett