Hi all, We are going to extend this adoption call until 2025-05-05 anywhere on earth, with the current intention of adopting the document given the changes Ian has described and which are reflected in the latest version and can be viewed incrementally on the datatracker or the merged PR[1].
Best, Matt & Lucas QUIC WG Chairs [1] https://github.com/wcsmith/draft-quic-receive-ts/pull/8 On Tue, Apr 22, 2025 at 1:06 PM Ian Swett <[email protected]> wrote: > I just published a new draft with support for out of order packets and it > defines no new frame types. > https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/ > > Thanks, Ian > > On Thu, Apr 17, 2025 at 4:09 AM Kazuho Oku <[email protected]> wrote: > >> >> >> 2025年4月17日(木) 1:00 Ian Swett <[email protected]>: >> >>> Coming from an author's perspective, I'm happy to remove the extended >>> ACK portion and ship a new draft version before adoption. >>> >>> I wrote a PR that does that and always includes the timestamp section at >>> the end of ACK frames, for example: >>> https://github.com/wcsmith/draft-quic-receive-ts/pull/8 >>> >> >> I support adoption, and I also think that this PR is in the right >> direction. >> >> Though I kind of wonder if we could agree on how to annotate ACK packets. >> At the moment, Multipath QUIC adds a path identifier and uses a different >> frame type. This pull request adds a new field for acks, reusing the >> original frame type. >> >> I think people have argued that we do not need to develop an encoding >> scheme that allows extensions add new fields to the ACK frame. I fully >> agree with that. >> >> But at the same time, I wonder if extensions could agree on one way of >> annotating ACKs rather than trying to define their own ways. >> >> >>> >>> Thanks, Ian >>> >>> On Tue, Apr 15, 2025 at 5:41 AM Mirja Kuehlewind <mirja.kuehlewind= >>> [email protected]> wrote: >>> >>>> Hi chairs, hi all, >>>> >>>> >>>> >>>> we had some discussion on list and in the meeting suggesting to rather >>>> use a new frame than using an extended ACK. I generally support this work >>>> but I would actually rather want to adopt a document that reflects this >>>> change. Or what’s the plan here? >>>> >>>> >>>> >>>> Mirja >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From: *Lucas Pardue <[email protected]> >>>> *Date: *Monday, 14. April 2025 at 21:01 >>>> *To: *"[email protected]" <[email protected]> >>>> *Cc: *QUIC WG Chairs <[email protected]> >>>> *Subject: *Re: Adoption call: QUIC Extended Acknowledgement for >>>> Reporting Packet Receive Timestamps >>>> >>>> >>>> >>>> Reminder: the call for adoption closes at the end of this week >>>> >>>> >>>> >>>> On Thu, Apr 3, 2025, at 20:58, Lucas Pardue wrote: >>>> >>>> Hi folks, >>>> >>>> >>>> >>>> At IETF 122 we discussed QUIC Extended Acknowledgement for Reporting >>>> Packet Receive Timestamps [1]. The sense of the room was that there was >>>> support for the QUIC WG adopting work on ACKs with timestamps. >>>> >>>> >>>> >>>> The email launches a formal adoption call >>>> for draft-smith-quic-receive-ts-01 as the basis of this work. The call will >>>> run until end of day 2025-04-18 anywhere on earth [2] >>>> >>>> >>>> >>>> Please post comments in favor or against as replies to this thread. >>>> >>>> >>>> >>>> Cheers >>>> >>>> Lucas & Matt >>>> >>>> QUIC WG Chairs >>>> >>>> >>>> >>>> [1] - https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/ >>>> >>>> [2] - https://en.wikipedia.org/wiki/Anywhere_on_Earth >>>> >>>> >>>> >>>> >> >> -- >> Kazuho Oku >> >
