Re: max_ack_delay for handshake

Martin Duke <martin.h.duke@gmail.com> Tue, 09 July 2019 17:00 UTC

MIME-Version: 1.0
References: <CAM4esxTLWNnKbzZNYq3QyWZfxMtdHtp74XoKMjRtnVy91UGuPw@mail.gmail.com>
In-Reply-To: <CAM4esxTLWNnKbzZNYq3QyWZfxMtdHtp74XoKMjRtnVy91UGuPw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 09 Jul 2019 10:00:18 -0700
Message-ID: <CAM4esxQgzYaZp_MosB94kHEK_Tx4FO1bo1ykbP=KXimVnAwBVA@mail.gmail.com>
Subject: Re: max_ack_delay for handshake
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007c11da058d427f90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/G4DkdtDit4wnGLgzNKPxipPE_f4>
Precedence: list

Ah, I see now that Section 5.3 makes it clear that we must use a value of
zero. Never mind!

On Tue, Jul 9, 2019 at 9:59 AM Martin Duke <martin.h.duke@gmail.com> wrote:

> New to section 4.4 of quic-recovery;
>
> *For Initial and Handshake packets, a
>    max_ack_delay of 0 is used.*
>
>
> I see two possible meanings of this:
> 1) endpoints MUST not intentionally delay acks of Initial and Handshake
> packets;
> 2) In RTT calculation, endpoints should assume a peer max_ack_delay of
> zero.
>
> (2) is a little hairy because there is one RTT estimate, not a per-context
> one. But what is the intent here?
>

max_ack_delay for handshake Martin Duke
Re: max_ack_delay for handshake Martin Duke