Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)

Christian Huitema <> Fri, 10 January 2020 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8C29120111 for <>; Fri, 10 Jan 2020 13:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gGcxWLHakpF4 for <>; Fri, 10 Jan 2020 13:36:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58E9912008C for <>; Fri, 10 Jan 2020 13:36:41 -0800 (PST)
Date: Fri, 10 Jan 2020 13:36:40 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578692200; bh=Ee4TWywbDKQWbf/rhpkzELG3iegbc5lrMqjUU/yAA64=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cM4zZKb2h0jLuX6oejvBDUTfKxrK8lV1Qtjfomk7YSLC1gOCoarcODBcJ2ZO2nh2B 0BD0A/M4MZ6x9rAKqx3fO/fm3aKGj39nAntRAAM3/kCYh6ysyNjb9hoPEqnVAwZ2wR i0FAKfurbY9gOaamwqHejBSMbta2+N2RXC/dXvqY=
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3332/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e18ee684de92_33a3ff3fd0cd95c10254f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 21:36:43 -0000

In the case of 1WD, I did consider coding that as a "prefix frame": encode a timestamp frame, and then encode the ACK. That could work too, but it requires making assumptions about the presence and order of frames in packets.

My current code is simple: go through the packet, parse and process the frames as they come. Each frame contains all the information required for processing it. In the case of the ACK frame, the processing involves passing information to the congestion control algorithm about packets acknowledged and RTT measured. I wanted to pass the information about one-way delay at the same time as the measured RTT. Having separate frames would require storing information in a "packet context". It is doable if I can assume that the Timestamp frame always precedes the ACK frame, but becomes fishy if the Timestamp frame follows the ACK.

Other problems appear if we start having a per packet context. Is it OK to have several timestamps in a packet? What about several ACK frames?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: