Re: #555: frame synchronization

On 21 July 2014 16:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <DDFE70F0-2BBC-4284-8DC1-B49FA61F56D9@mnot.net>, Mark Nottingham wri
> tes:
>
>>I'm only hearing PHK and Kinkie argue for this, and the people I'm
>>seeing F2F in Toronto are against it.
>
> Could you get them to say why ?
>
>>Considering how big of a change this is, I don't think there's
>>enough support to get it over the wall.
>
> This is not necessarily a big change, it may be as little as
> 1-N bit wide sequence number which increments in every frame.
>
> I raised this issue because I have seen any mention of
> frame-desynchronization or detection probabilities thereof anywhere
> at all ?
>
> I agree that sooner or later something will blow up, my question is
> if "later" is soon enough or of we should do something to increase
> probability of detection.

Based on no better reasoning than my own implementation experience
(and the interop bugs _I_ hit), I don't think frame synchronization is
the bit of the spec that will catch people out. I don't expect people
to utterly lose a frame and I don't expect them to 'drift' on the
frames (that is, where they think the frame borders are). More likely
they will get confused on some of the implicit (or less obvious) state
tracking. These are things like:

- Not counting the optional padding flags in the flow control window
(a mistake I made). This will lead to either the endpoint being
blocked but me believing it still has room in the window (plausibly
detected by BLOCKED), or to me sending against a technically closed
window (getting an inevitable GOAWAY).
- Desyncing on HPACK state (very very hard to detect except by human
examination or bizarre statistical analysis on headers).
- Desyncing on SETTINGS values caused by the SETTINGS-SETTINGS/ACK flow.
- Desyncing on next stream IDs caused by not pumping the receive queue
hard enough.

Those are the ideas that came to me in 30 seconds of thought. I see no
way to make those easier to catch.

Am I missing something? Is it easier to frame desync than I thought?
It's possible that my lack of concern is a side-effect of my
implementation language, so please do say if you think I'm missing
something, but otherwise I'm really not that worried about frame
desync.

Received on Monday, 21 July 2014 16:31:33 UTC