Subject: Re: New Version Notification for draft-benfield-http2-p2p-01.txt

From: David Dias <[email-masked]>
Date: Sun, 23 Aug 2015 15:27:48 +0100

Hi all,

Apologies for the slow reply, I found myself traveling to a couple of conferences during the month of August that consumed my full availability.

This extension to the HTTP2 Protocol looks very good indeed and fulfils the our expectations of using the robust framing layer designed for HTTP2 in P2P application scenarios. There are just only two segments that I need some clarification, namely:

2.2 CLIENT_AUTHORITY Frame
...
The purpose of this frame is to allow a client to advertise
the authority or authorities for which it is prepared to accept
requests.
Does this mean that a HTTP2-P2P client would have to announce every single authority it is willing to accept requests from? Would it be possible to do this with an header or simply by not sending the SETTINGS_PEER_TO_PEER frame if the client verifies that it is speaking with a server it is not interested in receiving requests from?

2.4 Client Behavioural Changes
…
The client MUST NOT
send a PUSH_PROMISE frame on a stream that it opened by means of a
HEADERS frame: only server-initiated streams may be used for sending
PUSH_PROMISE frames.  All other limitations about PUSH_PROMISE frames
in RFC 7540 [RFC7540] continue to apply, except that the words
'server' and 'client' are defined on a per-stream basis.
I believe the intended behaviour would be for a server to be able to send a PUSH_PROMISE frame on a client-initiated stream (a first request from the client) and not on a server-initiate stream.

One another thing I would like to point out is that we learned that declaring the participants in a connection as ‘dialer’ and ‘listener’ instead of ‘client’ and ‘server’, help achieve a better understanding how the system is designed to be distributed, meaning that every entity speak and implement the same protocol and respective semantics.

Thank you for working on this specification, we are really excited and looking forward to see it as a final RFC, so that we can collaborate on a unified implementation with the other groups who have been implementing their own versions of the spdy/http2 framing layer.

Best regards,

> On 27 Jul 2015, at 01:43, Fedor Indutny <[email-masked]> wrote:
> 
> Thank you, looks even better now!
> 
> On Sun, Jul 26, 2015 at 10:12 AM, Cory Benfield <[email-masked] <mailto:[email-masked]>> wrote:
> I’ve updated the HTTP/2 P2P draft in response to the feedback received this week. Particular thanks to Ilari, who provided substantial feedback and corrections. The major change here is that the server no longer needs to advertise its support for the extension.
> 
> Once again, more feedback would be appreciated!
> 
> Cory
> 
> > Begin forwarded message:
> >
> > From: [email-masked] <mailto:[email-masked]>
> > Subject: New Version Notification for draft-benfield-http2-p2p-01.txt
> > Date: 26 July 2015 18:09:38 BST
> > To: "Cory Benfield" <[email-masked] <mailto:[email-masked]>>, "Cory Benfield" <[email-masked] <mailto:[email-masked]>>
> >
> >
> > A new version of I-D, draft-benfield-http2-p2p-01.txt
> > has been successfully submitted by Cory Benfield and posted to the
> > IETF repository.
> >
> > Name:         draft-benfield-http2-p2p
> > Revision:     01
> > Title:                Peer-to-peer Extension to HTTP/2
> > Document date:        2015-07-26
> > Group:                Individual Submission
> > Pages:                8
> > URL:            https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-01.txt <https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-01.txt>
> > Status:         https://datatracker.ietf.org/doc/draft-benfield-http2-p2p/ <https://datatracker.ietf.org/doc/draft-benfield-http2-p2p/>
> > Htmlized:       https://tools.ietf.org/html/draft-benfield-http2-p2p-01 <https://tools.ietf.org/html/draft-benfield-http2-p2p-01>
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-benfield-http2-p2p-01 <https://www.ietf.org/rfcdiff?url2=draft-benfield-http2-p2p-01>
> >
> > Abstract:
> >   This document introduces a negotiated extension to HTTP/2 that turns
> >   a single HTTP/2 connection into a bi-directional communication
> >   channel.
> >
> >
> >
> >
> > 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 <http://tools.ietf.org/>.
> >
> > The IETF Secretariat
> >
> 
>

---

From: Cory Benfield <[email-masked]>
Date: Mon, 24 Aug 2015 09:33:26 +0100

On 23 August 2015 at 15:27, David Dias <[email-masked]> wrote:
> Does this mean that a HTTP2-P2P client would have to announce every single
> authority it is willing to accept requests from?

Nope, you have this backward. The client announces what authorities it
believes *it is*. This is necessary because the server (turned client)
needs to know what authority it is requesting data from (at the very
least to populate the :authority pseudo-header field) when it makes
requests.

The flow is as follows:

Client initiates connection to 'h2peer.com', and offers H2 P2P.
It emits a CLIENT_AUTHORITY frame indicating that the client believes
it is authority 'h2peer2.com'
Server verifies the client's IP address against a static list to
confirm that the client actually is 'h2peer2.com'
Client can now make HTTP requests to the server (authority h2peer.com)
and the server can make requests to the client (authority
h2peer2.com).

> I believe the intended behaviour would be for a server to be able to send a
> PUSH_PROMISE frame on a client-initiated stream (a first request from the
> client) and not on a server-initiate stream.

I think this represents a problem with the ambiguity of 'client' and
'server'. This should really be saying that PUSH_PROMISE frames can
only be sent on streams that the given peer did not initiate. I'll
attempt to reword with 'dialer' and 'listener' (or something similar)
to avoid the ambiguity.

Cory

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 25 Aug 2015 04:02:26 +1200

> and the server can make requests to the client (authority

Nit pick: if this gets anywhere near a spec make sure the example
authority names are clearly and instantly distinguishable from each
other. One digit is still quite mind-boggling.

> attempt to reword with 'dialer' and 'listener' (or something similar)

I think that wording you just used is probably the most clear its going
to get:

> PUSH_PROMISE frames can
> only be sent on streams that the given peer did not initiate.

Amos