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

From: Christian Huitema <[email-masked]>
Date: Sun, 27 Jan 2019 19:02:37 -0800

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

---

From: Marten Seemann <[email-masked]>
Date: Sun, 27 Jan 2019 19:09:54 -0800

The spec already [says](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#retransmission-of-information)

> Endpoints SHOULD prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise (see Section 2.3).

It seems like Quinn is ignoring this advice.

> Picoquic found that 10 seconds passed without making any progress, since no data was passed to the application, and closed the connection.

I think this rule is part of the problem. If there's still data arriving, there's no need to close the connection.

-- 
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#issuecomment-457986226

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 21:11:12 -0800

Thanks for finding that @marten-seemann.

-- 
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#issuecomment-458000836

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 21:11:12 -0800

Closed #2374.

-- 
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#event-2099814318