🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: mod.protocols
Article #97

Submission for mod-protocols

#97
From: larry
Date: Wed, 04 Mar 1987 14:51
49 lines
2674 bytes
Path: pdn!larry
From: larry@pdn.UUCP (Larry Swift)
Newsgroups: mod.protocols
Subject: Re: OSI references and flow control
Keywords: OSI flow control
Message-ID: <669@pdn.UUCP>
Date: 4 Mar 87 14:51:45 GMT
Organization: Paradyne Corporation, Largo, Florida
Lines: 40


(In reply to an email discussion)
>specific references to how to do FLOW CONTROL in the OSI model.  

Peer-to-peer flow control, as you have indicated, is much discussed in 
OSI circles.  I don't know of any references addressing flow control
at the service interface, however (see below).  If I find any, I'll 
let you know.

>I suspect whoever defined the standard do not know how well their stuff works
>in the real network.

You might have a good point, there!

> In OSI model, each layer determines its own flow control parameter
> values.  Now assume transport layer sends lots of data (it has a large
> window size), but the net can't send that fast.  Where are data buffered?
> What problems does this cause?  (in reality, not in definition.  These
> real problems are seen everyday.)

You are referring to a resource problem in the service interface(s), which,
I agree, the Model hasn't addressed at all, as of yet.  One of the reasons, 
I'm sure, is that the problem is usually internal to the node rather
than the network (ie, the given two layers are operating in the same 
program environment).  I know from experience that this takes a rather 
sophisticated, communications-oriented operating system to resolve in a
common manner, and therefore is subject to all sorts of non-networking
requirements being imposed.  Unix, for example, is a long way from being
able to address the problems.

I suspect the OSI Model won't be upgraded to address the problems for a 
long time either, since I don't believe the upper layers are yet locatable 
in separate program environments (ie, machines).

--------------------------------
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
Technical Details
Message-ID: <8703041603.AA16563@usfvax2.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!pdn.UUCP!larry

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!pdn.UUCP!larry
From: larry@pdn.UUCP.UUCP
Newsgroups: mod.protocols
Subject: Submission for mod-protocols
Message-ID: <8703041603.AA16563@usfvax2.UUCP>
Date: Wed, 4-Mar-87 09:51:46 EST
Article-I.D.: usfvax2.8703041603.AA16563
Posted: Wed Mar  4 09:51:46 1987
Date-Received: Sat, 7-Mar-87 00:38:31 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 49
Approved: protocols@red.rutgers.edu