Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ames!pasteur!ucbvax!agate!violet.berkeley.edu!cliff
From: cliff@violet.berkeley.edu (Cliff Frost)
Newsgroups: comp.protocols.iso
Subject: Re: TP0-4 question (novice level)
Keywords: TP
Message-ID: <1989Oct19.005408.236@agate.berkeley.edu>
Date: 19 Oct 89 00:54:08 GMT
References: <2549@hub.UUCP> <1989Oct16.173618.25068@agate.berkeley.edu> <46993@bbn.COM> <6670@pdn.paradyne.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Organization: University of California, Berkeley
Lines: 32

Larry,
Well, I have heard that if one does TCP/IP/X.25 there can be
problems due to flow control conflicts between TCP and X.25.  But, my
(naive) thought was that a TP4/X.25 stack might be engineered to avoid
this particular problem.  (Seems simpler than having 5 transport
protocols, one incompatible with the others...)

By "header prediction algorithms" I was referring to a part of Van
Jacobson's work with TCP.  I don't have the exact citation, but there
is an article in a very recent Journal of the IEEE by Van Jacobson,
Dave Clark and others which gives details.  (I stupidly leant my copy
to someone who appears to have lost it...)  This work should be
directly applicable to TP4, but it has nothing to do with the flow
control issue that you raise.

So far this flow control problem is the only argument I've heard that
is really technical.  Has it been spelled out somewhere, or is it
obviously insuperable to anyone very familiar with the protocols
involved?

	Thanks,
		Cliff
Re:
In article <6670@pdn.paradyne.com> larry@pdn.paradyne.com (Larry Swift) writes:
> ...
>Both of you seem to be saying that the TP4 flow control (over X.25's)
>doesn't contribute a performance hit over a single L4 & L3 connection.
>Since I have heard of contrary experiences, can you explain?  In
>particular, what are "header prediction algorithms"?
>
>
>Larry Swift                     larry@pdn.paradyne.com