Date: Thu, 07 Sep 2017 10:24:39 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab3f2c95ae775e902bb0acc4d13b169c3e495a5de992cf0000000115c942d792a169ce0f3e8128@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/327867668@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_59b180d76b776_5e523fe8e86ffc3c85442";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LTKVZWRruPvyQYzOK3YvWhmx-pQ>


----==_mimepart_59b180d76b776_5e523fe8e86ffc3c85442
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

When I was toying with this, I wound up tracking the delivery state of frames, not packets.  Each retransmittable frame was pending send, in-flight, or delivered.  Each packet that was outstanding was simply a list of frames that it contained, and changing a packet to lost or delivered was really walking its packets and updating *their* state.  Every time I generated a packet, I filled it as full as possible with frames that were pending send, with retransmissions being first.  And I agree, it's hairy.

You're right that you eventually need to get rid of the lists from old lost packets, but ought to maintain them for a little while in case the packet (or the ACK) is merely delayed.  However, there's no great harm in throwing it away too early (as you say, you'll get an ACK for a packet you no longer know anything about, and so accidentally resend a frame) and I'd say that can be left to the implementation.

-- 
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-327867668
----==_mimepart_59b180d76b776_5e523fe8e86ffc3c85442
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>When I was toying with this, I wound up tracking the delivery state of=
 frames, not packets.  Each retransmittable frame was pending send, in-fl=
ight, or delivered.  Each packet that was outstanding was simply a list o=
f frames that it contained, and changing a packet to lost or delivered wa=
s really walking its packets and updating <em>their</em> state.  Every ti=
me I generated a packet, I filled it as full as possible with frames that=
 were pending send, with retransmissions being first.  And I agree, it's =
hairy.</p>
<p>You're right that you eventually need to get rid of the lists from old=
 lost packets, but ought to maintain them for a little while in case the =
packet (or the ACK) is merely delayed.  However, there's no great harm in=
 throwing it away too early (as you say, you'll get an ACK for a packet y=
ou no longer know anything about, and so accidentally resend a frame) and=
 I'd say that can be left to the implementation.</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-327867668">view it on GitHub</a>, =
or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqwJOw=
IJmJLrb3wfGv0bE-e7ZWy4fks5sgCbXgaJpZM4PPBgM">mute the thread</a>.<img alt=
=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq9T=
sC0J488lApjLNISWavX1KDCY_ks5sgCbXgaJpZM4PPBgM.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-327867668"></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":"@MikeBishop in=
 #765: When I was toying with this, I wound up tracking the delivery stat=
e of frames, not packets.  Each retransmittable frame was pending send, i=
n-flight, or delivered.  Each packet that was outstanding was simply a li=
st of frames that it contained, and changing a packet to lost or delivere=
d was really walking its packets and updating *their* state.  Every time =
I generated a packet, I filled it as full as possible with frames that we=
re pending send, with retransmissions being first.  And I agree, it's hai=
ry.\r\n\r\nYou're right that you eventually need to get rid of the lists =
from old lost packets, but ought to maintain them for a little while in c=
ase the packet (or the ACK) is merely delayed.  However, there's no great=
 harm in throwing it away too early (as you say, you'll get an ACK for a =
packet you no longer know anything about, and so accidentally resend a fr=
ame) and I'd say that can be left to the implementation."}],"action":{"na=
me":"View Issue","url":"https://github.com/quicwg/base-drafts/issues/765#=
issuecomment-327867668"}}}</script>=

----==_mimepart_59b180d76b776_5e523fe8e86ffc3c85442--