Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

[Kazuho Oku <[e-mail]>]

2018-02-08 9:37 GMT+09:00 Christian Huitema <[e-mail]>:
>
>
> On 2/7/2018 1:10 AM, Kazuho Oku wrote:
>> The pros of using a sequence that randomly distributes 0 and ones
>> (i.e. PI or xorshift+) is that you can extract good loss / reordering
>> information if the error rate is low.
>>
>> OTOH, it is fragile to high error rate or certain patterns of error.
>> Let me explain two examples.
>>
>> Consider the case where the packet loss rate is 50%. I doubt if you
>> could use pattern matching against those sequences to figure out the
>> loss rate. This is because the power among the sequence is mostly high
>> frequencies. If you use a sequence that distributes power among lower
>> frequencies (like square wave or sin wave that I discussed), you can
>> calculate the loss rate in such cases as well.
>
> Actually, it should be possible to build a maximum likelihood decoder
> for an xorshift sending pattern. You are mostly concerned with erasure
> and permutations, and you roughly know the range of probability, so you
> can see likelihood of 1, 2, 3, etc. erasures, or permutations in some
> range. Obviously, the range that you can manage depends on the length of
> the code. If you can keep the decoder synchronized, you will be able to
> measure the erasure rate.

I agree with you that it is possible to detect loss / reorder if the
decoder can be kept synchronized.

What I am questioning is the possibility of keeping the decoder
synchronized under heavy loss / reorder.

> If it looses synchronization, you know that
> the error rate is truly horrendous, and that's information too.

I disagree.

It might be true that loosing synchronization due to heavy loss can be
a signal. OTOH, loosing synchronization due to massive reorder is not
an issue if the reorder resolves in a certain timeframe (IIRC 1/8
RTT).

My understanding is that the middleboxes' reliance to the sequence
number has led to the ossification of TCP. The ossification has
prevented us from doing some nifty things, such as sending some TCP
packets through a different node while answering others directly. In
QUIC, I am interested in doing such things, and I would expect that
others will be.

Considering that, I would prefer not to exposing a signal that could
give false information to observers when there is a "good" reorder.

> And
> xorshift codes are self synchronizing, so you will regain
> synchronization quickly.
>
> -- Christian Huitema
>



-- 
Kazuho Oku