Re: delta encoding and state management

On Thu, Jan 17, 2013 at 9:56 AM, James M Snell <jasnell@gmail.com> wrote:

>
> On Thu, Jan 17, 2013 at 9:49 AM, Nico Williams <nico@cryptonector.com>wrote:
>
>> On Thu, Jan 17, 2013 at 11:21 AM, James M Snell <jasnell@gmail.com>
>> wrote:
>> > My main concerns with this approach are (a) even tho the decoder gets
>> to set
>> > limits on the amount of state used, keeping that state around is still
>> > relatively expensive compared to what we have now, and (b) keeping it in
>> > sync with the client, server and any number of intermediaries along the
>> path
>> > is likely going to prove difficult at best. We need to make sure we
>> have a
>> > good understanding of the worst case scenario with this approach (i.e.
>> > nothing stored in context anywhere along the path).
>>
>> If the compression is hop-by-hop then there's no synchronization
>> issues.  But then middleboxes may have to decompress and always
>> re-compress (even if the headers are left unmodified) in each
>> direction.
>>
>>
> That's the exact problem I'm having really. Middleboxes will be required
> to maintain a complete compression state (for requests and responses) as
> opposed to just passing things through. Maintaining that state could become
> quite expensive. If we don't maintain it, tho, the potential sync issues
> become too messy.
>

Correction on this (the bits thankfully just kind of snapped together in my
brain finally)... a middlebox would have separate decompression and
compression contexts for each request and response and would translate
between the two. If it receives a kvsto, it can choose not to store
anything and pass those along as kvsto or eref, getting by without storing
any of the actual values, but still having to maintain some amount of state
for the translation to occur. So that part (finally) clicked in my head
correctly but we still need to make sure we have a solid sense of just how
expensive maintaining that context is going to be (best and worst cases).

- James


>
>
>> In general I'd much rather not have connection-oriented state at all,
>> not even if it were transparent to HTTP.
>>
>>
> Agreed, not sure how to avoid it and still get good compression (outside
> of simply optimizing the encoding of values as much as possible... i.e.
> bohe)
>
> - James
>
>
>> Nico
>> --
>>
>
>