IETF Logo Mail Archive

Lost initial MAX_PUSH_ID is unfortunate

Ryan Hamilton <rch@google.com> Tue, 27 August 2019 22:47 UTC

Return-Path: <rch@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF52E120130 for <quic@ietfa.amsl.com>; Tue, 27 Aug 2019 15:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcLzywZSDEBX for <quic@ietfa.amsl.com>; Tue, 27 Aug 2019 15:47:53 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2575D12004D for <quic@ietf.org>; Tue, 27 Aug 2019 15:47:53 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id e16so431098wro.5 for <quic@ietf.org>; Tue, 27 Aug 2019 15:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yb9FfL9KQ1uhtr8goXMmBlD/HkKkXC+ZVrz8uf8sx+o=; b=oMnNFGXZHj3R9sN5NhLSNu5t38pmKZuu7WaJO+ak/6emtJnqw4/JgLsOjL30LTLzOe 3MA1DAhQHicRlh41/Hj408vBJjVp+vb6B+CXKFyCrk2bzyOugwVJ1amA4g12dozR5Wmp 2QW1tlgjVYCEc/mbX3n8sBS+rnDXJ8xgk4vQsTOUCXHYK7Z4+2xD+24JZXRNQFSqAN4w oTHz03QBN/W3sqLMOvf9Qk65czcLFLVj+1fFQ1AQ5MHbfC7esAXfHSJMXmuuj6dG0sgn 2iRcfV2N+IB8+yZem6lMqp9yeoFQ0RZsyKTDrluzYVnOwqkrHEWT+itjxKX+7PE1Bv66 fykA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yb9FfL9KQ1uhtr8goXMmBlD/HkKkXC+ZVrz8uf8sx+o=; b=NseB1Prqz0WPt8uDX+4DR8uOSmC9TtCn+/CANyu9xy6xBqZ14djHqxFC9JAW3V7/7x 0GG5MF777+CYbTmkrjhklyq6ARuTz31VYHjInQEPRpxHTsccMZQ1+sPKBD6qDSKgLiol zDy8PFCC/eafk97piJQjULB1Z0/pvYE6nm45lfnJIA0sywGISkBPx5ut4eNzT5FRIiuP 4tZUEpq6YCCNgfF0KJbZOXxeV+aKD2dXSmnIT2VEMmb6SJ+QojHlOqrmjPCuJ212RtxH pmbmtuz8PXlrSkE164Z2xxCy9zxa9TKw8/B/YQRwKDe1WJw/N6pXzXqyYiKhRd4kzNtY 3IZg==
X-Gm-Message-State: APjAAAXouetD0KLuWx3Q1p0v/U+cvC1hqd+GBb7HvCFDKF9gk5MRZJgu BIWpVW4BLVqbgzXlftA5Py1gWMbhdhs1tnzDot6lHWpD4Gc=
X-Google-Smtp-Source: APXvYqx928x89diKCrULS5cOVOk4hFr/PVXML5iT4PIa9+4guY7mT+Qu/0p282AEXrZmbam66qbni53kBUCnXdjyulc=
X-Received: by 2002:adf:afe7:: with SMTP id y39mr436980wrd.350.1566946070790; Tue, 27 Aug 2019 15:47:50 -0700 (PDT)
MIME-Version: 1.0
From: Ryan Hamilton <rch@google.com>
Date: Tue, 27 Aug 2019 15:47:38 -0700
Message-ID: <CAJ_4DfSE4_2GR5peGeRuWnixgdc9ucGiXtab=c0fXbqedFHsgA@mail.gmail.com>
Subject: Lost initial MAX_PUSH_ID is unfortunate
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eef7000591210fc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vmeO71v6RQP8kcX1TV97RI_IQ4I>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2019 22:47:55 -0000

Howdy Folks,

In some testing we've been doing, we realized that if the packet
containing the initial MAX_PUSH_ID frame is lost (or reordered until after
the first request) then the server is unable to push responses. This is a
bit unfortunate. We could, of course, bundle the MAX_PUSH_ID with all
packets that send a new request until the MAX_PUSH_ID is ACK'd. This feels
a tad inelegant and I wondered if there's any appetite for an alternative.

We've been talking about the prospect of putting SETTINGS into transport
params. If we did this, we could add a new setting for the initial max push
id value which would be guaranteed to be delivered before requests. This
seems like a much more elegant solution to the problem.

What do folks think?

Cheers,

Ryan

v2.23.0 | Report a Bug | By Email