[quicwg/base-drafts] Crypto Retransmission Timeout interacts poorly with Congestion Control (#2886)

Marten Seemann <notifications@github.com> Tue, 09 July 2019 17:20 UTC

Date: Tue, 09 Jul 2019 10:20:44 -0700
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYMCDIWR3DAPULM2CN3GH7WZEVBNHHBXRIJFY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2886@github.com>
Subject: [quicwg/base-drafts] Crypto Retransmission Timeout interacts poorly with Congestion Control (#2886)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d24ccece0550_462c3fef4e0cd96044171f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/R6uU9v2VbFJLPvZVFt27t8rXDhg>

The crypto retransmission timeout works similar to the PTO timeout. On each timer expiration, you are supposed to send some data, and do an exponential backoff.
However, there's an important difference: PTO packets are not blocked by the congestion controller, whereas crypto retransmissions are. 

This can lead to a deadlock: Consider the case where the CFIN is lost, and the client sends all the available window of application data. When the crypto retransmission timer fires, the client would be supposed to retransmit the CFIN, but the congestion controller will not allow that. Furthermore, since the CFIN was lost, the server won't be able to read any of the 1-RTT packets, so cwnd will never be cleared.

-- 
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/2886

[quicwg/base-drafts] Crypto Retransmission Timeou… Marten Seemann
Re: [quicwg/base-drafts] Crypto Retransmission Ti… ianswett
Re: [quicwg/base-drafts] Crypto Retransmission Ti… ianswett