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
clearer.
> 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
way.
> 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
cribeiro@mail.inet.com.br
-------
[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.