Date: Thu, 13 Dec 2018 22:43:08 +0000 (UTC)
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab5d5267e9068aa37e85596aad69ee313f497222a092cf00000001182aa27c92a169ce174c8cc0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2168@github.com>
Subject: [quicwg/base-drafts] Verification of RTO no longer necessary (#2168)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c12e07c85675_66ab3fb8e22d45bc67978";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/wXw9lBdHgbyXQdGeyRhG87N7GrU>

----==_mimepart_5c12e07c85675_66ab3fb8e22d45bc67978
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

The changes to loss recovery in #1974 allow for some simplification in RTO response. The recovery draft says about an ACK after an RTO:
```
When an ACK is received that acknowledges only one or more packets sent on an RTO event, all unacknowledged packets with lower packet numbers MUST be marked as lost. If packets sent prior to the first RTO are acknowledged in the same ACK, the RTO is considered spurious and standard loss detection rules apply.
```
If the ACK acknowledges only packets sent after an RTO, everything sent earlier is marked lost. With time-threshold loss detection in #1974, that is exactly what standard loss detection will do. As a result, in both the conditions described in the text quoted above, standard loss detection does the right thing.

We can remove the two cases (remove OnRetransmissionTimeoutVerified) and always simply use standard loss detection when an ACK is received.


-- 
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/issues/2168
----==_mimepart_5c12e07c85675_66ab3fb8e22d45bc67978
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p>The changes to loss recovery in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="377799118" data-permission-text="Issue title is private" data-url="https://github.com/quicwg/base-drafts/issues/1974" data-hovercard-type="pull_request" data-hovercard-url="/quicwg/base-drafts/pull/1974/hovercard" href="https://github.com/quicwg/base-drafts/pull/1974">#1974</a> allow for some simplification in RTO response. The recovery draft says about an ACK after an RTO:</p>
<pre><code>When an ACK is received that acknowledges only one or more packets sent on an RTO event, all unacknowledged packets with lower packet numbers MUST be marked as lost. If packets sent prior to the first RTO are acknowledged in the same ACK, the RTO is considered spurious and standard loss detection rules apply.
</code></pre>
<p>If the ACK acknowledges only packets sent after an RTO, everything sent earlier is marked lost. With time-threshold loss detection in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="377799118" data-permission-text="Issue title is private" data-url="https://github.com/quicwg/base-drafts/issues/1974" data-hovercard-type="pull_request" data-hovercard-url="/quicwg/base-drafts/pull/1974/hovercard" href="https://github.com/quicwg/base-drafts/pull/1974">#1974</a>, that is exactly what standard loss detection will do. As a result, in both the conditions described in the text quoted above, standard loss detection does the right thing.</p>
<p>We can remove the two cases (remove OnRetransmissionTimeoutVerified) and always simply use standard loss detection when an ACK is received.</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/issues/2168">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkqxik0weDsVA4-9FXs7ijmX_o6g3qks5u4tf8gaJpZM4ZSkSf">mute the thread</a>.<img src="https://github.com/notifications/beacon/AWbkq28lXqhQwewDUWPNNVi8OIWI4obVks5u4tf8gaJpZM4ZSkSf.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Verification of RTO no longer necessary (#2168)"}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/issues/2168"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2168",
"url": "https://github.com/quicwg/base-drafts/issues/2168",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5c12e07c85675_66ab3fb8e22d45bc67978--