[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

Date: Sun, 27 Jan 2019 19:02:37 -0800
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/yyDbbebrFFuXQ0b88BoL06R0Arg>

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:
https://github.com/quicwg/base-drafts/issues/2374

[quicwg/base-drafts] Is it OK to place retransmit… Christian Huitema
Re: [quicwg/base-drafts] Is it OK to place retran… Marten Seemann
Re: [quicwg/base-drafts] Is it OK to place retran… Martin Thomson
Re: [quicwg/base-drafts] Is it OK to place retran… Martin Thomson