Date: Fri, 24 Jul 2020 15:10:43 -0700
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKZWVLXM56YRCZ6R25N5E46WHEVBNHHCPIKQDU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3957/review/455206964@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3957@github.com>
References: <quicwg/base-drafts/pull/3957@github.com>
Subject: Re: [quicwg/base-drafts] Don't retransmit lost packets that are acked
 later (#3957)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5f1b5c63ebd2_36193ff66e0cd95c6323f";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/zjC19Uzv0ke6ayu4jell4-jez-k>


----==_mimepart_5f1b5c63ebd2_36193ff66e0cd95c6323f
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@janaiyengar commented on this pull request.

I've rewritten the long sentence based on feedback

> @@ -3804,6 +3804,14 @@ 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

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3957#pullrequestreview-455206964
----==_mimepart_5f1b5c63ebd2_36193ff66e0cd95c6323f
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p></p>
<p><b>@janaiyengar</b> commented on this pull request.</p>

<p>I've rewritten the long sentence based on feedback</p><hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/3957#discussion_r460305843">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; @@ -3804,6 +3804,14 @@ 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
</pre>
<p>The PTO is the period of time that you expect the ack back by, not RTT.</p>
<p>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.</p>
<p>Either way, this is a suggestion, not a recommendation.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/3957#pullrequestreview-455206964">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJKZH2DJZJ7LBN5T5KYTR5IBGHANCNFSM4PGJ77DQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJKYMH7BXFUMQMFPL3XDR5IBGHA5CNFSM4PGJ77D2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGODMQ6QNA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/3957#pullrequestreview-455206964",
"url": "https://github.com/quicwg/base-drafts/pull/3957#pullrequestreview-455206964",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5f1b5c63ebd2_36193ff66e0cd95c6323f--