[quicwg/base-drafts] Loss recovery draft section 4.3.1.1 clarification (#1983)

Nasif Ekiz <notifications@github.com> Thu, 08 November 2018 21:43 UTC

Date: Thu, 08 Nov 2018 13:43:11 -0800
From: Nasif Ekiz <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8f90bb53a8fbc5aa1bfd310f23ceffd4315c878a92cf0000000117fc6fef92a169ce1695ffc6@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1983@github.com>
Subject: [quicwg/base-drafts] Loss recovery draft section 4.3.1.1 clarification (#1983)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5be4adef7fa9c_2e423fd801ed45b847625"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/TC1cPgytJ2VJfxkhiYBpy-Fedag>

Section 4.3.1.1 of draft 16 says:
A Retry or Version Negotiation packet causes a client to send another
   Initial packet, effectively restarting the connection process.

Either packet indicates that the Initial was received but not
   processed.  Neither packet can be treated as an acknowledgment for
   the Initial, but they MAY be used to improve the RTT estimate.

Should we clear handshake_count when an Retry or Version Negotiation packet is received after Initial is sent (maybe multiple times)? Otherwise, the new Initial could be delayed extra if Initial is lost and needs retransmission. 

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

[quicwg/base-drafts] Loss recovery draft section … Nasif Ekiz
Re: [quicwg/base-drafts] Loss recovery draft sect… ianswett
Re: [quicwg/base-drafts] Loss recovery draft sect… janaiyengar