Re: [EFM] RE: Pause frame usage in transport networks
Carlos,
You said:
"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?"
Actually, you are. We did a lot of testing of active flow control, both in
the local link and in long haul end to end services. What we found may not
be intuitively apparent.
In the local only link for P2P leased line services, active flow control
in the short distance of the link acted to gracefully reduce the traffic
transfer rate without effecting latency variance (Base line latency
variance of EOS is 125us because of the OAM frame window.) and prevented
data loss when attempting to push over the transmission line supportable
transfer rate bandwidth. We tested this by turning flow control rate
adaptation off and on and comparing the results at 90% utilization. We did
find that, depending on the distance between the transmission node and the
customer equipment, the available transfer rate was slightly reduced with
active flow control turned on. Without active flow control rate
adaptation, the transfer rate would go to 98/99% utilization and then
dramatically fail do to frame loss as the available transfer rate was
exceeded. At this point, retransmissions reduced the effective transfer
rate to well below the effective rate provided by the use of active flow
control.
The dropped packets and retransmissions also dramatically increased the
latency variance relative to the end to end distance of the P2P leased line
link. Any form of rate adaptation that uses "dropped" packets greatly
effects latency variance which gets translated to apparent end to end
latency by any application that is communicating across the P2P leased line
link.
Regardless of the protocol that is used, all TDM transmission facilities
induce a 125us latency variance at the customer data link layer. This is
because the transmission convergence mapping is based on a specific payload
window that occurs every 125us in SONET framing. In testing we found that
GbE has a baseline worst case latency variance of 12us regardless of the
vendor and 100base T has a latency variance of 120us regardless of the
vendor. We found that the latency variance of multiple switches in series
with multiple traffic paths through the switches, the end to end latency
variance tended to increase at a somewhat RMS value instead of a directly
additive value.
Using pause frames end to end tended to greatly reduce the available data
transfer rate in a P2P leased line link. Compared to 95% -97% that was
achieved when using flow control only in the local link at each end, end to
end 60% utilization was a dramatic reduction. But since there were no
retransmissions, that 60% utilization was the true effective
utilization. Depending on the way that the pause frame operands are
defined, additional latency variance that is directly related fixed
distance latency can be induced. Properly configured pause frame operands
tended to provide the same latency variance as the local only use,
125us. We can talk off line as to what those configuration differences are.
Basically, what I found in over 2 years of testing was that the use of
802.3x active flow control actually improved the performance and
reliability of data communications better than any other type of rate
adaptation. For applications that are severely time critical, like the SNA
scanning applications used by banks, the use of Ethernet as the Data Link
protocol, with Ethernet over SONET and active flow control in the local
link of P2P leased lines is perhaps the best possible solution. Over a
period of time, as more of the EOS technology gets rolled out, vendors that
provide X.86 will be able to prove that they provide a dramatic improvement
in performance and reliability over other EOS technologies and older
technologies based on HDLC/SDLC/PPP as the Data Link protocol.
Thank you,
Roy Bynum
At 07:59 PM 2/21/2003 -0300, Carlos Ribeiro wrote:
>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?