Re: New Draft: draft-ohanlon-transport-info-header

Patrick McManus <mcmanus@ducksong.com> Mon, 25 November 2019 15:25 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9025120127 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Nov 2019 07:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=mu13NQua; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=C2x6LWDj
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 TERNQCfm4RNB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 25 Nov 2019 07:25:39 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 1A5DF12004D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 25 Nov 2019 07:25:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iZGCd-0002Tr-Qs for ietf-http-wg-dist@listhub.w3.org; Mon, 25 Nov 2019 15:23:03 +0000
Resent-Date: Mon, 25 Nov 2019 15:23:03 +0000
Resent-Message-Id: <E1iZGCd-0002Tr-Qs@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mcmanus@ducksong.com>) id 1iZGCa-0002T6-Lv for ietf-http-wg@listhub.w3.org; Mon, 25 Nov 2019 15:23:00 +0000
Received: from outbound2r.ore.mailhop.org ([54.200.129.228]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mcmanus@ducksong.com>) id 1iZGCY-0001WW-UI for ietf-http-wg@w3.org; Mon, 25 Nov 2019 15:23:00 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1574695377; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=sWw9Q+19QCDuZtXCWeqPeFND96uD2CKJoiVcFGDjUxnSISBvRThyuqoLFHdmDlp1g0n07+EelG1RC B3+1wb3c9UWm3Yh6ZabhEsXtEY5cppi0Nhwi6+n72+ZYmJlWRLqeO18Gfa1qoxapANo4lZ8JpCipyW WF8JsPPdoueAG4kxOPvz0Lp6EqkLaz79rfirJ9ZQcl9SmYhev0Ou4otnGYzKjBMRbjVmEAgx+oplCN /0u1kYFOuGxHgGcoIHGq5e44sNBjwgb9LW59pMVaYFEh0dVZxE8zCOaEOhwMPw9JJFZYKISaYjafpi Cef38N8Yh6ifLUh+lqWVdRIt8GNXpiQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=VxHbeVNt7WuEgfmiMF+78uGVUNB02FOwe3HinorIovs=; b=A1Iyi99GIDPVQTPuCXpZLoW6uV/x1byvFLf5xLztB3zdGHMWiJhWHr9eNKNyXbzO7FXtxXmoHxizS JnkSyaLDsYJ0asMd/VstfTvHpScPu7y0tQW75JN8Q4nIx9IBknFQTAzqky3rpsC/rLPWihGw/T1rCS uk4AyGwDTtac+UGAm8O0NDO+cGfh6Ofv+p9s4kIaczumYZbh2xGhW0Hj9gtE7r7kEUp7wHsOArBs23 j5ORv8j+856Nh7z/xCB1kUGiH5M1WqtSB+3fTBOHbt5LVOiRxELrKiXTEiJvM7giDIy7c0l/9aeEWW CsE9vRJcbO76mAiwbtL3CfL1CNATDAw==
ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.178; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=VxHbeVNt7WuEgfmiMF+78uGVUNB02FOwe3HinorIovs=; b=mu13NQuaFzu0pyMmOdPxgI6NLrhzf3YY0hxD3gXVKSes9OPKwQNancMfqEMq8qsfGby5fJFo8JnNq mJUuLsvpWy76WGeEXx6muIPYu2PXE8mGsOsvuQNCAQ0rRPYZQksT1mmXiR4d8W/mPlqUwPpXYcIiff oHHzUvqbe7OuJeHY=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=VxHbeVNt7WuEgfmiMF+78uGVUNB02FOwe3HinorIovs=; b=C2x6LWDjcYIdHzuCc5jrbc6Hzy9eEbQ71Zb+cadREsfYECax+eBHaB7Z6XG1XlsjM4pLQgaSR8F3p 6SK1PnU5yKXRn6GNtxrkLRPoXHTb6+Lcm3a44AUTNyVfjVLQHKqRnke/qzPIx5vczzii6rOGCj4dWq 95EzELcIr07rjg2APufkpOoza1S3qAaY/DacyoIxC5qqk1sp5nsoBbj2fawNMK0hXvfRW8Iex6fHrl ubP2PZo/KL2ycSiI07dkRevzncBKpbODUw5xssFwR0196xgF/mOpimcBMmJSmCynM/2osy933Y5g8P 5ZsfMPfE9V74+PN/IfSnEBJ8ob9bq3w==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: 739e694e-0f97-11ea-829e-79a40d15cccd
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.167.178
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-oi1-f178.google.com (unknown [209.85.167.178]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 739e694e-0f97-11ea-829e-79a40d15cccd; Mon, 25 Nov 2019 15:22:55 +0000 (UTC)
Received: by mail-oi1-f178.google.com with SMTP id l202so13464032oig.1 for <ietf-http-wg@w3.org>; Mon, 25 Nov 2019 07:22:54 -0800 (PST)
X-Gm-Message-State: APjAAAVj3mZGRVSRrIPFvtMLcApqaXmi1wV7KFAyI4OdLolfQ+cBsiTb 25q9Kwa1reNOk08NWHZfLaymwov/+6qp9JMpOGE=
X-Google-Smtp-Source: APXvYqz/C+agiQDYM7qGI+riw2wo/vugkk9Evwi9HdwPk5eKNTO5ppVhkxiG5iI5YvgR/tgXwEsLOaACdrNJINlWbFk=
X-Received: by 2002:a54:4181:: with SMTP id 1mr23789975oiy.58.1574695374055; Mon, 25 Nov 2019 07:22:54 -0800 (PST)
MIME-Version: 1.0
References: <CAFWWCs4jSRbrK_-5mxM8w4YexYNKRuwGGJSK4iNrhr4en2Q=_w@mail.gmail.com> <CALGR9ob+EgQwC=VK80PPRWxABxi3AeLUpGXk=wzBK57H0OUzJw@mail.gmail.com> <CAFWWCs5u=qAjmhPek17YqN=AmVJgyCXEVkfP2RsQ5uM-DBZc0A@mail.gmail.com> <CAOdDvNrKSPwxNPDYW_0rqc78Zu4NJW9E49qGFt+nv7v3cUgTXg@mail.gmail.com> <CAFWWCs7XqVjOcNyt75P7enHXkAV3WzM8TDZLmUUaiDHFdT3QQQ@mail.gmail.com>
In-Reply-To: <CAFWWCs7XqVjOcNyt75P7enHXkAV3WzM8TDZLmUUaiDHFdT3QQQ@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 25 Nov 2019 10:22:43 -0500
X-Gmail-Original-Message-ID: <CAOdDvNo2dC77aQJif_351SR70J=judm+eKupm64=fSCY8212PA@mail.gmail.com>
Message-ID: <CAOdDvNo2dC77aQJif_351SR70J=judm+eKupm64=fSCY8212PA@mail.gmail.com>
To: Piers O'Hanlon <p.ohanlon@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000666e4705982d56c7"
Received-SPF: permerror client-ip=54.200.129.228; envelope-from=mcmanus@ducksong.com; helo=outbound2r.ore.mailhop.org
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iZGCY-0001WW-UI c893733f06219c6e5bd5fe9a5b9419f0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Draft: draft-ohanlon-transport-info-header
Archived-At: <https://www.w3.org/mid/CAOdDvNo2dC77aQJif_351SR70J=judm+eKupm64=fSCY8212PA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37189
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

A value like CWND is connection based - it is a side channel for all of the
transactions on the connection that is fed back through an http response
header on one particular transaction. These transactions don't necessarily
share the same origin (or the same auth properties).

On Mon, Nov 25, 2019 at 7:19 AM Piers O'Hanlon <p.ohanlon@gmail.com> wrote:

> Hi Patrick,
>
> Thanks for your feedback.
>
> I'm assuming most cross-origin issues should be dealt with by CORS but
> were you concerned with that suggestion that the header could be
> contained in an OPTIONS response? I can see that since such a response
> is not subject to CORS - such as in a CORS pre-flight request - then
> we could drop that as an approach and just keep to using HEAD requests
> as a mechanism to obtain the Transport-Info.
>
> Let me know what if that doesn't address your issue or if you have any
> other concerns.
>
> Piers
>
>
> On Fri, 22 Nov 2019 at 21:41, Patrick McManus <mcmanus@ducksong.com>
> wrote:
> >
> > To the extent that this leaks information across origins to js its
> probably a problem too.
> >
> > On Fri, Nov 22, 2019 at 8:58 PM Piers O'Hanlon <p.ohanlon@gmail.com>
> wrote:
> >>
> >> Hi Lucas,
> >>
> >> Thanks for bring that up - as you say Nginx's default for
> >> http2_max_requests is 1000, although it can be changed (and appears to
> >> be done so for RPC applications). I'm not sure how many other server
> >> implementations do this?
> >>
> >> Firstly, we can detect this through of the use of the dstport
> >> parameter - as a new TCP connection would use a different port.
> >> Although it could potentially lead to temporary loss of information
> >> for a time as discussed below.
> >>
> >> Secondly, the affect of this would be only apparent each time the
> >> request count is exceeded - so say every 1000 requests - when a switch
> >> over would occur. When a switch over does occur then it depends on the
> >> comparative duration of the data responses of interest, versus how
> >> often one wants to perform parallel HEAD/OPTION requests for
> >> Transport-Info. So for the case where where the frequency of parallel
> >> requests is about the same then I think it shouldn't matter much as
> >> with most server systems these days the congestion control parameters
> >> are cached in the kernel so a subsequent connection to the same
> >> destination would be preloaded with the cached metrics so the
> >> Transport-Info header would contain these. In the case where there's a
> >> series of long running responses then it might be an issue as after
> >> switch over point there would also be two parallel TCP connections to
> >> the same point but they would exist separately for a longer period so
> >> potentially the metrics obtained via subsequent HEAD/OPTIONS could be
> >> different as the cwnd can be reduced for low volume flows, though
> >> these would generally not be used since the dstport would not match so
> >> there could be a loss of information in this case.
> >>
> >> Cheers
> >>
> >> Piers
> >>
> >> On Fri, 22 Nov 2019 at 10:51, Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
> >> >
> >> > Hi Piers,
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, 22 Nov 2019, 17:58 Piers O'Hanlon, <p.ohanlon@gmail.com>
> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> - “It only provides information per response which isn’t very often”
> >> >> We mention in the draft that with H2+ one can send and arbitrary
> number of requests (using OPTIONS/HEAD) to obtain more measurements
> responses per unit time.
> >> >
> >> >
> >> > I have an observation but not sure it belongs in a document.
> Implementations such as nginx have a soft max number of HTTP/2 requests
> before closing the connection (default 1000 last I checked). If you're
> trying to sample the transport info to frequently you may end ip blowing it
> up. This seems unfortunate because the client use case is designed around
> making smarter transport related decisions.
> >> >
> >> > Cheers
> >> > Lucas
> >> >
> >> >>
> >> >> We would welcome any more feedback by email and/or Github issues
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Piers O'Hanlon
> >>
>
>