Re: bohe and delta experimentation...

On Wed, Jan 16, 2013 at 3:10 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 17/01/2013, at 9:45 AM, James M Snell <jasnell@gmail.com> wrote:
>
> > Yep, saw that. The advantage I see with the strawman binary encoding is
> that it provides for millisecond precision, includes timezone data, and
> covers years up to 9999, in just 3 additional bytes.
>
> Dates in HTTP are explicitly in UTC (we just call it "GMT"), so the
> timezone data isn't helping (and may be hurting).
>
> Dates in HTTP have a granularity of one second; although people ask for
> finer granularity from time to time, giving them this capability is IMO
> asking for trouble (because clock sync and the speed of light / disk,
> combined with people's ignorance of distributed systems, leads to lots of
> bugs).
>
>
Agreed... if we can drop the timezone info entirely and just assume
everything is GMT we're good. As for millisecond precision, I do question
whether it's truly necessary but it's possible for us to at least support
the option. Assuming we omit timezone and default to seconds-only, we're
down to six bytes and seven bytes with milliseconds.


> That said, we could make millisecond granularity available in HTTP/2
> dates, as long as it's OK for that resolution to be lost when converting to
> HTTP/1. The other approach would be to introduce new headers that have the
> resolution and are able to transit a HTTP/1 connection, but the cost is
> pretty high there...
>
> WRT years up to 9999 -- yes. The method I used consumes an extra byte
> after 2106... and then another in 4147. However, just one more byte buys up
> to 36812!
>
>
I'm generally convinced that 9999 is likely going to be more than
sufficient for header values ;-)


> What's the use case for separating out hours from minutes? Given that most
> uses for dates in HTTP are driven by caching, and therefore need a direct,
> numeric comparison, why not just send the number?
>
>
The rational here was is provide a field-for-field mapping of rfc3339
date-times as efficiently as possible... basically just trying to baseline
on a single model for expressing dates rather than having to convert
between several. That, of course, is not critical.


>
> >>> Entity Tags are another area where binary values may be useful.
> Currently, ETag values generally tend to be hex or base64 encoded binary
> data.
> >>>
> >> That's a big assumption!
> >
> > Indeed ;-) ... Notice the way I hedged that with "generally tend" lol...
> I was hoping no one would notice ;-) ... what I would imagine is that delta
> op-codes could include a binary-or-text flag (there is existing space
> available in Roberto's encoding). If that flag is set, then value is
> assumed to be binary, otherwise it's text. This gives good backwards
> compatibility by default but allows for more optimized binary values.
>
> That information will be lost on a HTTP/1 hop. It would be good to discuss
> how important that is; if it's really just optimisation information, it
> might be OK...
>
> The bigger impact that I can see is that people will now need to flag
> their ETags as "binary-compatible" or not when they set them, etc. Ew.
>
>
Yeah, that's certainly a major consideration. First question is, would
binary encoding make a significant difference, second question is: is it
worth the costs. In this case, I suspect that the payoff is not going to be
significant but it's worth spending at least a little bit of time
investigating it.

- James


>
> >>> Will be turning my attention to cookie values next. I'm considering
> whether or not we should produce a code-tree that is specific to cookie
> headers and/or allow for purely binary values.
> >>
> >> I could imagine setting a parameter on Set-Cookie that indicates its
> content is encoded in a certain way, which can be replayed as binary data.
> However, that information would also need to be in Cookie, which I *think*
> necessitates a new request header -- maybe Bookie?
> >>
> >
> > Hmm... if we have the flag in the opcode would we still need this?
> Obviously I'd rather avoid having yet another cookie header definition.
>
> See above.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>


On Wed, Jan 16, 2013 at 3:10 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 17/01/2013, at 9:45 AM, James M Snell <jasnell@gmail.com> wrote:
>
> > Yep, saw that. The advantage I see with the strawman binary encoding is
> that it provides for millisecond precision, includes timezone data, and
> covers years up to 9999, in just 3 additional bytes.
>
> Dates in HTTP are explicitly in UTC (we just call it "GMT"), so the
> timezone data isn't helping (and may be hurting).
>
> Dates in HTTP have a granularity of one second; although people ask for
> finer granularity from time to time, giving them this capability is IMO
> asking for trouble (because clock sync and the speed of light / disk,
> combined with people's ignorance of distributed systems, leads to lots of
> bugs).
>
> That said, we could make millisecond granularity available in HTTP/2
> dates, as long as it's OK for that resolution to be lost when converting to
> HTTP/1. The other approach would be to introduce new headers that have the
> resolution and are able to transit a HTTP/1 connection, but the cost is
> pretty high there...
>
> WRT years up to 9999 -- yes. The method I used consumes an extra byte
> after 2106... and then another in 4147. However, just one more byte buys up
> to 36812!
>
> What's the use case for separating out hours from minutes? Given that most
> uses for dates in HTTP are driven by caching, and therefore need a direct,
> numeric comparison, why not just send the number?
>
>
> >>> Entity Tags are another area where binary values may be useful.
> Currently, ETag values generally tend to be hex or base64 encoded binary
> data.
> >>>
> >> That's a big assumption!
> >
> > Indeed ;-) ... Notice the way I hedged that with "generally tend" lol...
> I was hoping no one would notice ;-) ... what I would imagine is that delta
> op-codes could include a binary-or-text flag (there is existing space
> available in Roberto's encoding). If that flag is set, then value is
> assumed to be binary, otherwise it's text. This gives good backwards
> compatibility by default but allows for more optimized binary values.
>
> That information will be lost on a HTTP/1 hop. It would be good to discuss
> how important that is; if it's really just optimisation information, it
> might be OK...
>
> The bigger impact that I can see is that people will now need to flag
> their ETags as "binary-compatible" or not when they set them, etc. Ew.
>
>
> >>> Will be turning my attention to cookie values next. I'm considering
> whether or not we should produce a code-tree that is specific to cookie
> headers and/or allow for purely binary values.
> >>
> >> I could imagine setting a parameter on Set-Cookie that indicates its
> content is encoded in a certain way, which can be replayed as binary data.
> However, that information would also need to be in Cookie, which I *think*
> necessitates a new request header -- maybe Bookie?
> >>
> >
> > Hmm... if we have the flag in the opcode would we still need this?
> Obviously I'd rather avoid having yet another cookie header definition.
>
> See above.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>