Re: New Version Notification for draft-nottingham-httpbis-retry-01.txt

Matt Menke <mmenke@google.com> Wed, 01 February 2017 21:33 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 D0412129A60 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 13:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.718
X-Spam-Level:
X-Spam-Status: No, score=-9.718 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4GuGvBMXYKxR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 Feb 2017 13:33:57 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79E3129A5D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 Feb 2017 13:33:56 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cZ2Ua-0006Tm-Om for ietf-http-wg-dist@listhub.w3.org; Wed, 01 Feb 2017 21:31:04 +0000
Resent-Date: Wed, 01 Feb 2017 21:31:04 +0000
Resent-Message-Id: <E1cZ2Ua-0006Tm-Om@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mmenke@google.com>) id 1cZ2UV-0006Sr-Ed for ietf-http-wg@listhub.w3.org; Wed, 01 Feb 2017 21:30:59 +0000
Received: from mail-oi0-f42.google.com ([209.85.218.42]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <mmenke@google.com>) id 1cZ2UO-0001qu-KG for ietf-http-wg@w3.org; Wed, 01 Feb 2017 21:30:53 +0000
Received: by mail-oi0-f42.google.com with SMTP id s203so110003963oie.1 for <ietf-http-wg@w3.org>; Wed, 01 Feb 2017 13:30:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bvhA6kxRQOTsYy+nq3Eai+6/QRRvRZ0w6P49bMb00xk=; b=SDzak4cQPDK0zO4JWL+ocH1RpuMiQ9V6liF9+V/E7z+6TZrofGgG2b1TMopeMQqJh2 bkucSZmnz5+dEusxfbbtcbTMyPU/J2egS2bMZtHr4ZfH9dFpW4fm1AbMjrh0cGyt/5rE kG51mAgWeOJ7oCxNJtad5rB3cZLMy8ExMaDgaQpfjxJgVb3EjATC6NeP+p34TVZmj7Zd L2NruPzkPp2Dvnm1DoRddU6KHHkMiQ80bbEHdGPe490tQfqWS7NjHoYoWrXjS0qC4gsY wP+/BU3+VI2HA6DvPBtkhRwVAcqQ3trMa5hNW0t4Y0PX+EhuITqYbjBFOsCFng82gx2O FzgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bvhA6kxRQOTsYy+nq3Eai+6/QRRvRZ0w6P49bMb00xk=; b=Km8PSbyrODkma5wnaHzsv0UyF4IPdtW+cTRnMhBFlr9kpkZWA8UXI6fz3Z4nMNIDfL c+4P6G0dpVimsvIqYsIPFOe/XZliGEUJBbiBHNV8cs0drn0172e5fRHGSpVzmXEaNBv+ lIptcpK900z/DmaTi2iuj/w6D5IGacEZdWrmtrVW3ge5GDFb8qW9iN0MZ1AjCRgioWTo q6INFCmxHC7VPLVvSQ1r2eiX1qVXvPn2Cdu+4OLHe+FAbDNv7/n69Ld8WH1aely7Mi7A dZTch8i5K/cL/B930D8WCRh00xDGMwWRce8/Ybh2EUwOvmVvDC94qvS9qgysDJncsDy1 h0RQ==
X-Gm-Message-State: AIkVDXJD1zC3kPH4Irtu+EA/eMzBUkydiGUZf/C0GCl3rQu14wnV/ejv4foh2yb7CbaZBnVvvOpWkYtYRC737qMR
X-Received: by 10.202.84.193 with SMTP id i184mr2568566oib.73.1485984625863; Wed, 01 Feb 2017 13:30:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.141.42 with HTTP; Wed, 1 Feb 2017 13:30:25 -0800 (PST)
In-Reply-To: <3F68DC4A-3AC8-4309-8119-15A82C5E1EFC@mnot.net>
References: <148593754312.24497.16311379877517350605.idtracker@ietfa.amsl.com> <3F68DC4A-3AC8-4309-8119-15A82C5E1EFC@mnot.net>
From: Matt Menke <mmenke@google.com>
Date: Wed, 1 Feb 2017 16:30:25 -0500
Message-ID: <CAEK7mvq3T9euSgu7zvAirwwVye8De8FY9h2bhXWpebYwj=ff0w@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113dececc47da605477ec1c3
Received-SPF: pass client-ip=209.85.218.42; envelope-from=mmenke@google.com; helo=mail-oi0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: AWL=-1.407, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cZ2UO-0001qu-KG c4ddee5ed0ea59d7825b10e699b81f54
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-nottingham-httpbis-retry-01.txt
Archived-At: <http://www.w3.org/mid/CAEK7mvq3T9euSgu7zvAirwwVye8De8FY9h2bhXWpebYwj=ff0w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33414
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

A bit more elaboration on Chrome's behavior:

I didn't see it mentioned in the draft, but the reason we retry is that any
time we reuse a socket, there's a race - servers timeout sockets after some
period, and we don't know what that period is.  So we could be retrying at
the same time the server is closing the socket on us.

We'll retry on a "stale" socket (one that was connected and then sat in a
socket pool, with or without being used first).  So if we fully preconnect
to a server before there's a connection request, we consider the socket
stale,if we've used a socket before, it's stale, or if we created a socket
to service a request, but the request was cancelled, and then the socket
connected and was returned to the socket pool, it's stale.

We only retry if we've received no response from a server, or if we get a
failure while still sending the request (i.e., if we're in the middle of
sending the request on error, we'll retry, even if there's data on the
socket from the server, since we don't bother to check for that).

We also only retry on certain errors (reset, connection closed, connection
aborted (Which is a weird error from the OS of some sort), H2 ping failure,
H2 server refusing the stream, QUIC handshake error.  This probably doesn't
include all the errors that we could get racily while reusing a socket (TCP
ping timeout, for instance?).


On Wed, Feb 1, 2017 at 3:26 AM, Mark Nottingham <mnot@mnot.net> wrote:

> FYI; fairly minor update. Would love to hear what people think about the
> various suggested paths forward.
>
> Cheers,
>
>
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *Subject: **New Version Notification for
> draft-nottingham-httpbis-retry-01.txt*
> *Date: *1 February 2017 at 7:25:43 pm AEDT
> *To: *"Mark Nottingham" <mnot@mnot.net>
>
>
> A new version of I-D, draft-nottingham-httpbis-retry-01.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
>
> Name: draft-nottingham-httpbis-retry
> Revision: 01
> Title: Retrying HTTP Requests
> Document date: 2017-02-01
> Group: Individual Submission
> Pages: 18
> URL:            https://www.ietf.org/internet-drafts/draft-
> nottingham-httpbis-retry-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-
> httpbis-retry/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-httpbis-
> retry-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-
> nottingham-httpbis-retry-01
>
> Abstract:
>   HTTP allows requests to be automatically retried under certain
>   circumstances.  This draft explores how this is implemented,
>   requirements for similar functionality from other parts of the stack,
>   and potential future improvements.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>