Re: Git Issues: PING

James M Snell <jasnell@gmail.com> Thu, 09 May 2013 17:03 UTC

Return-Path: <ietf-http-wg-request@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 B1BD221F92A5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.578
X-Spam-Level:
X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzzHDWZWHTlT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:03:31 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C57E721F84CD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 10:03:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UaUEN-0001X3-82 for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 17:02:11 +0000
Resent-Date: Thu, 09 May 2013 17:02:11 +0000
Resent-Message-Id: <E1UaUEN-0001X3-82@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UaUEC-0001Vx-RP for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 17:02:00 +0000
Received: from mail-oa0-f50.google.com ([209.85.219.50]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UaUEB-0006yS-QY for ietf-http-wg@w3.org; Thu, 09 May 2013 17:02:00 +0000
Received: by mail-oa0-f50.google.com with SMTP id l20so732056oag.23 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 10:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=H4qPtGpmnmUwVOax3QdraS0F0jAphsJXm+HNjk9P//U=; b=JT95DgTgIsB480O1Bsmbax0DDWurw2e3fWYhpePqSayNmalgrseidZqLmWqx/SVkXR 0Oo0OBFB1Vkfvg+9Jg6kujv8hOxzX6vn4epK2FObDxvFkxH8kl7oj4d/hh7Uxdnj/Rdm q5+10LQ5yTzoV/CVDOP+2SRngpNko9sjQ8eZD5ei1Oy9NkvpsB6b0F2p6KCWGDq+8UGI MDsXUkr6C+y2AaG1z7wZAvRGPbJuhBfV3OsQ/jLPfpjwV2m0XEK+4myQPc4a9DgzQnRk HWGoE54xvMWAr90fkPxTtqk0gfk3QRvwzD23h/PSCRwPRLpBXB/tYaPwDZAqjp2V23Rk B0Tw==
X-Received: by 10.182.108.165 with SMTP id hl5mr4766418obb.33.1368118893898; Thu, 09 May 2013 10:01:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Thu, 9 May 2013 10:01:13 -0700 (PDT)
In-Reply-To: <CA+pLO_hnzZ_o38jWXHK4h9VDTbRHwmcRgd7GzdWa2So2BW-wCQ@mail.gmail.com>
References: <CABP7RbeTgHaHVuoJPD=LNgEij4_+k8KQg4ni6oDn=Cuw6qsCWg@mail.gmail.com> <CAA4WUYhpOtHhH8kwHN3aK4=tT4LLdP+p6fTQuogWB9abBAhURw@mail.gmail.com> <CABP7RbcdGeBKfQke=NocROhow9kSuV4MOQvP4MMJrwzP7ip56Q@mail.gmail.com> <CA+pLO_hnzZ_o38jWXHK4h9VDTbRHwmcRgd7GzdWa2So2BW-wCQ@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Thu, 09 May 2013 10:01:13 -0700
Message-ID: <CABP7Rbe_9+jp2Hg==0TWO6xu6M+oz0GHv0KrifJhOqAkeA5TsQ@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.219.50; envelope-from=jasnell@gmail.com; helo=mail-oa0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.702, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UaUEB-0006yS-QY b824d3b0c187b00fa150d99c4b62e978
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Git Issues: PING
Archived-At: <http://www.w3.org/mid/CABP7Rbe_9+jp2Hg==0TWO6xu6M+oz0GHv0KrifJhOqAkeA5TsQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17908
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>

I'm working through issues relating to frame size currently. What I'd
like to recommend is that the PING frame be limited to no more than
8-bytes of payload data. The PING sender can use these bytes however
they want and they are completely opaque to the PING recipient. Most
typically, I would think that these bytes would be used to encode a
timestamp or correlation ID for the ping.

On Mon, Apr 22, 2013 at 12:43 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> I would be cautious of giving semantic meaning to the payload, and an ID
> larger than 4 bytes seems unnecessary.
>
> I do like the introduction of the PONG flag and the subsequent removal of
> the restrictions on the ID field, letting the peer send whatever index into
> their stored context that they like.
>
>
> On Sat, Apr 20, 2013 at 2:56 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> The main argument I've seen for allowing a payload is so that the PING
>> sender can include a stronger correlation token than just the ID (a
>> timestamp, for instance).
>>
>> On Sat, Apr 20, 2013 at 1:51 PM, William Chan (陈智昌)
>> <willchan@chromium.org> wrote:
>> > +jpinner who filed the issue
>> >
>> > Unless anyone comes up with a motivating reason to add arbitrary
>> > payloads,
>> > let's just disallow them. This is what the SPDY/2 spec originally did
>> >
>> > (http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-PING):
>> > "Length: This frame is always 4 bytes long."
>> >
>> > Unless I missed a PING discussion elsewhere, it looks refactoring
>> > accidentally introduced a semantic change. Let's fix that.
>> >
>> >
>> > On Sat, Apr 20, 2013 at 12:37 PM, James M Snell <jasnell@gmail.com>
>> > wrote:
>> >>
>> >> Per https://github.com/http2/http2-spec/issues/68 ...
>> >>
>> >> The question is: "In the current draft, the PING frame requires the
>> >> server to resend an arbitrarily large payload.... Perhaps restrict the
>> >> length of the PING frame to 0, allow any stream identifier in the
>> >> header require the server to echo the identifier? ... I'm not sure
>> >> what benefit being able to echo arbitrary contents provides."
>> >>
>> >> Placing a cap on the size of the Ping payload makes sense. Whether
>> >> that cap should be strictly mandated by the spec or established via
>> >> SETTINGS is an open question, however. Perhaps the spec ought to place
>> >> a strict upper limit and allow recipients to optionally specify a more
>> >> restrictive value via SETTINGS?
>> >>
>> >> - James
>> >>
>> >
>
>