IP over T1.6ca

["k1io@FN42jk 08-Oct-1990 1136" <[e-mail]>]

I belong to T1S1 and worked on ANSI T1.6ca, the pending ANS for the 
Frame Relay "Core Aspects" protocol.  We did discuss TCP/IP, in particular 
with regard to congestion control.  Perhaps this will be of use.  Here 
are a few thoughts about how to converge IP over FR.

You can use the FR network two ways.  One is to run an edge-to-edge
connection-mode data link (actually subnetwork, to be an OSIRM purist) 
protocol across the FR.  In that case, flow and congestion across the FR 
are determined by that protocol; the gateway device (IP router) manages 
its own queues as it sees fit, discarding what it must.  The congestion 
avoidance options in T1.6ca can be used in this edge protocol.  Note 
taht this is a lot like X.25; it just moves some of the effort out of 
the network and into the users' edge nodes.

The alternative is to run UI-like frames across the FR, with end-to-end
(TCP) recovery of loss.  In that case the Jacobson dynamic window takes 
care of congestion recovery.  Note though that IP has no congestion 
avoidance (explicit) mechanism, though T1.6ca and for that matter ISO-IP 
(IS8473) do.  Whether that helps or hinders the TCP/IP user depends upon 
the way the network protects itself.  

A network that has full-bore congestion avoidance, with leaky-bucket
enforcement, may discard "excess" frames (the ones sent by users who 
don't take the hint from explicit congestion avoidance signaling) a bit
more rapidly than one that doesn't.  So a user who doesn't slow down
when told is more likely to lose a packet and hit the "cliff", which
will cause a much more severe slowdown.  But if the FR network doesn't
enforce congestion avoidance (by selective discard) and just puts what
it can't handle into the bit-bucket, then the TCP users (with no 
explicit congestion avoidance slowdowns) will tend to "win", by hogging
the network during periods of mild congestion. 

If the FR network is public, it'll probably have a time component to its 
cost, as well as a per-frame component.  Tariffs aren't filed yet but FR 
tends to have more bandwidth reservation than X.25, which will lead 
telcos to charge for VCs.  So you may end up with a demand for 
time-cutting, too, not unlike ISDN circuit mode. 
     fred