Date: Tue, 02 Oct 2018 13:58:27 -0700
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab9d9400b0443859aeaaa7e1bae8568f418747f94c92cf0000000117cb9df392a169ce15d1d968@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1827/426427801@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1827@github.com>
References: <quicwg/base-drafts/issues/1827@github.com>
Subject: Re: [quicwg/base-drafts] PLPMTUD section claims that PADDING frames
 generate ACKs (#1827)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5bb3dbf311936_57ff3fe309ad45b82881a3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/oTcruYWurVmEmuQCOjAc9V0A-jA>


----==_mimepart_5bb3dbf311936_57ff3fe309ad45b82881a3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I think the 8.1 section is reasonably clear

> To avoid creating an indefinite feedback loop, an endpoint MUST NOT send an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet. The endpoint MUST acknowledge packets containing only ACK or PADDING frames in the next ACK frame that it sends.

but the next paragraph could be misread even if it is correct:

> While PADDING frames do not elicit an ACK frame from a receiver,

indeed it does not elicit ACK's, meaning that receiving PADDING does not trigger the peers urge to ACK incoming packets. Only when non-ACK, non-PADDING packets are received, will an ACK be transmitted (and possible during tail loss probe - not sure about that)

-- 
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/1827#issuecomment-426427801
----==_mimepart_5bb3dbf311936_57ff3fe309ad45b82881a3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I think the 8.1 section is reasonably clear</p>
<blockquote>
<p>To avoid creating an indefinite feedback loop, an endpoint MUST NOT se=
nd an ACK frame in response to a packet containing only ACK or PADDING fr=
ames, even if there are packet gaps which precede the received packet. Th=
e endpoint MUST acknowledge packets containing only ACK or PADDING frames=
 in the next ACK frame that it sends.</p>
</blockquote>
<p>but the next paragraph could be misread even if it is correct:</p>
<blockquote>
<p>While PADDING frames do not elicit an ACK frame from a receiver,</p>
</blockquote>
<p>indeed it does not elicit ACK's, meaning that receiving PADDING does n=
ot trigger the peers urge to ACK incoming packets. Only when non-ACK, non=
-PADDING packets are received, will an ACK be transmitted (and possible d=
uring tail loss probe - not sure about that)</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/1827#issuecomment-426427801">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq-aI=
0IWuNK1URx4XcdKzC_GfRgtMks5ug9NzgaJpZM4XE2AG">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq95zsRiVtFxs7oP5IlUqL1le=
zNS4ks5ug9NzgaJpZM4XE2AG.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"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":"http=
s://assets-cdn.github.com/images/email/message_cards/header.png","avatar_=
image_url":"https://assets-cdn.github.com/images/email/message_cards/avat=
ar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicw=
g/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mikk=
elfj in #1827: I think the 8.1 section is reasonably clear\r\n\r\n\u003e =
To avoid creating an indefinite feedback loop, an endpoint MUST NOT send =
an ACK frame in response to a packet containing only ACK or PADDING frame=
s, even if there are packet gaps which precede the received packet. The e=
ndpoint MUST acknowledge packets containing only ACK or PADDING frames in=
 the next ACK frame that it sends.\r\n\r\nbut the next paragraph could be=
 misread even if it is correct:\r\n\r\n\u003e While PADDING frames do not=
 elicit an ACK frame from a receiver,\r\n\r\nindeed it does not elicit AC=
K's, meaning that receiving PADDING does not trigger the peers urge to AC=
K incoming packets. Only when non-ACK, non-PADDING packets are received, =
will an ACK be transmitted (and possible during tail loss probe - not sur=
e about that)"}],"action":{"name":"View Issue","url":"https://github.com/=
quicwg/base-drafts/issues/1827#issuecomment-426427801"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/1827#issuecomment=
-426427801",
"url": "https://github.com/quicwg/base-drafts/issues/1827#issuecomment-42=
6427801",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [quicwg/base-drafts] PLPMTUD section claims that PADDING fr=
ames generate ACKs (#1827)",
"sections": [
{
"text": "",
"activityTitle": "**MikkelFJ**",
"activityImage": "https://assets-cdn.github.com/images/email/message_card=
s/avatar.png",
"activitySubtitle": "@mikkelfj",
"facts": [

]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \=
"quicwg/base-drafts\",\n\"issueId\": 1827,\n\"IssueComment\": \"{{IssueCo=
mment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"q=
uicwg/base-drafts\",\n\"issueId\": 1827\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/quicwg/base-drafts/issues/1827#issuecomment-42=
6427801"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 3871457=
34\n}"
}
],
"themeColor": "26292E"
}
]</script>=

----==_mimepart_5bb3dbf311936_57ff3fe309ad45b82881a3--