Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] RE: Pause frame usage in transport networks

On Friday 21 February 2003 11:59, Roy Bynum wrote:
> Carlos,
> I agree 100% with your assessment, but only for "packet" services. 

Sure. In fact, PAUSE only makes sense for packet based services, and I assumed 
that the restriction mentioned above was intrinsec to the problem and 
therefore obvious. But it's nice to point it out, if it helps to make things 

> For "Frame Relay", the data link layer is defined to have a from of
> congestion control.  For the Frame Relay protocol, it uses forward explicit
> congestion notification (FECN) and backward explicit congestion
> notification (BECN).  In some respects these operate similarly to "pause"
> MAC Control frames defined in 802.3x.   FECN and BECN are "in-band" with
> the customer traffic and thus belong to, and for the use of the service
> provider.  FECN and BECN are generally set by the service provider for
> network congestion control within the service provider facilities.  FECN
> and BECN might also be seen by the customer's equipment at each end of the
> service, and would be required to respond accordingly

I think that FECN and BECN are miles above PAUSE in terms of complexity and 
results achieved. FECN and BECN are used to define a control system that _in 
theory_ can stabilize traffic at the network level (in fact there is a 
considerable distance between theory and practice, but that's best left for 
the FR or ATM Forum to discuss - FR traffic engineering is not that magical, 
and is very hard to stabilize, in fact). For example, it is possible to set 
up queueing parameters that affect BECN and FECN signaling at each node; fine 
tuning these values is a lot of work, that can kill the entire network if 
done the wrong way. As far as I'm aware, PAUSE frames are local only, and I 
don't know if they are really able to effect the entire network in a positive 

> 802.3x MAC Control frames are in band with the customer traffic in the
> link.  For services that are not "broadband", "packet", or "Frame Relay",
> the specific traffic in the link belongs to the customer and is only for
> the customer's use.  Where the access bandwidth is greater than the
> transmission bandwidth, the transmission facility can issue a message to
> the customer facility that prevents the customer facility from
> "overrunning" the transmission facility.  Within the link, end to end, both
> the access facility at each end and the transmission facility in the middle
> are considered by law to be the temporary "property" of the customer.  This
> is what is meant as a "leased circuit".  The law in most countries treat
> "switched circuits" the same way while the "circuit" is established end to
> end.  For these services, your assessment would not apply, and another from
> of congestion control must be used.  This is where 802.3x will be useable.

Roy, I'm really lost here. By definition, we are talking about a technology 
that is frame based. And as far as I am concerned, PAUSE is only effective 
for frame/packet[1] based services that are not time sensitive[2]. Most 
applications that demand leased-line style circuits are time sensitive. For 
these applications it is better to simply drop late frames - it does not good 
to deliver them late, as they will be not useful anymore. Once you lose a few 
frames it's up to the upper protocol to reconstruct or infer in some way the 
information lost to keep the application running.

That leaves us with non-time sensitive applications that still require 
leased-line service. In this case, we're probably talking about premium 
services, that have be carefully managed, and that probably will be 
configured with conservative bandwidth reservations. In this scenario, PAUSE 
is also probably not that useful, or at least not desirable as the main 
congestion management system. As I said, I think that PAUSE acts as a last 
safety net for abnormal situations - it is useful, it has to be present, but 
no engineer would ever be comfortable relying on it as the main safety device 
on the system.

Am I missing something here?

Carlos Ribeiro

[1]: packet/frame, it's all the same for the purposes of this discussion.
[2]: time sensitive: traffic that is "delay" and/or "delay variance" 
sensitive. PAUSE is bad for both types of traffic.