Date: Mon, 08 Apr 2019 18:08:49 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab0acd1ef9d63f9d82d64e6c11ee854e2b760143e492cf0000000118c3b2a192a169ce19787a10@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2568/481062758@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2568@github.com>
References: <quicwg/base-drafts/issues/2568@github.com>
Subject: Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples
 (#2568)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5cabf0a16ce0b_4ba83f90896d45bc59527f";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/8C4DhTys-tQ-bVyTpjZ9G-EPVwM>


----==_mimepart_5cabf0a16ce0b_4ba83f90896d45bc59527f
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

It might not be a lot of additional load, but a lot of additional complexity. For example, what happens if the peer never acks an ack-eliciting packet (either because it was actually lost, or as part of an attack)? You then have to somehow clear that packet from your history. If you use the normal loss detection mechanism for it, you have to be careful not to take any congestion controller action upon loss of that packet. You also don't want to set any timers based on non-ack-eliciting packets, etc.

I never suggested sending out-of-date information, that would indeed be a bad idea. There's just no need to send an ACK at all if largest_acked is not ack-eliciting, and I'm suggesting that we recommend (mandate?) that peers don't do it. They should just wait until they receive the next ack-eliciting packet.

-- 
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/2568#issuecomment-481062758
----==_mimepart_5cabf0a16ce0b_4ba83f90896d45bc59527f
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>It might not be a lot of additional load, but a lot of additional comp=
lexity. For example, what happens if the peer never acks an ack-eliciting=
 packet (either because it was actually lost, or as part of an attack)? Y=
ou then have to somehow clear that packet from your history. If you use t=
he normal loss detection mechanism for it, you have to be careful not to =
take any congestion controller action upon loss of that packet. You also =
don't want to set any timers based on non-ack-eliciting packets, etc.</p>=

<p>I never suggested sending out-of-date information, that would indeed b=
e a bad idea. There's just no need to send an ACK at all if largest_acked=
 is not ack-eliciting, and I'm suggesting that we recommend (mandate?) th=
at peers don't do it. They should just wait until they receive the next a=
ck-eliciting packet.</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/2568#issuecomment-481062758">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq91b=
FHY-jRRoIvqCnz9dkh5PTyviks5ve-ghgaJpZM4cT9U0">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq0NOo6a7Ye6YxebcVj1lW-h2=
ncjJks5ve-ghgaJpZM4cT9U0.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://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
marten-seemann in #2568: It might not be a lot of additional load, but a =
lot of additional complexity. For example, what happens if the peer never=
 acks an ack-eliciting packet (either because it was actually lost, or as=
 part of an attack)? You then have to somehow clear that packet from your=
 history. If you use the normal loss detection mechanism for it, you have=
 to be careful not to take any congestion controller action upon loss of =
that packet. You also don't want to set any timers based on non-ack-elici=
ting packets, etc.\r\n\r\nI never suggested sending out-of-date informati=
on, that would indeed be a bad idea. There's just no need to send an ACK =
at all if largest_acked is not ack-eliciting, and I'm suggesting that we =
recommend (mandate?) that peers don't do it. They should just wait until =
they receive the next ack-eliciting packet."}],"action":{"name":"View Iss=
ue","url":"https://github.com/quicwg/base-drafts/issues/2568#issuecomment=
-481062758"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2568#issuecomment=
-481062758",
"url": "https://github.com/quicwg/base-drafts/issues/2568#issuecomment-48=
1062758",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5cabf0a16ce0b_4ba83f90896d45bc59527f--