Date: Wed, 06 Sep 2017 17:04:47 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abae75d55b94600aa9ca9b97ad0295cc7fce4eb4ae92cf0000000115c84f1f92a169ce0f3e8128@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/765/327644998@github.com>
In-Reply-To: <quicwg/base-drafts/issues/765@github.com>
References: <quicwg/base-drafts/issues/765@github.com>
Subject: Re: [quicwg/base-drafts] Complicated Retransmission Corner Cases
 (#765)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_59b08d1fc06fc_58863ff9ff2cbc3811137e";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/x-Z6rlFAlPjXz3NQQhXRW9D_wOw>


----==_mimepart_59b08d1fc06fc_58863ff9ff2cbc3811137e
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@martinduke, This is where I think that I'd like your opinion on #743.  Is this a duplicate of that issue?

The model that I prefer is to hold the data in one place, but maintain a separate structure that tracks where various pieces of that data were sent.  Having just reviewed code for DTLS that does exactly that, and having then worked on improving the retransmission logic, I can be fairly confident in saying that it's a much better strategy for managing this sort of thing.

The idea that you can just copy data from the last/lost packet to the next one is rarely true.  Enough so that attempting to do so is wasteful.

-- 
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/765#issuecomment-327644998
----==_mimepart_59b08d1fc06fc_58863ff9ff2cbc3811137e
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><a href=3D"https://github.com/martinduke" class=3D"user-mention">@mart=
induke</a>, This is where I think that I'd like your opinion on <a href=3D=
"https://github.com/quicwg/base-drafts/issues/743" class=3D"issue-link js=
-issue-link" data-url=3D"https://github.com/quicwg/base-drafts/issues/743=
" data-id=3D"251813241" data-error-text=3D"Failed to load issue title" da=
ta-permission-text=3D"Issue title is private">#743</a>.  Is this a duplic=
ate of that issue?</p>
<p>The model that I prefer is to hold the data in one place, but maintain=
 a separate structure that tracks where various pieces of that data were =
sent.  Having just reviewed code for DTLS that does exactly that, and hav=
ing then worked on improving the retransmission logic, I can be fairly co=
nfident in saying that it's a much better strategy for managing this sort=
 of thing.</p>
<p>The idea that you can just copy data from the last/lost packet to the =
next one is rarely true.  Enough so that attempting to do so is wasteful.=
</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/765#issuecomment-327644998">view it on GitHub</a>, =
or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxfPJ=
fnAwH5G3QZt0jssZw1cxNEtks5sfzMfgaJpZM4PPBgM">mute the thread</a>.<img alt=
=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkqzA=
INV0x4D4fcRfAHwXFYM_NzFf9ks5sfzMfgaJpZM4PPBgM.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewActi=
on">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/is=
sues/765#issuecomment-327644998"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></me=
ta>
</div>

<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://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6=
-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubuserconte=
nt.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","=
action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-dr=
afts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@martinthomson=
 in #765: @martinduke, This is where I think that I'd like your opinion o=
n #743.  Is this a duplicate of that issue?\r\n\r\nThe model that I prefe=
r is to hold the data in one place, but maintain a separate structure tha=
t tracks where various pieces of that data were sent.  Having just review=
ed code for DTLS that does exactly that, and having then worked on improv=
ing the retransmission logic, I can be fairly confident in saying that it=
's a much better strategy for managing this sort of thing.\r\n\r\nThe ide=
a that you can just copy data from the last/lost packet to the next one i=
s rarely true.  Enough so that attempting to do so is wasteful."}],"actio=
n":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/issu=
es/765#issuecomment-327644998"}}}</script>=

----==_mimepart_59b08d1fc06fc_58863ff9ff2cbc3811137e--