Subject: h2 Connection Preface

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Tue, 9 Sep 2014 14:10:17 +0000

I have 4 concerns with the text for connection preface:

Concern 1)
>From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:

>   The client connection preface starts with a sequence of 24 octets,
>   which in hex notation are:
>
>     0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
>
>   (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n").  This sequence is
>   followed by a SETTINGS frame (Section 6.5).  The SETTINGS frame MAY
>   be empty.

Why does the client need to send an empty SETTINGS frame if it is OK with
the defaults?  Ditto for the server?

Concern 2)
>From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:

>   The server connection preface consists of a potentially empty
>   SETTINGS frame (Section 6.5) that MUST be the first frame the server
>   sends in the HTTP/2 connection.

But we also have in section 6.5.3:

>   The values in the SETTINGS frame MUST be processed in the order they
>   appear, with no other frame processing between values.  Unsupported
>   parameters MUST be ignored.  Once all values have been processed, the
>   recipient MUST immediately emit a SETTINGS frame with the ACK flag
>   set.

So which is it?  Does the client send the SETTINGS frame and the server
ACK and then send a SETTINGS frame?  Or must the server send its SETTINGS
before acknowledging those of the client?

Bottom line: I think we need text regarding the acknowledgement of
SETTINGS during the connection preface.

Concern 3)

>From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 3.5:

>   To avoid unnecessary latency, clients are permitted to send
>   additional frames to the server immediately after sending the client
>   connection preface, without waiting to receive the server connection
>   preface.  It is important to note, however, that the server
>   connection preface SETTINGS frame might include parameters that
>   necessarily alter how a client is expected to communicate with the
>   server.  Upon receiving the SETTINGS frame, the client is expected to
>   honor any parameters established.  In some configurations, it is
>   possible for the server to transmit SETTINGS before the client,
>   providing an opportunity to avoid this issue.

I'd be curious to hear more about "some configurations."  Considering some
servers may wish to make certain their settings are received prior to any
additional frames being sent by the client, I believe we need to describe
how this is possible.

Concern 4) -- This is more of a general issue with the SETTINGS frame.

>From http://tools.ietf.org/html/draft-ietf-httpbis-http2-14, section 6.5:

>   ACK (0x1):  Bit 1 being set indicates that this frame acknowledges
>      receipt and application of the peer's SETTINGS frame.  When this
>      bit is set, the payload of the SETTINGS frame MUST be empty.
>      Receipt of a SETTINGS frame with the ACK flag set and a length
>      field value other than 0 MUST be treated as a connection error
>      (Section 5.4.1) of type FRAME_SIZE_ERROR.  For more info, see
>      Settings Synchronization (Section 6.5.3).

Why is piggybacking of ACKs disallowed?  We could thus save 9 octets,
particularly during the connection preface.

Robby Simpson, PhD
System Architect
GE
Digital Energy

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Sep 2014 15:50:44 +0000

I agree with concerns 1, 2 and 3. By Robby's interpretations the statements in 3.5 and 6.5.3 seem mutually exclusive. 

However, a different view is that 6.5 and 6.5.3 implicitly states rules for ACK that do allow such behaviour. It is not immediately clear if all SETTINGS are ACK'd or only those containing 'updated' parameters.

> SETTINGS parameters are acknowledged by the receiving peer.

> Most values in SETTINGS benefit from or require an understanding of when the peer has received and applied the changed parameter values.

In other words, is it implied that no ACK is required if an end point sends a SETTINGS frame with parameters identical to a previous SETTINGS frame. No change was made, so there was nothing to ACK?

Does this argument extend to the preface SETTINGS frame containing parameters identical to the defined initial values?

Are empty settings frames never ACK'd? 

Concern 3)
>   In some configurations, it is

Before the client does what? If SETTINGS are part of the client preface or HTTP/1.1 upgrade request (HTTP2-Settings header), in the h2c perspective, I am unable to see how the server can send SETTINGS before the client.

>   The client sends the client connection preface
>   immediately upon receipt of a 101 Switching Protocols response (indicating a successful upgrade),
>   or as the first application data octets of a TLS connection.

This seems to imply that even over TLS the client sends a connection preface first, although it could be argued the statement is made from the client perspective. Perhaps it is hinting that after TLS connection either client or server can send a SETTINGS frame first?

Lucas

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 9 Sep 2014 16:14:00 +0000

Some answer below.

> -----Original Message-----
> From: Simpson, Robby (GE Energy Management)
> [mailto:[email-masked]]
> Sent: mardi 9 septembre 2014 16:10
> To: [email-masked]
> Subject: h2 Connection Preface
> 

3.5 rules here: the server sends its SETTINGS first and then acknowledge those of the client. It is possible for the server to send other frames after its first SETTINGS frame and before acknowledging the SETTINGS frame of the client.

6.5.3 states that when receiving a SETTINGS frame with several parameters (e.g.: SETTINGS_HEADER_TABLE_SIZE + SETTINGS_MAX_CONCURRENT_STREAMS + SETTINGS_INITIAL_WINDOW_SIZE), then all these parameters must be applied atomically and acknowledged in the same SETTINGS frame. It is not possible to apply SETTINGS_HEADER_TABLE_SIZE, to send a few frames, and then to apply SETTINGS_HEADER_TABLE_SIZE.

> additional frames being sent by the client, I believe we need to describe

Typically, when starting HTTP/2 through an Upgrade from HTTP/1.1 (3.2), the server sends its settings first, just after the 101 response.

Typically, when starting HTTP/2 with Prior Knowledge (3.4), the client sends its settings first.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 9 Sep 2014 16:25:56 +0000

I wrote too fast :-(.

> Typically, when starting HTTP/2 through an Upgrade from HTTP/1.1 (3.2), the
> server sends its settings first, just after the 101 response.

More clearly, in this case, typically, the server sends its settings before the client sends any other frame.

> Typically, when starting HTTP/2 with Prior Knowledge (3.4), the client sends its

And the client can send other frames before receiving the server settings.

Hervé.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 9 Sep 2014 16:34:06 +0000

See my answers below,

Hervé.

> From: Lucas Pardue [mailto:[email-masked]]
> Sent: mardi 9 septembre 2014 17:51
> To: Simpson, Robby (GE Energy Management); [email-masked]
> Subject: RE: h2 Connection Preface
> 
> However, a different view is that 6.5 and 6.5.3 implicitly states rules for ACK
> that do allow such behaviour. It is not immediately clear if all SETTINGS are
> ACK'd or only those containing 'updated' parameters.
> 
> > Most values in SETTINGS benefit from or require an understanding of when
> the peer has received and applied the changed parameter values.
> 
> In other words, is it implied that no ACK is required if an end point sends a
> SETTINGS frame with parameters identical to a previous SETTINGS frame. No
> change was made, so there was nothing to ACK?

This sentence is intended to provide background for the reason why a SETTINGS ack is required by the spec.
So even when the SETTINGS parameters are identical to those of the previous SETTINGS frame, section 6.5.3 is applied and a SETTINGS frame with the ACK flag set is sent.

> Does this argument extend to the preface SETTINGS frame containing
> parameters identical to the defined initial values?

The preface SETTINGS frame is always ACK'd.

> Are empty settings frames never ACK'd?

All SETTINGS frame are ACK'd, otherwise, the sender of a SETTINGS frame can no longer match received SETTINGS ACKs to sent SETTINGS.
 
> Before the client does what? If SETTINGS are part of the client preface or
> HTTP/1.1 upgrade request (HTTP2-Settings header), in the h2c perspective, I
> am unable to see how the server can send SETTINGS before the client.

It should read "before the client sends additional frames".

> This seems to imply that even over TLS the client sends a connection preface
> first, although it could be argued the statement is made from the client
> perspective. Perhaps it is hinting that after TLS connection either client or
> server can send a SETTINGS frame first?
> 
> Lucas
> 
> 
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Sep 2014 17:02:26 +0000

That answers my questions thank you. While I agree that the ACK helps the end point tracking ability, it does complicate the sequence. Following your description I have this sequence in the HTTP/1.1 Upgrade case 

1. Client sends Upgrade request including SETTINGS in HTTP2-Settings header field
2. Server does not need to ACK (1) (as explained in 3.2.1, however that runs contrary to the MUST described in 6.5)
3. Server sends 101 Switching Protocol
4. Server sends SETTINGS
5. Client ACKS (4)
6. Client sends preface including SETTINGS
7. Server ACKS (6)
8. Server provides response to request 1

My Proposition: If we can bend the rules to remove an ACK in the Upgrade sequence, can we also remove the requirement for a client preface? 

The client has provided settings that the Server implicitly accepted, the server is sending it's connection preface before the client, so the connection preface provides no value other than a redundant SETTINGS that could be sent in a standalone frame if really necessary.

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Tue, 9 Sep 2014 18:43:54 +0000

On 9/9/14, 12:14 PM, "RUELLAN Herve" <[email-masked]> wrote:

>3.5 rules here: the server sends its SETTINGS first and then acknowledge
>those of the client. It is possible for the server to send other frames
>after its first SETTINGS frame and before acknowledging the SETTINGS
>frame of the client.
>
>6.5.3 states that when receiving a SETTINGS frame with several parameters
>(e.g.: SETTINGS_HEADER_TABLE_SIZE + SETTINGS_MAX_CONCURRENT_STREAMS +
>SETTINGS_INITIAL_WINDOW_SIZE), then all these parameters must be applied
>atomically and acknowledged in the same SETTINGS frame. It is not
>possible to apply SETTINGS_HEADER_TABLE_SIZE, to send a few frames, and
>then to apply SETTINGS_HEADER_TABLE_SIZE.

Then it sounds like 6.5.3 needs some re-wording and that would resolve my
2nd concern.  When I see "no other frame processing" and "MUST immediately
emit" I think that no other frames are sent until the ACK is sent and that
essentially everything stops when a SETTINGS frame is received.  And what
you are saying is that the server MUST send its SETTINGS frame prior to
sending an ACK for the client's SETTINGS frame.

A piggyback ACK, if possible, would help here.

>Typically, when starting HTTP/2 through an Upgrade from HTTP/1.1 (3.2),
>the server sends its settings first, just after the 101 response.
>

OK.  So the "configurations" in this case are the various "starting"
mechanisms (i.e., HTTP Upgrade, TLS, Prior Knowledge), specifically HTTP
Upgrade.  Perhaps "some configurations" should be changed to state the
HTTP Upgrade starting mechanism specifically.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Sep 2014 15:31:52 -0700

> 8. Server provides response to request 1

I sometimes worry that people intentionally misread the spec to make a
point.  Do you really expect the above to work with steps 5 and 6 as
shown?

> My Proposition: If we can bend the rules to remove an ACK in the Upgrade sequence, can we also remove the requirement for a client preface?

That doesn't work.  If one side changes certain settings, like header
table size, the other side needs to know when the change was enacted.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Sep 2014 15:37:15 -0700

> sending an ACK for the client's SETTINGS frame.

Let's show that in context, because the immediately applies to the
processing, not the receipt.  Any other requirement is a little
ridiculous, because your interpretation doesn't allow for the packets
already in flight, which can't be taken back.

> A piggyback ACK, if possible, would help here.

?

>>> SETTINGS during the connection preface.

https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee62e0dd618e76

> HTTP Upgrade starting mechanism specifically.

TLS 1.3 might allow the server to send application data first.  Might.

Enumerating the options like this doesn't seem to be particularly
useful here.  For one, it runs the risk of proscribing behaviour.

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Wed, 10 Sep 2014 00:08:53 +0000

>>A piggyback ACK, if possible, would help here.

My 4th concern from the start of this thread.

>https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee62e

Thanks!  This resolves my 2nd concern.

>useful here.  For one, it runs the risk of proscribing behaviour.

Makes sense - I agree with you.  I withdraw my 3rd concern.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 10 Sep 2014 10:32:14 +0000

Following the change made at https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee, I can more clearly see how the proposed sequence was mistaken.

> That doesn't work.  If one side changes certain settings, like header table size, the other side needs to know 
> when the change was enacted. 

I think we are talking cross purposes, I was focussed more on Upgrade scenario and the SETTINGS redundancy between HTTP2-Settings and the connection preface. Having done some more reading in the mailing lists (http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0048.html) I agree with the intentions of having both; similar codepaths regardless of entry point, minimal HTTP2-Settings in the HTTP etc.

The argument for similar codepaths would also answer Robby's concern #1.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 09 September 2014 23:32
To: Lucas Pardue
Cc: RUELLAN Herve; Simpson, Robby (GE Energy Management); [email-masked]
Subject: Re: h2 Connection Preface

On 9 September 2014 10:02, Lucas Pardue <[email-masked]> wrote:
> 1. Client sends Upgrade request including SETTINGS in HTTP2-Settings 
> header field 2. Server does not need to ACK (1) (as explained in 
> 3.2.1, however that runs contrary to the MUST described in 6.5) 3. 
> Server sends 101 Switching Protocol 4. Server sends SETTINGS 5. Client 
> ACKS (4) 6. Client sends preface including SETTINGS 7. Server ACKS (6) 

I sometimes worry that people intentionally misread the spec to make a point.  Do you really expect the above to work with steps 5 and 6 as shown?

> My Proposition: If we can bend the rules to remove an ACK in the Upgrade sequence, can we also remove the requirement for a client preface?

That doesn't work.  If one side changes certain settings, like header table size, the other side needs to know when the change was enacted.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Sep 2014 09:01:28 -0700

> particularly during the connection preface.

I missed this earlier.  There was a preference expressed for a clean
demarcation between settings and acknowledgements.  I don't think it
was a strong preference, but since the only reason to allow
piggybacking was to save bytes and that saving was for a relatively
rare frame type, I think that it was easier to go with the no
combination option.

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Wed, 10 Sep 2014 17:34:25 +0000

>rare frame type, I think that it was easier to go with the no

Thanks for the background Martin.

My preference would be to allow piggybacking.  I understand it is
relatively rare, but it is possible during the connection preface in most
configurations.  The potential to save 9 octets during the setup of a
connection is particularly important for short-lived connections,
energy-limited applications, etc., particularly for a protocol with a
stated goal of improving latency and performance.  I'm specifically
thinking of servers sending a piggybacked ACK along with their SETTINGS
during the connection preface.

That said, I understand the ship may have sailed on this one.  But I am
curious if such a change is possible.  Those who wish to maintain a clean
demarcation could simply choose not to send piggybacked ACKs.

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Thu, 11 Sep 2014 19:44:52 +0000

On 9/10/14, 6:32 AM, "Lucas Pardue" <[email-masked]> wrote:

>Following the change made at
>https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee,
>I can more clearly see how the proposed sequence was mistaken.
>
>I think we are talking cross purposes, I was focussed more on Upgrade
>scenario and the SETTINGS redundancy between HTTP2-Settings and the
>connection preface. Having done some more reading in the mailing lists
>(http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0048.html) I
>agree with the intentions of having both; similar codepaths regardless of
>entry point, minimal HTTP2-Settings in the HTTP etc.
>

How so?  From what I can tell, my concern #1 is the same regardless of
entry point.  It essentially comes down to the difference of all code
paths sending an empty SETTINGS frame when they wish to stick with the
defaults, or all code paths moving on (and saving the SETTINGS frame and
the corresponding ACK).

That said, I understand that changing it at this point may not be
desirable if we do not want to make "breaking" changes.