Subject: Re: On the ATM benchmarking terminology draft.

From: Jeffrey Dunn <[email-masked]>
Date: Wed, 05 May 1999 21:47:11 -0400

Mike,

Again, I address your message below:

>mike winslow wrote:

> Three points of clarification:

> -I refer to FCS error more in the sense of "error detected". Whether the SAR

> detects the error as length, or as FCS error is likely dependent on the SAR

> . (eg nearly every length error will likely be an FCS error).

> (I'm glad that I at least changed my references to "CRC" over to "FCS"

> before I hit 'send').

Recall that AAL5 reassembly occurs before an encapsulated FR or 802.X

frame is passed from the ATM to the other side of an Inter Working

Function (IWF).  As a result, if the error occurs on the ATM side (the

subject of the ID), then AAL5 discards the PDU and the other side is
none

the wiser.  If the error occurred before the frame was encapsulated,
then

AAL5 is none the wiser and error processing proceeds after the frame is

on the other side.  There is a non-subtle difference between Frame Check

Sequence (FCS) and AAL Cyclic Redundancy Check 32 bit (CRC-32).  In the

BISN model, ALL errors will be processed first and FCS will never

come into play.

> -The point of perspective of 'frame' or 'packet' in this context is an AAL5

> PDU delivered by the sender as cells on the ATM.

Fair enough; however, as implied above, each layer must be treated

separately.

> -Reference to buffer size refers to the packet reassembly buffer allocated

> to this VPI/VCI.

I still do not understand.  If you are referring to the AAL reassembly

buffer, this has a constant size of 65535 octets.  If you are referring

to an IP packet fragmentation reassembly buffer, this is typically very

large (greater than 6MB on HP-UX machines).

> A comment: SAR re-assembly timeout is an important factor. I'm not sure that

> everyone understands the potential impact of this. You make mention to a

> 250Ms timeout, but I do not believe that there is a standard value here. In

> fact, this value is likely buried and well hidden (versus prominent) in the

> configuration if it is available at all.

Mea culpa.  I do not have a copy of I.363 handy; therefore, I must table

this point until I hear back from my friends with ITU-T specification

access (read deep pockets).

> A point: In LANE, arguably one of the largest deployed applications of ATM

> (in ports and signalling : typically campus environment), the client setup

> messages indicate a <1600 byte AAL5 PDU size (Ethernet).

I will not argue your comment about LANE deployment.  With respect to

AAL PDU size, the MTU for 803.3 is 1500 octets.  With 18 octets for

source and destination MAC addresses and FCS, this yields 1518 octets. 

In addition, LANE prepends 16 octets of LANE specific information

yielding 1534 octets. This will not fit into 32 cells along with the 8

octet AAL trailer; therefore, the AAL PDU size is 33 cells or 1585. 

This does not, however, effect the estimates of the average packet size

on the U.S. Internet which is 128 octets.

> As you say, in a UBR environment, cell arrivals for a given PDU (assuming

> only one stream of data), are at line rate.

Acknowledged.

> Given say a TCP/IP connection with a window of say 8k, it would therefore be

> likely to see multiple contiguous frames of contiguous cells in the stream.

Acknowledged.  The exact number of cells depends on the state of the TCP

connection, i.e. where the connection is in the slow start and/or

congestion avoidance process.

> IF the last cell of the first frame is lost, the SAR process runs out of

> re-assembly space on the second or third cell of the second frame (AAL5 PDU,

> sorry.. habit). (First frame is lost/discarded)

I do not follow this reasoning.  The largest applicable MTU is 9180. 

Twice this value is still far less than the maximum AAL PDU size of

65535.  IMHO, AAL reassembly should never run out of memory.  Analyzing

the AAL layer only, if the terminal cell (PTI=1) of an AAL PDU is

lost, the MTU limits the size of the concatenated PDU to 383 cells or

18384 octets.  When we play by the RFC 2225 rules or 802.3 MTU size

rules, AAL will never run out of memory.

> Next cell arrival is cell 'N' (say 4) of PDU 2. The SAR sees this as a new

> frame, and collects cells till the PTI=1 cell arrives or re-assembly timeout

> occurs. Again, the original assumption here was two PDU's, so this

> particular case is a FCS/Length error during re-assembly.

I fail to see why the arrival of a PTI=0 cell would trigger SAR.  Assume

that the AAL PDU contains a 1500 octet IP message transported over

802.3 with an LLC/SNAP codepoint prepended and LANE junk as well.  The

original AAL PDU size is 33 cells.  If cell 33 of one frame is lost,

cells 1 to 33 of the next frame roll up and are appended to the 32 cells

of the original AAL PDU.  On receiving cell 33 of the second PDU, SAR

detects PTI=1 and tries to reassemble the mess.  SAR registers a length

error and aborts the process resulting in the loss of two AAL PDUs

(Ethernet frame, IP packets, etc.).

> I think that you substantiate this in 2.B

> I apologize in advance (It's not that I could express it better), but the

> probability function which describes the nature of Cell loss needs to

> recognize that  P(CL) for cells increases with the number of cells in a

> burst (or group of frame/packet/PDU's), therefore you might expect that the

> most likely cell loss would occur in the last cell of the last frame of a

> burst. This would increase the probability of a re-assembly timeout.

Although P(CL) is positively correlated to burst length, the actual

cells which will be lost is more a function of switch architecture than

cell ordering.  Assume that at some point during a cell burst a switch

becomes congested, the following should happen:

1. Cells at the ingress port which cannot be delivered to the egress

port due to congestion are dropped.

2. The switch manufacturer pays attention to the AAL type IE and

implements EPD.  All cells in an AAL PDU which has had one of its cells

dropped by CAC are discarded.

Further, given that the burst size (in cells) is a random variable which

is not highly correlated to the frame number or size, I fail to see why

the last cell in the last frame is more at risk than any other cell.  If

we assume that the segment/packet/frame ALL PDU size is predicated on

the state of a layer 4, e.g. TCP, connection, then the IP packets will

be of variable size and there is no way to correlate the last cell in

the stream to cell loss.

> Why would P(CL) be greater for larger bursts? There are a number of reasons:

> One of which may be switching congestion, another may be policing (not

> relevant to UBR(?)). (I wholeheartedly agree that policing has many

> complexities)

Agreed, if P(CL) is a monotonically increasing function of MBS, we can
assume that buffer size and switch capacity will play a role in
determining this function; however, I still do not concede your point
that the last cell of the frame is the most likely to be lost.

> I guess that my original point, simply stated is that ATM AAL5 introduces

> the probability than an error in a  frame is the cause of the discard of

> next frame (PDU). I don't think that this occurs on non-cell/non-policed

> networks. We have a history dependent P(E) here.

True enough.  IP fragmentation re-assembly takes place at the IP service
layer; therefore, it is not effected by the DLL.  Once said, the fact is
that 802.X or FR frame loss have the same effect on IP SAR as AAL/5 PDU
loss.  More to the point, if everyone is playing by the rules, MTU
discovery will take care of IP PDU fragmentation and there will be a
one-to-one correspondence between AAL PDU corruption and IP PDU loss,
with the proviso that AAL SAR errors may cause two IP PDUs to be lost.

> A new point:

> The effect of Cell Misinsertion is not expected on UBR connections. I

> actually saw it once, but this was a bug in a version of hardware for the

> switch (not the edge device!).

P(CM) is an increasingly small number; however, I.353 calls out this
specific impediment.  As a result, I feel that it is pertainent to this
document.

Regards,

Jeff

-- 

Jeffrey H. Dunn

Phone: 410 730 6300

FAX: 410 730 1412

Email: [email-masked]

> -----Original Message-----

> From: [email-masked]

> [mailto:[email-masked]]

> Sent: Wednesday, April 21, 1999 11:48 PM

> To: [email-masked]

> Cc: Jeffrey H. Dunn; [email-masked]

> Subject: Re: On the ATM benchmarking terminology draft.

> Importance: High

> Mike,

> I address your points below:

> > 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.

> Please see my reply to Kevin.

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

> lost:

> > 1)A non-ending cell is lost

> Meaning a cell whose low order PTI bit is set to zero.

> > OR

> > 2)The last cell in frame is lost

> Meaning a cell whose low order PTI bit is set to one.

> > In case "1" the arrival of the cell indicating the end of frame results in

> > 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

> > number of frames which are lost due to a single cell loss.

> 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.

> > 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 .

> 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.

> > Critical factors being:

> > 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.

> > Number of expected frames in a burst from the sender (which may be a

> > 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.

> > 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.

> Not in the case of UBR.

> > 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?)).

> 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

---

From: "mike winslow" <[email-masked]>
Date: Thu, 6 May 1999 09:08:28 -0400

A quick note:

While AAL5 can accommodate 65535 byte PDU, many implementations do not
provide or allow for this due to memory constraints. Often times, a
developer will tell the SAR to only allow for 2000 bytes of memory for the
re-assembled PDU.

This allows the implementation to handle more active VPI/vci pairs for a
given amount of memory.

I cannot state specific instances as some companies may feel this to be
proprietary.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, May 05, 1999 9:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: On the ATM benchmarking terminology draft.
Importance: High

Mike,

come into play.

separately.

Acknowledged.

the stream to cell loss.

Regards,

Jeff

--

Jeffrey H. Dunn

Phone: 410 730 6300

FAX: 410 730 1412