I've gotten the simulator working with QCRAM -04 changes, specifically the
part that moves all updates to the control stream.

I ran some tests to compare hpack, qcram-03 and qcram-04.


                   HolBs     (%)
hpack         850         100
qcram-03   27            3.2
qcram-04   46            5.4

HolBs here are requests that experienced Hol blocking.

I think the main reason -04 doesn't degrade to HPACK is that there are
quite a lot of requests that do no updates.   Note that the indexing
strategy doesn't index :path.

Additional details:

The har was a facebook of my own.  I got it from chrome, using developer
tools For reference it has 299 requests, and 167955 uncompressed header
bytes.

The table maxed out at 38 entries (same for all runs).

The HolBs above are totals over 10 runs of each scheme.  I ran multiple
times to smooth variation due to the randomization of the simulator.

I set the simulator loss rate of 0.35, which may be insanely high, but it
stresses HoL Blocking.










On Wed, Jan 24, 2018 at 9:06 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:

> Hi,
>
> Thank you for the response.
>
> 2018-01-25 3:44 GMT+11:00 Charles 'Buck' Krasic <ckrasic@google.com>:
>
>>
>>
>> On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>>> 2018-01-24 23:10 GMT+11:00 Jana Iyengar <jri@google.com>:
>>> >
>>> > The draft outlines what I think the room converged on, and it seems
>>> fairly straightforward -- thanks for the quick turnaround!
>>> >
>>> > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but
>>> I believe the "Base Index" is basically what I think of as the "generation
>>> ID" of the table. It reflects the number of table operations that have
>>> happened... this is important when you have evictions, since just a
>>> reference to the largest index is ambiguous if there have been evictions.
>>>
>>> Jana, thank you for the response.
>>>
>>> Please correct me if I am wrong, but the below is my understanding.
>>>
>>> Modifications to the HPACK state only happens on the Control Stream.
>>> So we do not need to rely on the index to determine how the state
>>> needs to be changed.
>>>
>>
>> Great point.  The prefix is not needed for the modifications to HPACK
>> state, i.e. for the blocks delivered on the Control Stream.
>>
>>
>>>
>>> For HEADERS frames sent over non-control streams, the only information
>>> that the decoder needs is the absolute indices of the header table,
>>> which can be encoded as largest_index (or whatever you call) plus the
>>> deltas.
>>>
>>> >
>>> >
>>> > I don't understand however how the largest index is "Base Index -
>>> Depends". I would've thought the largest index would simply be "Depends".
>>> What am I missing?
>>>
>>
>> Alan F.  also made a similar point.
>>
>> Base index is for interpreting indexed representations correctly
>> regardless of re-ordering.  It is basically the total number of insertions
>> that happened before the current block has processed.
>>
>> Depends is for ensuring that the decoder blocks if necessary to wait for
>> table updates the current block depends on.
>>
>> The 'Base Index - Depends' is poorly written and needs an example, sorry
>> about that.   The point I was trying (badly) to make was that depends is
>> encoded relative to Base Index so that it's size stays bounded, it's just
>> an optimization to save bytes for the case of very long lived connections.
>> Note that Base Index does not have such bound right now.  Maybe a change to
>> specify wrap-around  might be a reasonable way to also bound Base Index.
>>
>> Alternatively, and maybe this is what you just said (?), the two could be
>> combined into one number.
>>
>
> Yes. That is what I have been thinking of.
>
>
>> I think that is tricky because one does not naturally know "depends" yet
>> while emitting indexed entries.
>>
>
> I think that the encoder needs to do a two-pass operation regardless of if
> we encode two numbers (i.e. base_index, depends) or just one. This is
> because since base_index and depends cannot be determined until the encoder
> iterate through all the headers.
>
> So to me it seems that it is not tricker for an encoder to use an unified
> value; in the first pass the encoder determines the absolute index, and
> then in the second pass emit the unified "base index" plus the deltas.
>
>
>>     It could be in practice that either the depends flag is false, or it
>> is true and the Depends value is the same as Base Index.   This was
>> definitely not true with QCRAM-03, but it might well be with QCRAM-04.
>> That's what I hope to sort out ASAP with updates to the simulator. 🤔
>>
>
> I understand that it's hard to update all the related code as we adjust
> the approach. Thank you for your efforts!
>
>
>>
>>
>>
>>
>>
>>> >
>>> > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <kazuhooku@gmail.com>
>>> wrote:
>>> >>
>>> >> Buck,
>>> >>
>>> >> Thank you for the draft.
>>> >>
>>> >> I like the approach and I think that it is not difficult to implement.
>>> >>
>>> >> Reading the spec, the question I have is why you need the BLOCKING
>>> flag and two variables (i.e. base index and depends). Can't each HEADERS
>>> frame always hold just one offset (i.e. largest index that the frame refers
>>> to)?
>>> >>
>>> >> Maybe I am missing something.
>>> >>
>>> >>
>>> >> 2018-01-24 16:53 GMT+11:00 Mike Bishop <mbishop@evequefou.be>:
>>> >>>
>>> >>> Buck has posted an updated QCRAM draft at
>>> https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read
>>> before tomorrow’s meeting so we can have a useful discussion.  Thanks!
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kazuho Oku
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>>>
>>
>>
>>
>> --
>> Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1
>> (408) 412-1141 <(408)%20412-1141>
>>
>>
>
>
> --
> Kazuho Oku
>



-- 
Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408)
412-1141