Re: Simple transform for improving PN ossification prevention

[Kazuho Oku <[e-mail]>]

2018-04-11 17:56 GMT+09:00 Fossati, Thomas (Nokia - GB/Cambridge)
<[e-mail]>:
> Hi Kazuho
>
> On 11/04/2018, 09:41, "QUIC on behalf of Kazuho Oku" <[e-mail] on behalf of [e-mail]> wrote:
>> What I am arguing is that the KPI of the middleboxes that optimize TCP
>> are not only the end-user-percieved performance, but also how
>> efficient the bandwidth is used.
>>
>> It's true that with QUIC there will be much less "optimizations" that
>> middleboxes can make. But the bandwidth efficiency could still be
>> improvable, and mobile network operators will have the incentive to do
>> so since, as I stated, it helps them cram more users into each base
>> station.
>>
>> And PN will likely be the vector being used for such optimizations
>> unless we encrypt it.
>
> I'm not aware of any technique that uses an untamperable PN to achieve
> bandwidth optimisation.

Well, assuming that the majority of the senders will use PN in a
monotonously increasing manner and that skips will be inserted
infrequently, and assuming that such senders will implement ACK-based
loss detection, I would anticipate that it would make sense for a
middlebox to reorder the packet by the PN (by buffering out-of-order
packets for up to some short amount of time (e.g., 1/16 RTT)), since
it would reduce the probability of fast retransmits that could be
spurious.

I am not sure how effective doing so would be, or what the side
effects of doing that would be (or if such side effects can be
fixed)...

Am I missing something?

And anyways, let me assert what Roberto said. There will be many ways
of misusing a signal in the ways that we cannot expect of.

Let's start from the safe side (by having PNE) instead of exposing us
to the risk of ossification that will become unfixable once we start
seeing them.

> The middlebox needs to be able to actively
> manipulate the SEQ/ACK space - and maybe other things - to do that.
> And this is already not possible in QUIC, which is why network equipment
> vendors are mainly looking at AQM-based solutions.
>



-- 
Kazuho Oku