Re: delta encoding and state management

["Adrien W. de Croy" <[e-mail]>]

------ Original Message ------
From: "James M Snell" <[e-mail]>


>>>Let's assume that the connection between B and C dies before that 
>>>second request is sent to B, causing the compression context shared 
>>>between B and C to be reset and lost. Suddenly the delta encoding in 
>>>the second message becomes invalid, even though nothing has 
>>>interrupted the connection between A and B.
>>>
>>>B and C need to have some way of reestablishing the compression 
>>>context after their connection is reestablished or the second message 
>>>just becomes nonsense.
>>>
>>>At first review, there appear to be a few options:
>>>
>>>1. B has to also maintain it's own copy of the complete header value 
>>>table, which could consume quite a bit of storage space on the proxy 
>>>(relative to current requirements). Once the connection is 
>>>re-established, B would then translate the delta-encoding in the 
>>>second message to initialize the reconstructed context on C. We 
>>>currently do not have any metrics on just how large this table could 
>>>potentially become within the course of a single session.
>>>
>>
>>Well, current requirements are either no compression (HTTP/1), or use 
>>a encoder-defined amount of memory at the decoder (gzip in SPDY).
>>The idea here with delta is to give the decoder more keys to the 
>>castle-- the decoder (not the encoder!) dictates how much state it is 
>>willing to maintain and the encoder must stick within that. It 
>>wouldn't be too hard to bolt this onto any compression scheme, 
>>probably.
>>
>>As an encoder, you always have the option of using no state for 
>>encoding, so all the other side can dictate is the maximum state you 
>>can use.
>>
>>-=R
>>
>>>2. B needs to notify A that the compression context needs to be 
>>>reset. If A gets that message before is constructs the second 
>>>message, all is fine, A would just treat it like the initial 
>>>response. If A already in the process of sending that message to B, B 
>>>is going to have to reject it or put it on hold until the context is 
>>>reconstructed... in which case B is going to need some way of knowing 
>>>whether the message needs to be rejected. Also, there is a risk of 
>>>too many reset messages being sent, causing a lot of churn.
>>>
>>>3. B assigns a compression buffer window size of 0, effectively 
>>>disabling the stored compression context (every message effectively 
>>>becomes an initial message). The risk here is that a proxy might 
>>>defensively always send a 0.
>>>
>>>My questions to the group are:
>>>
>>>A. Am I missing anything obvious here?

why not just get B to tell A that C went down.

Push the problem back to the client is the obvious boot-strap option.  
It already has all the data.

Adrien


>>>B. Are there other possible options?
>>>C. Which option seems to be the least painful?
>>>
>>>- James
>>>
>>
>