Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!pdn!larry
From: larry@pdn.paradyne.com (Larry Swift)
Newsgroups: comp.protocols.iso
Subject: Re: TP0-4 question (novice level)
Keywords: TP
Message-ID: <6674@pdn.paradyne.com>
Date: 19 Oct 89 12:12:56 GMT
References: <2549@hub.UUCP> <1989Oct16.173618.25068@agate.berkeley.edu> <46993@bbn.COM> <6670@pdn.paradyne.com> <1989Oct19.005408.236@agate.berkeley.edu>
Sender: usenet@pdn.paradyne.com
Reply-To: larry@pdn.paradyne.com (Larry Swift)
Organization: AT&T Paradyne, Largo, Florida
Lines: 26

In article <1989Oct19.005408.236@agate.berkeley.edu> cliff@violet.berkeley.edu (Cliff Frost) writes:
>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

No doubt the same problem as with TP4 and X.25.

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

The obviousness of it is arguable, but in any case I can't put my
finger on any publication at the moment that explains or cites
statistics.  I think you'll find that a model of the protocols will
show a double delay (often, if not always) while first Layer 3 waits
for an ACK, then Layer 4.  This injects a significant delay into ONE
transport/network connection.  It is possible to reduce the delay by
using more connections for the one application path and tuning window
sizes, but it always seems to me like fixing symptoms instead of the
problem -- redundancy of function in the two layers.

Larry Swift                     larry@pdn.paradyne.com
AT&T Paradyne, LG-132           Phone: (813) 530-8605
8545 - 126th Avenue, North
Largo, FL, 34649-2826           She's old and she's creaky, but she holds!