- From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
- Date: Wed, 10 Sep 2014 17:34:25 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 9/10/14, 12:01 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote: >On 9 September 2014 07:10, Simpson, Robby (GE Energy Management) ><robby.simpson@ge.com> wrote: >> Why is piggybacking of ACKs disallowed? We could thus save 9 octets, >> 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. 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.
Received on Wednesday, 10 September 2014 17:34:57 UTC