W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

#555: frame synchronization

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 20 Jul 2014 15:52:17 -0400
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>
Message-Id: <B58FCE90-D71E-4479-B1C1-FFC912CAD993@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
<https://github.com/http2/http2-spec/issues/555>

Anyone with thoughts on this? 



On 12 Jul 2014, at 4:30 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> Another issue I don't want to raise in the current melee, but I
> think we should take it as an isssue, discuss it and close it,
> so we can claim that we thought about it:
> 
> 
> Has anybody considered frame-desynchronization ?
> 
> The framing layer has neither pattern, checksum or sequence numbers
> to help us tell if the sender and receiver have become mis-synchronized,
> 
> If we wanted to be strictly compliant with "end-to-end argument" we
> should have an integrity check, but given that we have a CRC and
> sums in the layers below I don't think that's really an overhead
> which would justify itself.
> 
> However, it would make good sense to add a pattern or sequence
> number to the frame header to give us a "must match field" to detect
> frame misalignment.  (I looked at the current frames and there
> are no fields which lend themselves naturally to this).
> 
> If a frame header gets misaligned one byte either way, there are
> pretty good chances that it will still look legit enough for
> processing to commence.
> 
> Given that many people talk about processing frames while they are
> still being received, adding a more robust misalignment detection
> sounds like a good idea to me.
> 
> The easiest is probably a single byte sequence number which just
> increments from frame to frame.  That number could be included
> in RST frames to indicate which frame caused the error.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

--
Mark Nottingham   http://www.mnot.net/
Received on Sunday, 20 July 2014 19:52:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC