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.

Sign up for GitHub

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

Don't retransmit lost packets that are acked later #3957

Merged
merged 8 commits into from Sep 1, 2020
Merged

Don't retransmit lost packets that are acked later #3957

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
d2658fd
retain info on lost packets
janaiyengar Jul 24, 2020
98c9d04
rewrite based on feedback
janaiyengar Jul 24, 2020
b0ed70a
smithing
janaiyengar Jul 24, 2020
e8db499
split up sentence
janaiyengar Jul 24, 2020
7abdc4b
wait for one PTO, not 3
janaiyengar Jul 27, 2020
e3999ba
sync recovery
janaiyengar Jul 27, 2020
89ff7fa
add ref to transport
janaiyengar Jul 28, 2020
2e534ad
Ian's comment
janaiyengar Jul 28, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 6 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3804,13 +3804,12 @@ number length, connection ID length, and path MTU. A receiver MUST accept
packets containing an outdated frame, such as a MAX_DATA frame carrying a
smaller maximum data than one found in an older packet.

When a sender declares a packet as lost and either retransmits the contained
frames or marks them for retransmission, the sender SHOULD avoid subsequent
retransmission of this information if it later receives an acknowledgement for
that packet. Doing so requires senders to retain information about packets after
they are declared lost. A sender can discard this information after a period of
time elapses, such as three times the PTO (Section 6.2 of {{QUIC-RECOVERY}}), or
on other events, such as reaching a memory limit.
A sender SHOULD avoid retransmitting information from packets that are
acknowledged, including those that are acknowledged after they are declared
lost. Doing so requires senders to retain information about packets after they
are declared lost. A sender can discard this information after a period of time
elapses, such as three times the PTO (Section 6.2 of {{QUIC-RECOVERY}}), or on
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
are declared lost. A sender can discard this information after a period of time
elapses, such as three times the PTO (Section 6.2 of {{QUIC-RECOVERY}}), or on
are declared lost. A sender can discard this information a period of time after the
packet is lost, such as after the Smoothed RTT (Section 5 of {{QUIC-RECOVERY}}), or on

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm happy to change it to 1 x PTO. I'd like the ack delay and the rttdev to be included in this suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

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

ack delay shouldn't need to be included, because the packet would be acknowledged immediately.

Including RTTVar implies that the network's reordering is sometimes as much 3*SRTT, but assuming the data was retransmitted, you'd expect the retransmission to be acknowledged in about 1 RTT, so suggesting you might need to wait longer seems odd to me.

other events, such as reaching a memory limit.

Upon detecting losses, a sender MUST take appropriate congestion control action.
The details of loss detection and congestion control are described in
Expand Down