Re: HTTP Alternative Services Best Practices?

Daniel Stenberg <daniel@haxx.se> Tue, 17 December 2019 19:48 UTC

Return-Path: <daniel@haxx.se>
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 1944D120D26 for <quic@ietfa.amsl.com>; Tue, 17 Dec 2019 11:48:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mCn2nxIdHC7D for <quic@ietfa.amsl.com>; Tue, 17 Dec 2019 11:48:34 -0800 (PST)
Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78990120D1D for <quic@ietf.org>; Tue, 17 Dec 2019 11:48:34 -0800 (PST)
Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id xBHJmSwi006735 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 20:48:28 +0100
Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id xBHJmS5j006730; Tue, 17 Dec 2019 20:48:28 +0100
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Tue, 17 Dec 2019 20:48:28 +0100
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
cc: QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTP Alternative Services Best Practices?
In-Reply-To: <CALGR9oaCNigDAZP=ue-sORxCJFzkVynhaJszjjY_ohN56ewy8g@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1912172040300.23555@tvnag.unkk.fr>
References: <CALGR9oaCNigDAZP=ue-sORxCJFzkVynhaJszjjY_ohN56ewy8g@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/VUBw_sUGQwED1nvOghlRhmAM88s>
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, 17 Dec 2019 19:48:38 -0000

On Mon, 16 Dec 2019, Lucas Pardue wrote:

> invokes default values for parameters, "ma" is fresh for 24 hours and 
> "persist" is false (i.e. clear alternative cache on network changes). One 
> could imagine how this could cause bursts of activity at regular periods, or 
> cascades due to end-user local conditions such as flocking or hopping.

The "persist" thing gives me, as author of the alt-svc handling in curl, a 
small headache too. Let me elaborate:

curl is a command line tool that you typically fire off one or two requests 
with now and then again at a later point.

When curl saves/caches the alt-svc information because we want to take 
advantage of for example HTTP/3 at subsequent invokes, we just have no idea if 
the network changed or not in between the invokes. Figuring out if a network 
chanfes is hard enough when you catch it in run-time (I wrote a lot of such 
code for Firefox), but even worse when you do occasional runs with potentially 
long intervals.

I'm struggling to come up with a decent way to deal with this. Right now I 
just ignore the persistent parameter completely, but I realize that's just 
waiting for a case when it will hurt me. I'm leaning towards either always 
consider the network as changed, or to add some very rudimentary checks that 
for example consider it the same if the source IP is still the same or 
something...

(the curl alt-svc implementation is still marked "experimental" and as such 
isn't actually used very widely yet)

-- 

  / daniel.haxx.se