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

Willy Tarreau <w@1wt.eu> Tue, 07 February 2017 07:35 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 F3CED129A9A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Feb 2017 23:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Z5bU8SPHAZ3S for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Feb 2017 23:35:24 -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 132D7129A57 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 Feb 2017 23:35:23 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cb0Fm-0004yA-6X for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Feb 2017 07:31:54 +0000
Resent-Date: Tue, 07 Feb 2017 07:31:54 +0000
Resent-Message-Id: <E1cb0Fm-0004yA-6X@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <w@1wt.eu>) id 1cb0Fh-0004xP-EX for ietf-http-wg@listhub.w3.org; Tue, 07 Feb 2017 07:31:49 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by titan.w3.org with esmtp (Exim 4.84_2) (envelope-from <w@1wt.eu>) id 1cb0FY-0006tJ-UH for ietf-http-wg@w3.org; Tue, 07 Feb 2017 07:31:43 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v177VBfw003575; Tue, 7 Feb 2017 08:31:11 +0100
Date: Tue, 7 Feb 2017 08:31:11 +0100
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20170207073111.GE4850@1wt.eu>
References: <148593754312.24497.16311379877517350605.idtracker@ietfa.amsl.com> <3F68DC4A-3AC8-4309-8119-15A82C5E1EFC@mnot.net> <d8e70ea7-5d62-e22a-c0c5-ac223aa2c3a3@measurement-factory.com> <BABA7AEC-EE2E-4648-BA08-C30454752CC9@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BABA7AEC-EE2E-4648-BA08-C30454752CC9@mnot.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: AWL=0.929, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cb0FY-0006tJ-UH 7fc3f43eccaee9a8f2b28381538d542f
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/20170207073111.GE4850@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33459
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>

On Tue, Feb 07, 2017 at 02:35:32PM +1100, Mark Nottingham wrote:
> 
> > On 7 Feb 2017, at 8:04 am, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> > 
> > On 02/01/2017 01:26 AM, Mark Nottingham wrote:
> >> FYI; fairly minor update. Would love to hear what people think about the
> >> various suggested paths forward.
> > 
> > FWIW, Squid mind-boggling algorithm for retries is partially summarized
> > at
> > http://wiki.squid-cache.org/SquidFaq/InnerWorkings?highlight=%28reforward%29#When_does_Squid_re-forward_a_client_request.3F
> > 
> > Your draft already mentions a single Squid decision point, but the
> > actual logic is a lot more complex than the draft currently implies.
> > Some of that complexity is Squid's fault, as the source code comment you
> > quoted illustrates, but a lot of it is genuine.
> 
> Ah, I should have remembered that one; thanks. I've added a link.
> 
> 
> > Recommending a unified (but necessarily parameterized) approach to
> > retries would be useful for future implementors, but I suspect that
> > doing so properly would take too much time while oversimplifying the
> > situation would not help much. Just cataloging various retry factors to
> > consider may be very helpful on its own, even if you then suggest
> > nothing more than "keep these factors in mind when implementing retries".
> 
> That's a reasonable outcome. Some folks might want more, e.g., a recommended algorithm that itself isn't mandatory for all implementations (yet). Whether we go that far (and when) is still an open question, I think.

I like a lot the way it's presented in Squid's doc above. It's indeed
much better to enumerate a number of conditions that should prevent a
retry than to suggest when it's possible. As seen above, that makes
the list much easier to understand (shorter and simpler conditions)
and easier to adapt to other products.

HAProxy currently doesn't implement retry if at least one byte was sent.
The main reason is that once forwarded, these bytes are lost, but I
contemplated the possibility to pin and rewind the buffer to deal with
failures on persistent shared connections (by default we don't share them).
I've come to a number of conditions (much less) and some are common with
Squid's, so it's encouraging to read this :-)

I tend to think that just like we audited many implementations when
trying to redefine the state of deployed stacks for RFC723x, by
enumerating what various implementations do combined with their successes
or failures, we may end up with MAY and SHOULD that can be considered as
safe guidelines for future implementations, just because existing code
has had to adapt to what these current implementations do as well.

Cheers,
Willy