Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!craig
From: craig@bbn.com (Craig Partridge)
Newsgroups: comp.protocols.iso
Subject: Re: TP0-4 question (novice level)
Message-ID: <47107@bbn.COM>
Date: 19 Oct 89 12:11:22 GMT
Sender: news@bbn.COM
Reply-To: craig@BBN.COM (Craig Partridge)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 29

The header prediction algorithms are described in an article in
the July 1989 issue of IEEE Communications by Clark, Jacobson,
Romkey and Salwen.  The larger point of this article is that
protocol processing costs in hosts are less expensive than you think
(and the numbers they use for analysis are fairly conservative).

As for TCP over X.25 -- my impression from experience (now some years
ago) with CSNET's IP over X.25 implementation is that the key problem
is proper round-trip estimation, given  that X.25 introduces additional
variance into the estimate.  An example may help here:

    If TCP introduces 8 segments into an X.25 network with a maximum
    outstanding window of 2 packets (say because you go through an
    X.75 gateway), then if the round-trip time of the X.25 network
    is T, the observed TCP round-trip times will be T,T, 2T,2T,
    3T,3T, 4T, 4T.  Wilder scenarios occur in the face of mistaken
    retransmissions by the TCP.  But a good round-trip time
    estimator (e.g. Jacobson's described in SIGCOMM '88) should
    detect this  and keep your retransmission interval correct
    for the X.25 network characteristics.

Note that users, however, may notice this bizzare pattern.  Until the
Nagle algorithm was in common use, users of TELNET would find that
the echo time on their characters varied widely.  It is still true
that redrawing a screen can have an oddly syncopated look to it.
One might speculate that because TP4 doesn't allow re-aggregation of data
in the transport layer, TP4 may look worse (but then again, so should TP0).

Craig