Date: Tue, 15 Jan 2019 16:13:56 -0800
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abb7d960b1e87a4f3b397c0ffd7d3bb8ee3f922b0e92cf000000011856394492a169ce179f536f@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2303/c454601267@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2303@github.com>
References: <quicwg/base-drafts/pull/2303@github.com>
Subject: Re: [quicwg/base-drafts] One Retry/VN per UDP datagram (#2303)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c3e7744d41d7_62cb3ff4d40d45b8113540";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Rb-p9LVetKM5RdiFZimPVlJl-hI>


----==_mimepart_5c3e7744d41d7_62cb3ff4d40d45b8113540
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I think this PR addresses the amplification problem directly, by tying the number of response datagrams to the number of incoming datagrams, so I am in favor of this PR as a spec solution.

@marten-seemann : quic-go can still choose to drop datagrams with a large (> 3?) coalesced packets, which might help you (slightly). I agree with @kazuho also that since all coalesced packets are supposed to go to the same connection, the implementation would be better aligned if it were to pass the datagram along to the connection instead of the individual packets... but that's an impl choice, and it's certainly not the only way to do this.

-- 
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/2303#issuecomment-454601267
----==_mimepart_5c3e7744d41d7_62cb3ff4d40d45b8113540
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I think this PR addresses the amplification problem directly, by tying=
 the number of response datagrams to the number of incoming datagrams, so=
 I am in favor of this PR as a spec solution.</p>
<p><a class=3D"user-mention" data-hovercard-type=3D"user" data-hovercard-=
url=3D"/hovercards?user_id=3D1478487" data-octo-click=3D"hovercard-link-c=
lick" data-octo-dimensions=3D"link_type:self" href=3D"https://github.com/=
marten-seemann">@marten-seemann</a> : quic-go can still choose to drop da=
tagrams with a large (&gt; 3?) coalesced packets, which might help you (s=
lightly). I agree with <a class=3D"user-mention" data-hovercard-type=3D"u=
ser" data-hovercard-url=3D"/hovercards?user_id=3D41567" data-octo-click=3D=
"hovercard-link-click" data-octo-dimensions=3D"link_type:self" href=3D"ht=
tps://github.com/kazuho">@kazuho</a> also that since all coalesced packet=
s are supposed to go to the same connection, the implementation would be =
better aligned if it were to pass the datagram along to the connection in=
stead of the individual packets... but that's an impl choice, and it's ce=
rtainly not the only way to do this.</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/pull/2303#issuecomment-454601267">view it on GitHub</a>, o=
r <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq2BmtW=
KSK-T0MSUxAZzLv5o6J9oGks5vDm7EgaJpZM4Zyty6">mute the thread</a>.<img src=3D=
"https://github.com/notifications/beacon/AWbkq1bR4g32BkQCfGvRQBwgyqoRiNpd=
ks5vDm7EgaJpZM4Zyty6.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":"@=
janaiyengar in #2303: I think this PR addresses the amplification problem=
 directly, by tying the number of response datagrams to the number of inc=
oming datagrams, so I am in favor of this PR as a spec solution.\r\n\r\n@=
marten-seemann : quic-go can still choose to drop datagrams with a large =
(\u003e 3?) coalesced packets, which might help you (slightly). I agree w=
ith @kazuho also that since all coalesced packets are supposed to go to t=
he same connection, the implementation would be better aligned if it were=
 to pass the datagram along to the connection instead of the individual p=
ackets... but that's an impl choice, and it's certainly not the only way =
to do this."}],"action":{"name":"View Pull Request","url":"https://github=
.com/quicwg/base-drafts/pull/2303#issuecomment-454601267"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2303#issuecomment-4=
54601267",
"url": "https://github.com/quicwg/base-drafts/pull/2303#issuecomment-4546=
01267",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c3e7744d41d7_62cb3ff4d40d45b8113540--