Re: [quicwg/base-drafts] Complicated Retransmission Corner Cases (#765)

Mike Bishop <notifications@github.com> Thu, 07 September 2017 17:25 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35833132F2D for <quic-issues@ietfa.amsl.com>; Thu, 7 Sep 2017 10:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.019
X-Spam-Level:
X-Spam-Status: No, score=-7.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSX-GoJiIdYN for <quic-issues@ietfa.amsl.com>; Thu, 7 Sep 2017 10:25:16 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FA71329F9 for <quic-issues@ietf.org>; Thu, 7 Sep 2017 10:25:16 -0700 (PDT)
Date: Thu, 07 Sep 2017 10:24:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1504805114; bh=nPJp9hpkIWzgJSsccASS25VXBc1zyESSXjl+DjNDseM=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WzXHDJm8UJTKzBOUU9+qjTzu7/XIUB22pG+7nDu1Bhg2JTN/2VV0InNorEFkfQeTh mamFSNInTnHI6Bio5m76F0gzwLVcj8AWxR3KVrsnb7vlUmchTczkuuyxosynK5Iff5 LK2n8Xi1tAyc0XwGkzZYYbfC4S5l3WbdzSribqEM=
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
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LTKVZWRruPvyQYzOK3YvWhmx-pQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Sep 2017 17:25:18 -0000

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