Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!pdn.UUCP!larry
From: larry@pdn.UUCP.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8702251358.AA03547@usfvax2.UUCP>
Date: Wed, 25-Feb-87 08:15:00 EST
Article-I.D.: usfvax2.8702251358.AA03547
Posted: Wed Feb 25 08:15:00 1987
Date-Received: Fri, 27-Feb-87 23:53:46 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

Path: pdn!larry
From: larry@pdn.UUCP (Larry Swift)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Vertically Moving Congestion  (VMC)
Message-ID: <651@pdn.UUCP>
Date: 25 Feb 87 13:14:59 GMT
References: <8702200048.AA02250@ucbvax.Berkeley.EDU>
Reply-To: larry@pdn.UUCP (0000-Larry Swift)
Organization: Paradyne Corporation, Largo, Florida
Lines: 17

In article <8702200048.AA02250@ucbvax.Berkeley.EDU> JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes:
>Vary often you end up solving the problem at the layer you 
>wanted only to find that a new layer has become congested.  
>
That's why the OSI Reference Model has some form of flow control in *all*
layers one thru five.  The Session Layer (layer 5) is where the data path is
finally narrowed to a single user, and therefore s/his ability to consume
network resources can be limited there.

There are many good reference works on the OSI Model.
--------------------------------
Larry Swift
UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry
Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541
Phone: (813) 530-8605