🚀 go-pugleaf

> Jacobson's header prediction algorithms grew out of a need to better
> utilize the bandwidth of very low speed links.  As a consequnce, he found
> that by being able to predict the next packet to be received, he could also
> reduce the calculations the tcp code had to do, and increase performance on
> high speed links also.  A jaded hacker would cry "obvious, that's just
> checking for the common case first - a standard optimization technique",
> which is essentially true, but never the less, such techniques had yet
> to be applied to TCP - most vendors being more or less content with
> implementations that were at least "correct", and "reasonably fast".

    Whoa -- let's be careful here.

    There are two separate algorithms that Van has developed:

    (1) An algorithm that predicts the next TCP header from the current
    one, and thus gives a very fast path (~20 instructions) for
    processing TCP segments.  This algorithm is described in
    IEEE Communications magazine (I believe in the June 1989 issue),
    and the actual code will appear in the April '90 issue of Computer
    Communication Review.

    (2) An algorithm that uses similar techniques to *compress* TCP/IP
    headers for slow speed links.  This is described in RFC 1145.

> I doubt that ISO and TP4 implementations have yet reached the level of
> maturity where this sort of optimization would produce much overall
> improvement.

    I don't think maturity is the critical factor here.  The key question
is how much coherence there is from one TP segment to the next.  (I.e.
given I know the last segment, is there a simple test I can do to confirm
the current segment is the one I expected?)

Craig