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

janaiyengar · 2020-07-24T02:57:55Z

Closes #3956.

martinthomson

This is useful information and in the right place. Thanks.

I have a small suggestion, but I'm OK with the original phrasing.

martinthomson · 2020-07-24T05:34:07Z

draft-ietf-quic-transport.md

+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.


Suggested change

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.

Acknowledgments can be received after a sender declares a packet as lost. A

sender SHOULD avoid sending information again after receiving a late

acknowledgment. Doing so requires senders to retain information about packets

for some time 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.

I think I like @martinthomson's idea of splitting the sentence into two. The only thing I might prefer is changing the last part of the second sentence "after receiving a late acknowledgement" to something like "after receiving such an acknowledgement" to make it clearer, but anyways it's good.

How about "..after receiving an acknowledgement for a previously lost packet." I think late acknowledgement is potentially confusing.

And how about starting with "A packet can be acknowledged after being declared lost." instead of "Acknowledgements can be received after a sender declares a packet as lost."

ianswett

Thanks for adding this, some more comments.

ianswett · 2020-07-24T18:39:17Z

draft-ietf-quic-transport.md

+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


3*PTO is really long in this case, and it can consume a fair bit of memory depending upon implementation details. I'd suggest an ~RTT, since by that point you're expecting the acknowledgement of the retransmitted data.

The PTO is the period of time that you expect the ack back by, not RTT.

It's true that 3 PTO is a conservative value, but, it's only on lost packets. When that's the uncommon case, it won't consume a lot of memory. When it's the common case, you're not sending a lot of packets anymore because the sender is in congestion, so it shouldn't also cause memory exhaustion.

Either way, this is a suggestion, not a recommendation.

Generally speaking, I tend to think that 3*PTO is fine, and that is because the size of a sentmap entry (i.e., the amount of memory required to remember what was sent in a packet) is only a tiny fraction of the MTU.

If your send buffer is capable of retaining X packets amount of data, then it does not matter if you use one tiny fraction, two tiny fractions, or three, for sentmap.

All that said, I agree that it might sound a bit frightening, it does not need to be as long as 3PTO, and therefore my view is that this is a trade-off issue between simplicity (i.e. reusing 3PTO timer) vs. less frightening.

ianswett · 2020-07-24T18:42:37Z

draft-ietf-quic-transport.md

+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.


How about "..after receiving an acknowledgement for a previously lost packet." I think late acknowledgement is potentially confusing.

ianswett · 2020-07-24T18:44:40Z

draft-ietf-quic-transport.md

+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.


And how about starting with "A packet can be acknowledged after being declared lost." instead of "Acknowledgements can be received after a sender declares a packet as lost."

janaiyengar

I've rewritten the long sentence based on feedback

janaiyengar · 2020-07-24T21:58:50Z

draft-ietf-quic-transport.md

+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


The PTO is the period of time that you expect the ack back by, not RTT.

It's true that 3 PTO is a conservative value, but, it's only on lost packets. When that's the uncommon case, it won't consume a lot of memory. When it's the common case, you're not sending a lot of packets anymore because the sender is in congestion, so it shouldn't also cause memory exhaustion.

Either way, this is a suggestion, not a recommendation.

ianswett

I still think 3*PTO is far too long. This time period exists to ensure there's sufficient tolerance of reordering, not to wait for multiple PTOs to fire.

ianswett · 2020-07-27T14:42:20Z

draft-ietf-quic-transport.md

+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


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

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.

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.

janaiyengar · 2020-07-27T23:08:57Z

Added changes to recovery as well.

ianswett

Some suggestions, but I think we're close.

ianswett · 2020-07-28T00:55:45Z

draft-ietf-quic-recovery.md

-time comparable to the maximum expected packet reordering, such as 1 RTT.
-This allows for detection of spurious retransmissions.
+After a packet is declared lost, the endpoint can still maintain state for it
+for an amount of time, such as a PTO, to allow for packet reordering. This


Suggested change

for an amount of time, such as a PTO, to allow for packet reordering. This

for an amount of time to allow for packet reordering. This

ianswett · 2020-07-28T01:03:34Z

draft-ietf-quic-transport.md

+acknowledged. This includes packets that are acknowledged after being 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 a PTO (Section 6.2 of {{QUIC-RECOVERY}}), or on other events,
+such as reaching a memory limit.


Suggested change

acknowledged. This includes packets that are acknowledged after being 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 a PTO (Section 6.2 of {{QUIC-RECOVERY}}), or on other events,

such as reaching a memory limit.

acknowledged. Doing this for packets acknowledged after they are declared

lost requires retaining state for lost packets. A sender can discard lost packet state

after the expected maximum packet reordering elapses, such as after PTO

(Section 6.2 of {{QUIC-RECOVERY}}), or on other events, such as reaching a packet limit.

I will take the compression, but we don't need to say "expected maximum packet reordering", since that's not a well-defined term. I'll spell in out in other words.

I'm trying to wordsmith this compression, but it's a bit difficult. The text is a bit verbose, but I think it is clearer. Unless you think there's a substantive difference, I'd prefer the existing text for clarity.

The expanded form is fine.

The intent was to both make it clearer and talk about the goal of waiting for a reordering period. I find the existing text a bit unclear, which is why I put the first two sentences together.

Ok, added some rationale.

ianswett

I think what you're saying is fine, but another attempt at an editorial suggstion.

draft-ietf-quic-transport.md

martinthomson

Let's not thrash too much on this one.

retain info on lost packets

d2658fd

janaiyengar requested review from kazuho and martinthomson July 24, 2020 02:58

martinthomson approved these changes Jul 24, 2020

View reviewed changes

kazuho approved these changes Jul 24, 2020

View reviewed changes

ianswett reviewed Jul 24, 2020

View reviewed changes

rewrite based on feedback

98c9d04

janaiyengar commented Jul 24, 2020

View reviewed changes

janaiyengar added 2 commits July 24, 2020 15:13

smithing

b0ed70a

split up sentence

e8db499

kazuho approved these changes Jul 24, 2020

View reviewed changes

janaiyengar mentioned this pull request Jul 24, 2020

Suggest endpoints may recognize acks after loss is declared #3956

Closed

ianswett reviewed Jul 27, 2020

View reviewed changes

ianswett added the -transport label Jul 27, 2020

wait for one PTO, not 3

7abdc4b

kazuho approved these changes Jul 27, 2020

View reviewed changes

sync recovery

e3999ba

ianswett reviewed Jul 28, 2020

View reviewed changes

add ref to transport

89ff7fa

ianswett approved these changes Jul 28, 2020

View reviewed changes

Ian's comment

2e534ad

ianswett approved these changes Jul 29, 2020

View reviewed changes

draft-ietf-quic-transport.md Show resolved Hide resolved

martinthomson approved these changes Jul 29, 2020

View reviewed changes

ianswett added the design An issue that affects the design of the protocol; resolution requires consensus. label Aug 4, 2020

huitema approved these changes Aug 21, 2020

View reviewed changes

janaiyengar merged commit c5923f5 into master Sep 1, 2020

janaiyengar deleted the jri/late-ack branch September 1, 2020 19:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

janaiyengar commented Jul 24, 2020

martinthomson left a comment

martinthomson Jul 24, 2020

kazuho Jul 24, 2020 •

edited

ianswett Jul 24, 2020

ianswett Jul 24, 2020

ianswett left a comment

ianswett Jul 24, 2020

janaiyengar Jul 24, 2020

kazuho Jul 24, 2020

ianswett Jul 24, 2020

ianswett Jul 24, 2020

janaiyengar left a comment

janaiyengar Jul 24, 2020

ianswett left a comment

ianswett Jul 27, 2020

janaiyengar Jul 27, 2020

ianswett Jul 27, 2020

janaiyengar commented Jul 27, 2020

ianswett left a comment

ianswett Jul 28, 2020

ianswett Jul 28, 2020 •

edited

janaiyengar Jul 28, 2020

janaiyengar Jul 28, 2020

martinthomson Jul 28, 2020

ianswett Jul 28, 2020

janaiyengar Jul 28, 2020

ianswett left a comment

martinthomson left a comment

		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

	for an amount of time, such as a PTO, to allow for packet reordering. This
	for an amount of time to allow for packet reordering. This

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

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

Conversation

janaiyengar commented Jul 24, 2020

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kazuho Jul 24, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar commented Jul 27, 2020

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett Jul 28, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

kazuho Jul 24, 2020 •

edited

ianswett Jul 28, 2020 •

edited