Subject: RE: On the ATM benchmarking terminology draft.

From: "mike winslow" <[email-masked]>
Date: Wed, 21 Apr 1999 11:22:30 -0400

For what it's worth.. My $.02 worth..

'Cause' is a bad word you are correct.

"may result in" may be a good replacement here.

The impact of Cell loss on AAL5 re-assembly depends upon which cell is lost:

1)A non-ending cell is lost

OR

2)The last cell in frame is lost

In case "1" the arrival of the cell indicating the end of frame results in
Frame Discard due to FCS error.

Case "2" is a bit more complex, as it depends on either the next frame's
arrival, or expiration of the Packet assembly timer of the SAR.

In the event of multiple frames in transit, then you may have two frames
effectively discarded with either a FCS error or with a 'packet too large'
type error (eg. packet assembly continues until the size of the rcvd frame
is > allowable).

in the case of packet too large, this may result in the third frame after
the error being trashed as well.

So, we have a probability function (yet to be stated!) which describes the
number of frames which are lost due to a single cell loss.

In a larger view, the probability of a burst of errors on ATM (seen at the
frame level) is greater than that of a similar frame based connection .

Critical factors being:
Frame re-assembly timeout
Average frame size of arrival
maximum buffer size and

Number of expected frames in a burst from the sender (which may be a
function of high level window size).

Also, you must consider the handling of policing by both the sender as well
as transit switch.  A well regulated sender will avoid excess data rates and
may have more uniformly spaced frame arrivals.

Differences in handling of policing by the switch and the sender tend to
result in higher frame loss as the offered load approaches the policing
limits. (policing is a function of data over time, and I don't see any Bt
parameters in ATM.(Do I?)).

Mike Winslow
Director of Products, North America
Radcom Equipment Inc
1-800-RADCOM4 ext. 304
(pager) 1-800-609-9283
(car)  201-220-3218
(text page) [email-masked]
www.radcom-inc.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kevin Dubray
Sent: Wednesday, April 21, 1999 9:09 AM
To: [email-masked]
Subject: On the ATM benchmarking terminology draft.

Hi!

Section 2.2.2.3 of <draft-ietf-bmwg-call-04.txt>, Cell Error Ratio,
states in the discussion: "CER causes ATM cells to be lost."  Isn't
CER a statistic and not a cause?

Likewise Section 2.2.2.5, Cell Misinsertion Rate, discussion states
"CMR causes ATM streams to be corrupted."   Isn't CMR an indicator to
the degree of disruption in an ATM stream as opposed to a cause?

Contrast the above to section 2.2.2.7, CRC Error Ratio, whose
discussion presents, "CRC errors causes ATM cells to be lost."
While I would have preferred the term "discarded" to lost, I find
this statement closer to the mark...

Two general comments:

1) Are _all_ the related definitions of section 1.2, admittedly
   subsumed from other sources, needed to support the definition
   proposed in section 2.2?  Perhaps the document might benefit by
   including only those background definitions needed to provide
   a basis for section 2.2's definitions.

2) Section 2.2's definitions do a good job of instrumenting the
   ATM layer (a communicated goal), but that layer's instrumentation
   alone doesn't help me benchmark the cross-technology of an
   IP/ATM forwarding device.  For instance, how can I emperically
   ascertain the impact of cell loss or AAL 5 reassembly time on IP
   packet forwarding?  As I understand it, this was a major
   differentiator for this work from other bodies' work.

-Kevin

---

From: "mike winslow" <[email-masked]>
Date: Wed, 21 Apr 1999 11:22:30 -0400

OR

Critical factors being:

Mike Winslow

-----Original Message-----

Hi!

Two general comments:

-Kevin

---

From: Jeffrey Dunn <[email-masked]>
Date: Wed, 21 Apr 1999 23:49:13 -0400

Mike,

> "may result in" may be a good replacement here.

Please see my reply to Kevin.

> 1)A non-ending cell is lost

Meaning a cell whose low order PTI bit is set to zero.
 
> 2)The last cell in frame is lost

Meaning a cell whose low order PTI bit is set to one.
 
> Frame Discard due to FCS error.
 
I do not understand your terminology.  Assuming a user data cell not
experiencing congestion, a PTI=0 cell is lost.  In this case, AAL5
registers a length discrepancy and discards the PDU.  On the other hand,
FCS errors are caused by AAL5 payload errors (assuming that the FCS is
being computed over a MAC layer or FR frame adapted into AAL5).  If the
error occurs before the frame is adapted into AAL5, e.g. before FRF.5 or
FRF.8 does its magic, then the bad frame will pass unmolested through
SAR and should be caught on the non-ATM side of the inter-working
function.  If, on the other hand, the error occurs on the ATM side, AAL5
should register a CRC-32 error and discard the errored PDU.

>Case "2" is a bit more complex, as it depends on either the next 
>frame's arrival, or expiration of the Packet assembly timer of the SAR.
> In the event of multiple frames in transit, then you may have two 
>frames effectively discarded with either a FCS error or with a 'packet 
>too large' type error (eg. packet assembly continues until the size of 
>the rcvd frame is allowable). In the case of packet too large, this may 
>result in the third frame after the error being trashed as well. So, we 
>have a probability function (yet to be stated!) which describes the

Again, I am a bit confused.  I assume that you are equating packet with
AAL5 PDU.  If so, assuming a user data cell not experiencing congestion,
a PTI=1 cell is lost.  As I see it, the possible behavior can be
summarized as follows:

2. A. The AAL5 reassembly timer, which is 250 mS, expires before the
first cell, PTI=0, of the next AAL5 PDU arrives.  The AAL5 PDU with the
missing PTI=1 cell is discarded due to reassembly timeout and one packet
is lost.

2. B. The first cell of the next AAL5 PDU arrives before the reassembly
timer expires.  The AAL5 with the missing PTI=1 cell is prepended to the
next AAL5 PDU in the SAR engine.  This yields two possibilities:

2. B. i. The AAL5 reassembly timer expires before the last cell, PTI=1,
of the next AAL5 PDU arrives.  The AAL5 PDU with the missing PTI=1 cell
and the next AAL5 PDU are discarded due to reassembly timeout and two
packets are lost.

2. B. ii. The last cell of the next AAL5 PDU arrives before the
reassembly timer expires. In this case, AAL5 registers a length
discrepancy and discards the PDU; therefore, the AAL5 PDU with the
missing PTI=1 cell and the next AAL5 PDU are discarded due to their
concatenation and two packets are lost.

Thus, 2. B. i. and 2. B. ii. produce the same result and will simply be
called 2. B.  In addition, RFC 2331 specifies the service type as UBR.
In this case, SAR functions generally segment an AAL5 PDU at full line
rate, meaning that the cell interarrival for cells comprising the same
PDU is usually the minimum for the given line speed.  Viewed in terms of
rates, the PCR is usually line rate.  Assuming that every one is playing
by the rules and the MTU for ATM is 9180, this translates to 192 cells. 
Even at DS-1 speeds, this requires only about 53 mS.  Given a modem with
an effective rate of 32Kb, the packet interarrival time for 512 octet
packets is 128 mS; therefore, even if we allow for some congestion and
CDV, we should rarely, if ever, see AAL5 SAR timeout.  As a result,
cases 2. A. and 2. B. effectively colapse into case 2 in which 2 packets
are lost.

I am not sure where the FCS comes into play here as, in all cases listed
above, PDUs are being discarded at the AAL5 layer.  With respect to
packet too large, again the PDUs are discarded at the AAL5 layer;
therefore, they never reach the IP layer.  As a result, I fail to see
the relevance of 'packet too large' or FCS.

Concerning the PDF of packet loss, I believe that it should be
reasonably easy to express in terms of I.353.  If we allow that cell
error (CE), cell loss (CL) and cell mis-insertion (CM) all result in
AAL5 PDU corruption, then the PDF becomes a conditional probability,
conditioned on error type, and results in the following cases:

1) CE

P(packet loss) = P(CE) 

Pretty simple, as CE causes CRC-32 error and an AAL5 PDU is discarded.

The next two cases are a bit more complex, as they must take into
account the placement of the effected cell in the AAL5 PDU, i.e. PTI,
and weight case 2.  by a factor of 2 in order to get the expectation
value correct.

2) CL

P(packet loss) = P(CL) * P(PTI=0)     Case 1
                 + 2 *  P(CL) * P(PTI=1)   Case 2.

3) CM

P(packet loss) = P(CM) * P(PTI=0)     Case 1
                 + 2 * P(CM) * P(PTI=1)   Case 2.

> frame level) is greater than that of a similar frame based connection .

Given the above PDFs, I disagree.  Assume that the average packet size
is 128 octets. Further, assume that the probability of a burst of errors
is higher than that of an isolated error.  For example, assume that the
probability of 1, 2 and 3 consecutive errors is .1, .3 and .6,
respectively.

1. On a frame based service, the probability of multiple packets being
in error is higher that of an isolated frame being in error, as P(packet
error) = P(frame error) = .1 + 2 * .1 * .3 + 3 * .1 * .3 * .6 = .214

2. On an ATM based service, each packet comprises 3 cells.  The effect
of bursts of CE is as follows:

CE: P(packet error) = .1 + .1 * .3 + .1 * .3 * .6 = .148

CL and CM are similar, if slightly more complex.

> Frame re-assembly timeout

See above.

> Average frame size of arrival

Since reassembly time out has been shown to be relatively unimportant,
frame size will only bear on the effect of the probability of bursts of
errors.

> maximum buffer size and

To which buffer are you refering?  Ingress and egress buffer size will
effect CL and CDV; however, in the UBR world, these parameters are not
guarenteed.
 
> function of high level window size).

Again, assuming UBR, an IP driver which is ATM aware will still burst at
line  or backplane speed. As a result, the time series of cell
interarrival times depends, in the case of TCP, on window size, and, in
the case of UDP, on the backplane speed.  This must also be convolved
with the characteristic transmission unit of the application.  As a
result, ttcp or netperf will act very differently from ftp or MBONE. 
This means that the expected value for burst size (whether in octets,
cells or "frames") may be very hard to come by.

> may have more uniformly spaced frame arrivals.

Not in the case of UBR.

> parameters in ATM.(Do I?)).

Again, TM4.0 rears its ugly head.  Given the injunction in RFC 2331 that
the BE indicator must always be asserted in the ATMTD IE (UBR), I think
that we should take all discussions of the effects of policing and
traffic contracts off line until there is some consensus among the
various "services" camps concerning ATM services.

-- Jeff