Re: OAMP Etc.

[Roy Bynum <rabynum@xxxxxxxxxxx>]

Mick,

I am not sure where the idea came from that flow control stops traffic flows.
Flow control acts to restrict the bandwidth available to traffic over the
transmission system.  I have set up tests that cascade restricted flow control
over multiple layers of data switches and transmission links without loosing any
traffic and not stoping any one flow.  I have even sent GbE through restricted
OC12 links without loosing data traffic.

Yes, for elements (network data switches)  that have more incoming traffic than
bandwidth is available for outgoing traffic, system buffers are used.  When
system buffers become overloaded data traffic is lost.  When data traffic is
lost at a point inside the transmission system, it is often resent over the same
transmission system.

With flow control, the storage of traffic is spread to multiple elements,
increasing the overall buffer storage capacity without raising it for any one
element.  When the element system buffers do not become overloaded, less data
traffic is lost.  When data traffic is not lost, the applications do not have to
resend it.  When applications do not have to resend data, the applications
communications is more stable with less delays.  By logical extension, a
universal implementation of flow control within an enterprise nework makes the
enterprise network applications more stable with less delays.

Am I missing something here?  Is there something about flow control that I have
not tested for?  Can you suggest a specific configuration that I can set up and
test?  If you can help me identify a specific problem, other than a failure to
implement it on all elements, I would appreciate it.  If you can help me
identify a problem that can be avoided by not implementing universal flow
control, it will help me design and implement better enterprise data networks
for MCIW and its customers.

Thank you,
Roy Bynum,
Optical and Data Network Technology Development
MCI WorldCom


Mick Seaman wrote:

> Link aggregation can be used to support redundant unused links if you wish,
> either explictly or by choice of distribution algorithm.
>
> I am not sure whether you are arguing for introducing the complexity of flow
> control below or not. In any case it is the wrong answer. Service is not
> improved by stopping traffic flows. In any case they won't get stopped right
> back to the originating application, they'll build up and get discarded in
> some buffer somewhere. The right answer is to differentiate between the
> services (as per .1p and Diffserv) and making sure that the higher grade
> traffic levels have spare capacity (as you suggest in your first para). Then
> link aggregation can be used as Fred suggests to spread the traffic around
> with the result that the network can sustain higher levels of 'best effort'
> or 'background ' service in the absence of failure, while satisfactorily
> handling admission controlled high priority/expensive/committed traffic even
> if there is a failure. That's better economics.
>
> Net net we don't need more embedded stuff in the data link. It took us years
> to figure this out, throwing out the use of X.25 and LAPB/SDLC on high speed
> links, and we don't need to go back there.
>
> Mick
>
> > -----Original Message-----
> > From: Roy Bynum [SMTP:rabynum@xxxxxxxxxxx]
> > Sent: Friday, June 25, 1999 7:50 PM
> > To:   Fred Weniger
> > Cc:   'HSSG_reflector'
> > Subject:      Re: OAMP Etc.
> >
> >
> > Fred,
> >
> > Interesting that you should suggest this.  Oddly enough, having
> > redundant fiber turns out to be cheaper for protocols that do not have
> > active flow control.  People, operations costs, cost the carriers more
> > than making use of "spare" capacity when liquidated damages are part of
> > most service level agreements.
> >
> > Link aggregation at L2 does not always map L3 path route aggregation
> > because "over subscription" can not be controled in the case of a
> > partial "link route" failure.  In the case using active flow control
> > over bridged, not routed systems, "over subscription" should be
> > controlable.  This is one of the differences between what some people
> > are used to accepting as the cost of doing business, and people who are
> > always chalanging the "religiously accepted" way of thinking.
> >
> > Thank you,
> > Roy Bynum
> > Fred Weniger wrote:
> > >
> > > Pardon my naivete, but if people start demanding idle backup paths in
> > 10GbE
> > > WAN links, as are to be found in SONET rings (correct?), shouldn't the
> > > discussion at least include a comparison of the benefits of Ethernet
> > link
> > > aggregation, i.e., when multiple links are all carrying Ethernet packets
> > > between two points, and if one link goes down, the remaining links
> > continue
> > > to carry data.  The benefit is the full utilization of all available
> > data
> > > paths, with no available link sitting there idle.
> > >
> > > Fred Weniger
> > > Product Marketing Manager, Gigabit Products
> > > Vitesse Semiconductor Corporation
> > > 741 Calle Plano, Camarillo, CA 93012
> > > Phone: 805-388-7571   Fax: 805-987-5896
> > > E-mail: weniger@xxxxxxxxxxx