Re: h2 frame layout

--------
In message <528F9DBF-A486-45A0-8790-1E90FB521C65@mnot.net>, Mark Nottingham wri
tes:

>Regarding putting the stream identifier first - what concrete benefits 
>will that bring?

There are no performance benefits.

Given a transport with packets larger than the frame header
(ie: all but async RS-232), the only case where the order can
matter is if the frame header is split across packets.

For plain HTTP/TCP/IP/Ethernet that happens with a probability
of 9/1480 = 0.6%.

In reality the probability is a lot lower because frames will end
up at front of new packets after inter-packet delays.

The best "gedanken-experiment" I can come up with is a hyperintelligent
ethernet controller which uses the stream-id to route the packet to
a particular CPU-core.

However, such an ethernet controller would have to also react to the
length field or it wouldn't know where the next frame starts, so to
order of the fields wont matter.

(For a relevant piece of prior art in this space, see the contortions
the Intel '599 ethernet controller goes through to support timestamping
of PTP packets.  It's around page 700-ish of the 1000+ page datasheet.)

But the same cannot be said of the question about how we tell that
a stream has ended.

Such an intelligent ethernet controller would benefit if there were
a marker bit in the frame header that says "this is the last
frame on this stream" so that it can free any resources associated
with the processing of that stream.

-- 
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.

Received on Wednesday, 3 September 2014 06:49:27 UTC