[quicwg/base-drafts] Is it OK to place retransmitted frames at the end of the queue? (#2374)

Christian Huitema <notifications@github.com> Mon, 28 January 2019 03:02 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5E784130F32 for <quic-issues@ietfa.amsl.com>; Sun, 27 Jan 2019 19:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SJwsPlvkg8h5 for <quic-issues@ietfa.amsl.com>; Sun, 27 Jan 2019 19:02:39 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC49130F09 for <quic-issues@ietf.org>; Sun, 27 Jan 2019 19:02:38 -0800 (PST)
Date: Sun, 27 Jan 2019 19:02:37 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548644557; bh=3b7TEJgBwvyhMPSshigj1P11PQRh0HvbPNvNi1+hjj8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=fNGAARq6xUNnd8e2uInhUpQw0b5eXFaHtMK+64KHe3G0yZPh7W/OZdDp3u4y3B/a/ PWiRNb34B6C9rV1rrm1PRG0vxshrT+4KpQEzCupUgArrARIu6z+hFB9jgN3EzKGGHR mmNPVS5JkmjPoFm1xuomQcwq9dNLhtexsAEj3xMw=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdd3e48e65729b74984afaf121f25648f6f69938492cf00000001186632cd92a169ce180ef4ec@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2374@github.com>
Subject: [quicwg/base-drafts] Is it OK to place retransmitted frames at the end of the queue? (#2374)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c4e70cd9daf8_45da3fc4578d45b8113704f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/yyDbbebrFFuXQ0b88BoL06R0Arg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 28 Jan 2019 03:02:41 -0000

We had an interesting interop issue yesterday between Picoquic and Quinn. Summary:

* we were testing NAT rebinding. A bunch of packets in transit were lost during the rebinding.

* the version of Quinn tested yesterday had already queued a bunch of data frames in the normal order. It noticed the losses, and placed the frames to be retransmitted "at the end of the queue".

* Picoquic delivers stream data in order to the app. It received the frames from Quinn and queued them, waiting for the retransmitted frames to fill the holes.

* Due to an unrelated bug, the transmission was really slow. Picoquic found that 10 seconds passed without making any progress, since no data was passed to the application, and closed the connection.

When discussing the issue, we raised a bunch of points:

1) Quinn was complying with the letter of the spec. The data frames were within the range allowed by MAX DATA and MAX STREAM DATA.

2) The combination of slow transmission and piling a lot of frames for reordering looks a lot like one of the "slow Loris" attacks, which explains why Picoquic complained.

3) Picoquic could have forced in order delivery by using small flow control windows. But then, small windows have a tendency to cause stalls, so I don't think that using flow control to solve logic issues should be recommended. (There were always enough buffers, so this is not an over commit issue.)

4) The issue only happened because Picoquic enforces "in sequence delivery" of stream data to the app. Quinn implements out of sequence delivery and lets the app reassemble the stream, so it was not a problem in internal tests. But then, the "stream" paradigm is initially designed to emulate a TCP connection, and there are a bunch of apps like video that really want to consume data in order.

This was fixed in Quinn by placing the retransmitted frames at the front of the queue. But it seems that there is no text in the spec asking implementations to do that. Should we add it?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: