From owner-stds-802-3-etholaps@ieee.org Tue Oct 3 13:46 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id NAA24486 for ; Tue, 3 Oct 2000 13:46:47 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA6ECF for ; Tue, 3 Oct 2000 13:45:03 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id IAA20735; Tue, 3 Oct 2000 08:45:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20001003074320.00ab7ee0@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Oct 2000 07:44:21 -0500 To: "Ethernet over LAPS"@mindspring.com, From: Roy Bynum Subject: Hello, anyone here? Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 8 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 77 Hello, Has anyone subscribed to this reflector yet? Thank you, Roy Bynum From owner-stds-802-3-etholaps@ieee.org Tue Oct 3 13:57 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id NAA24584 for ; Tue, 3 Oct 2000 13:57:36 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA6EDE for ; Tue, 3 Oct 2000 13:55:51 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id IAA22197; Tue, 3 Oct 2000 08:55:48 -0400 (EDT) Message-ID: From: Vivek Mishra To: "Ethernet over LAPS"@mindspring.com, stds-802-3-etholaps@ieee.org Subject: RE: Hello, anyone here? Date: Tue, 3 Oct 2000 18:24:57 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02D39.225B68F0" X-Lines: 70 Status: RO Content-Length: 1553 ------_=_NextPart_001_01C02D39.225B68F0 Content-Type: text/plain; charset="iso-8859-1" X-Sun-Content-Length: 314 Hi, I am here vivek -----Original Message----- From: Roy Bynum [mailto:rabynum@mindspring.com] Sent: Tuesday, October 03, 2000 6:14 PM To: "Ethernet over LAPS"@mindspring.com; stds-802-3-etholaps@ieee.org Subject: Hello, anyone here? Hello, Has anyone subscribed to this reflector yet? Thank you, Roy Bynum ------_=_NextPart_001_01C02D39.225B68F0 Content-Type: text/html; charset="iso-8859-1" X-Sun-Content-Length: 968 RE: Hello, anyone here?

Hi,
I am here

vivek

-----Original Message-----
From: Roy Bynum [mailto:rabynum@mindspring.com]
Sent: Tuesday, October 03, 2000 6:14 PM
To: "Ethernet over LAPS"@mindspring.com; stds-802-3-etholaps@ieee.org
Subject: Hello, anyone here?



Hello,

Has anyone subscribed to this reflector yet?

Thank you,
Roy Bynum

------_=_NextPart_001_01C02D39.225B68F0-- From owner-stds-802-3-etholaps@ieee.org Tue Oct 3 17:50 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id RAA26399 for ; Tue, 3 Oct 2000 17:50:40 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA709E for ; Tue, 3 Oct 2000 17:48:55 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id MAA05067; Tue, 3 Oct 2000 12:48:51 -0400 (EDT) From: pat_thaler@agilent.com Message-ID: <1BEBA5E8600DD4119A50009027AF54A00313E340@axcs04.cs.itc.hp.com> To: rabynum@mindspring.com, "Ethernet over LAPS"@mindspring.com, stds-802-3-etholaps@ieee.org Subject: RE: Hello, anyone here? Date: Tue, 3 Oct 2000 10:48:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 22 Status: RO Content-Type: text/plain; charset="iso-8859-1" Content-Length: 428 Roy, I'm on the reflector. The administrator of the list should be able to get a list of those who've signed up from majordomo. Pat -----Original Message----- From: Roy Bynum [mailto:rabynum@mindspring.com] Sent: Tuesday, October 03, 2000 5:44 AM To: "Ethernet over LAPS"@mindspring.com; stds-802-3-etholaps@ieee.org Subject: Hello, anyone here? Hello, Has anyone subscribed to this reflector yet? Thank you, Roy Bynum From owner-stds-802-3-etholaps@ieee.org Tue Oct 3 19:38 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id TAA27126 for ; Tue, 3 Oct 2000 19:38:51 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA7167 for ; Tue, 3 Oct 2000 19:37:07 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id OAA24856; Tue, 3 Oct 2000 14:36:54 -0400 (EDT) Message-ID: From: "David Martin" To: Roy Bynum , "Ethernet over LAPS"@mindspring.com, stds-802-3-etholaps Subject: RE: Hello, anyone here? Date: Tue, 3 Oct 2000 14:34:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02D68.84025D10" X-Lines: 101 Status: RO Content-Length: 2605 ------_=_NextPart_001_01C02D68.84025D10 Content-Type: text/plain; charset="iso-8859-1" X-Sun-Content-Length: 454 I'm on. ...Dave David W. Martin Nortel Networks +1 613 765-2901 dwmartin@nortelnetworks.com ======================== -----Original Message----- From: Roy Bynum [SMTP:rabynum@mindspring.com] Sent: Tuesday, October 03, 2000 8:44 AM To: "Ethernet over LAPS"@mindspring.com; stds-802-3-etholaps Subject: Hello, anyone here? Hello, Has anyone subscribed to this reflector yet? Thank you, Roy Bynum ------_=_NextPart_001_01C02D68.84025D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sun-Content-Length: 1835 RE: Hello, anyone here?

I'm on.

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
dwmartin@nortelnetworks.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

    -----Original = Message-----
    From:   Roy Bynum = [SMTP:rabynum@mindspring.com]
    Sent:   Tuesday, October 03, 2000 8:44 AM
    To:     "Ethernet over LAPS"@mindspring.com; = stds-802-3-etholaps
    Subject:       = Hello, anyone here?


    Hello,

    Has anyone subscribed to this = reflector yet?

    Thank you,
    Roy Bynum

------_=_NextPart_001_01C02D68.84025D10-- From owner-stds-802-3-etholaps@ieee.org Tue Oct 3 21:25 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id VAA27853 for ; Tue, 3 Oct 2000 21:25:39 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA7210 for ; Tue, 3 Oct 2000 21:23:55 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id QAA14888; Tue, 3 Oct 2000 16:23:47 -0400 (EDT) Date: Tue, 3 Oct 2000 13:24:09 -0700 (PDT) From: Thomas Dineen Reply-To: Thomas Dineen Subject: RE: Hello, anyone here? To: rabynum@mindspring.com, stds-802-3-etholaps@ieee.org Cc: tdineen@redback.com MIME-Version: 1.0 Content-MD5: NC2UjxrwnQQ6W8vJhRzSmg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Message-Id: <20001003202341.C409C17BC01@postal.redback.com> Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 25 Status: RO Content-Type: TEXT/plain; charset="us-ascii" Content-Length: 300 No, Roy your are the only one. No one is here except us chickens. What about: "Ethernet over LAPS"@mindspring.com is this a seperate reflector? Thanks for the help. Thomas Dineen > Hello, > > Has anyone subscribed to this reflector yet? > > Thank you, > Roy Bynum > From owner-stds-802-3-etholaps@ieee.org Wed Oct 4 00:17 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id AAA28997 for ; Wed, 4 Oct 2000 00:17:40 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA7316 for ; Wed, 4 Oct 2000 00:15:56 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id SAA12508; Tue, 3 Oct 2000 18:56:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20001003175405.00abbe70@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Oct 2000 17:55:38 -0500 To: Thomas Dineen , From: Roy Bynum Subject: RE: Hello, anyone here? Cc: tdineen@redback.com In-Reply-To: <20001003202341.C409C17BC01@postal.redback.com> Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 34 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 540 Tom, "Ethernet over LAPS"@mindspring.com was a miss-address within my Eudora e-mail. I have corrected the mistake. Thanks for noticing. Roy At 01:24 PM 10/3/00 -0700, Thomas Dineen wrote: > No, Roy your are the only one. > > No one is here except us chickens. > > What about: > > "Ethernet over LAPS"@mindspring.com > > is this a seperate reflector? > > >Thanks for the help. >Thomas Dineen > > > > Hello, > > > > Has anyone subscribed to this reflector yet? > > > > Thank you, > > Roy Bynum > > From owner-stds-802-3-etholaps@ieee.org Wed Oct 4 15:27 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA05717 for ; Wed, 4 Oct 2000 15:27:22 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA5B5 for ; Wed, 4 Oct 2000 15:25:37 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id KAA00586; Wed, 4 Oct 2000 10:25:21 -0400 (EDT) Cc: rabynum@mindspring.com, "Ethernet over LAPS"@mindspring.com, stds-802-3-etholaps@ieee.org Message-ID: <39DB3DC3.37C31D9E@lucent.com> Date: Wed, 04 Oct 2000 16:25:07 +0200 From: Erik van Oosten Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: pat_thaler@agilent.com Original-CC: rabynum@mindspring.com, "Ethernet over LAPS"@mindspring.com, stds-802-3-etholaps@ieee.org Subject: Re: Hello, anyone here? References: <1BEBA5E8600DD4119A50009027AF54A00313E340@axcs04.cs.itc.hp.com> Content-Transfer-Encoding: 7bit Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 19 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 213 > Hello, > > Has anyone subscribed to this reflector yet? > > Thank you, > Roy Bynum I am here. Is there an archive? Erik. -- * Erik van Oosten * Lucent Technologies, ONG * mailto:evoosten@lucent.com From owner-stds-802-3-etholaps@ieee.org Fri Oct 6 14:34 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id OAA25373 for ; Fri, 6 Oct 2000 14:34:18 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA1C12 for ; Fri, 6 Oct 2000 14:32:34 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id JAA22839; Fri, 6 Oct 2000 09:32:28 -0400 (EDT) Message-ID: <39DDD23B.60E1450D@lucent.com> Date: Fri, 06 Oct 2000 15:23:07 +0200 From: Erik van Oosten Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: stds-802-3-etholaps Subject: Why EthoLAPS discusion in IEEE? Content-Transfer-Encoding: 7bit Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 18 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 508 Hi, I wonder why this e-mail list was setup? EthoLAPS to me seems to be a competitor of the GPF (Generic Packet Framing) from T1X1.5. I donot see any overlap or connection points with IEEE (except for the name Ethernet of course). Please understand I do not want to kill any discussion. I only want the right people to be in the discussion. Regards, Erik. -- * Erik van Oosten * Lucent Technologies, ONG, PMG/Network Architecture * Mailto:evoosten@lucent.com * Http://hzswww.nl.lucent.com/~evoosten From owner-stds-802-3-etholaps@ieee.org Fri Oct 20 20:17 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id UAA20718 for ; Fri, 20 Oct 2000 20:17:39 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA651 for ; Fri, 20 Oct 2000 20:15:54 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id PAA01387; Fri, 20 Oct 2000 15:14:02 -0400 (EDT) Message-ID: From: "David Martin" To: stds-802-3-etholaps Subject: Comments On LAPS Date: Fri, 20 Oct 2000 15:04:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AC8.A1A79AC0" X-Lines: 397 Status: RO Content-Length: 16668 ------_=_NextPart_001_01C03AC8.A1A79AC0 Content-Type: text/plain; charset="iso-8859-1" X-Sun-Content-Length: 5945 All, Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. Background LAPS is a modified version of PPP with the following similarities: * Uses the same HDLC-like frame * Uses the same byte-stuffing / flag pattern delineation mechanism * Supports only point-to-point Layer 2 topology (i.e. no address/label fields) Differences wrt PPP: * Uses a much-simpler version of Link Control Protocol (no 'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 actions, and 11 LCP frame formats") * Uses the 'Address' field to identify among IPv4, IPv6, etc. (PPP fixes it as FF). The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean that LAPS shares the same drawbacks in throughput performance and the service effects of flag/byte-stuffing delineation. The following elaborates on these issues. Comments Packet based traffic generally requires received frames to be error-free. Any frames lost due to bit errors within the frame payload or due to loss of frame delineation will usually trigger a request for re-transmission at a higher layer. The re-transmission requests will then generate more traffic. This positive feedback mechanism makes frame loss performance an important parameter for packet-based traffic in general. Three aspects of throughput are discussed: deterministic versus statistical behaviour, the effect of frame inflation on throughput, and the effect of delineation performance on throughput. 1. Deterministic vs Statistical Throughput All currently defined Ethernet physical layers provide a deterministic throughput capacity. The throughput capacity is independent of the data contents. This is an important attribute, since it permits predictable performance. For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a unique one-byte pattern is used to detect both beginning and end of each frame. To ensure the flag pattern is unique, any occurrences of it must be removed from the data prior to encapsulation. This is done by replacing each occurrence of the flag pattern with a sequence of two bytes: a special 'escape' byte, followed by a slightly modified version of the flag pattern. Because of its special meaning, the 'escape' character must also be 'escaped'. Consequently, the frame length of the payload is inflated in a non-deterministic manner. Since two byte patterns are replaced by pairs of bytes, the probability that a random data byte will be 'escaped' is p = 1/128. For a frame F bytes long prior to 'escaping', the average frame-length after 'escaping' will be: F' = F + m bytes Where F is the un-escaped frame length in bytes m is the mean of the distribution of the number of bytes that must be escaped in the original F-byte frame Assuming random data the number of bytes 'escaped' per F-byte frame follows a binomial distribution with: probability of 'success': p = 2/256 = 1/128 probability of 'failure': q = 1 - p = 127/128 number of trials: n = F mean of the distribution is: m (mu) = np = F*(1/128) bytes standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 The tail of this distribution is extremely long: it reaches zero only after a potential doubling of the frame size. Non-Random Data The assumption of random data could easily be invalidated by applications that happen to produce the escaped octet values more frequently than a random process would. Vulnerability to Emulation Attacks The inflation problem is aggravated by the possibility of emulation attacks. Malicious users can generate frames with a high density of octet values which must be 'escaped'. This definitely invalidates the assumption of random data and skews the distribution towards the worst-case of a doubling of frame size. Service-Impacting Effects of Non-Deterministic Inflation The non-deterministic inflation imposed by LAPS byte stuffing could make tightly controlled frame delay variation (with acceptable absolute delays) very difficult if not impossible to achieve. The quality of frame-based real-time services, such as voice-over-IP, would suffer as a consequence. 2. LAPS Frame Inflation: Effect on Throughput The throughput capacity of an error-free link is inversely related to the overhead required by a given encapsulation mechanism. The inflation introduced by LAPS reduces throughput in a non-deterministic manner, by adding more overhead in an error-free environment. Once errors are introduced, throughput is diminished in two ways: random errors occurring within the frame; and frames lost through loss of delineation. For frames on a link with given BER, the probability of errors within the frame are a function of the frame length: the longer the frame the higher the probability of an error occurring in the frame. As seen above, LAPS inflation can significantly increase the frame length. This degrades the throughput by providing a larger target for random errors to hit. 3. LAPS Delineation Performance: Effect on Throughput The second factor affecting throughput on a link with non-zero BER is frame delineation. It is also affected by choice of encapsulation. LAPS frames rely on error-free matches to the flag pattern to indicate start and end of frame for every frame. This leads to an unnecessarily high probability of lost frames due to loss of delineation. This in turn contributes to a lower absolute throughput than could be realized with a more robust delineation mechanism. More robust delineation mechanisms are possible that are designed to be error-tolerant. This allows them to coast through random bit errors that would defeat a flag delineation mechanism. This would reduce the number of frames lost due to delineation failures. Conclusion Mapping approaches for Ethernet over SONET/SDH which do not use flag-based delineation are preferable. David W. Martin & Tim Armstrong Nortel Networks ========================= ------_=_NextPart_001_01C03AC8.A1A79AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sun-Content-Length: 10405 Comments On LAPS

All,

Some comments on LAPS (Draft X.86, = April 2000) to get the ball rolling.

Background

LAPS is a modified version of PPP with = the following similarities:

    ·       Uses the same HDLC-like frame
    ·       Uses the same byte-stuffing / flag pattern delineation = mechanism
    ·       Supports only point-to-point Layer 2 topology (i.e. no = address/label fields)

Differences wrt PPP:

    ·       Uses a much-simpler version of Link Control Protocol (no = 'Protocol' field, so no LCP frames; only 2 states instead of "16 = events, 12 actions, and 11 LCP frame formats")

    ·       Uses the 'Address' field to identify among IPv4, IPv6, = etc. (PPP fixes it as FF).

The simplified LCP is laudable, but = the similarities to PPP/HDLC/SDH mean that LAPS shares the same = drawbacks in throughput performance and the service effects of = flag/byte-stuffing delineation. The following elaborates on these = issues.

Comments

Packet based traffic generally = requires received frames to be error-free. Any frames lost due to bit = errors within the frame payload or due to loss of frame delineation = will usually trigger a request for re-transmission at a higher layer. = The re-transmission requests will then generate more traffic. This = positive feedback mechanism makes frame loss performance an important = parameter for packet-based traffic in general.

Three aspects of throughput are = discussed: deterministic versus statistical behaviour, the effect of = frame inflation on throughput, and the effect of delineation = performance on throughput.

1.      = Deterministic vs Statistical Throughput

All currently defined Ethernet = physical layers provide a deterministic throughput capacity. The = throughput capacity is independent of the data contents. This is an = important attribute, since it permits predictable performance. =

For byte-oriented LAPS, frame = delineation uses a simple flag mechanism: a unique one-byte pattern is = used to detect both beginning and end of each frame. To ensure the flag = pattern is unique, any occurrences of it must be removed from the data = prior to encapsulation. This is done by replacing each occurrence of = the flag pattern with a sequence of two bytes: a special 'escape' byte, = followed by a slightly modified version of the flag pattern. Because of = its special meaning, the 'escape' character must also be 'escaped'. = Consequently, the frame length of the payload is inflated in a = non-deterministic manner. Since two byte patterns are replaced by pairs = of bytes, the probability that a random data byte will be = 'escaped' is p =3D 1/128.

For a frame F bytes long prior to = 'escaping', the average = frame-length after 'escaping' will be:    F' =3D F = + m bytes

Where  F =        is the un-escaped frame length in = bytes

      m       is the mean of the distribution of the number of bytes = that must be escaped in the original F-byte frame

Assuming random data the = number of bytes 'escaped' per F-byte frame follows a binomial = distribution with:

probability of 'success': =       =         p =3D 2/256 =3D 1/128
probability of 'failure': =       =         q =3D 1 - p =3D = 127/128
number of = trials:       =         =         =         n =3D F
mean of the distribution is: =    m (mu) =3D np =3D F*(1/128) bytes
standard deviation is:  =         s (sigma) =3D sqrt (npq) =3D sqrt (F*127) / = 128

The tail of this distribution is = extremely long: it reaches zero only after a potential doubling of the frame size.

Non-Random Data

The assumption of random data could = easily be invalidated by applications that happen to produce the = escaped octet values more frequently than a random process would.  =

Vulnerability to Emulation = Attacks

The inflation problem is aggravated by = the possibility of emulation attacks. Malicious users can generate = frames with a high density of octet values which must be 'escaped'. = This definitely invalidates the assumption of random data and skews the = distribution towards the worst-case of a doubling of frame size.  =

Service-Impacting Effects of = Non-Deterministic Inflation

The non-deterministic inflation = imposed by LAPS byte stuffing could make tightly controlled frame delay = variation (with acceptable absolute delays) very difficult if not = impossible to achieve. The quality of frame-based real-time services, = such as voice-over-IP, would suffer as a consequence.   

2.      LAPS = Frame Inflation: Effect on Throughput

The throughput capacity of an = error-free link is inversely related to the overhead required by a = given encapsulation mechanism. The inflation introduced by LAPS reduces = throughput in a non-deterministic manner, by adding more overhead in an = error-free environment.

Once errors are introduced, throughput = is diminished in two ways: random errors occurring within the frame; = and frames lost through loss of delineation.

For frames on a link with given BER, = the probability of errors within the frame are a function of the frame = length: the longer the frame the higher the probability of an error = occurring in the frame. As seen above, LAPS inflation can significantly = increase the frame length. This degrades the throughput by providing a = larger target for random errors to hit.

3.      LAPS = Delineation Performance: Effect on Throughput

The second factor affecting throughput = on a link with non-zero BER is frame delineation. It is also affected = by choice of encapsulation. LAPS frames rely on error-free matches to = the flag pattern to indicate start and end of frame for every frame. = This leads to an unnecessarily high probability of lost frames due to = loss of delineation. This in turn contributes to a lower absolute = throughput than could be realized with a more robust delineation = mechanism.

More robust delineation mechanisms are = possible that are designed to be error-tolerant. This allows them to = coast through random bit errors that would defeat a flag delineation = mechanism. This would reduce the number of frames lost due to = delineation failures.

Conclusion

Mapping approaches for Ethernet over = SONET/SDH which do not use flag-based delineation are = preferable.


David W. Martin & Tim = Armstrong
           Nortel Networks

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C03AC8.A1A79AC0-- From owner-stds-802-3-etholaps@ieee.org Sat Oct 21 00:58 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id AAA22772 for ; Sat, 21 Oct 2000 00:58:03 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA86E for ; Sat, 21 Oct 2000 00:56:19 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id TAA23863; Fri, 20 Oct 2000 19:56:13 -0400 (EDT) From: pat_thaler@agilent.com Message-ID: <1BEBA5E8600DD4119A50009027AF54A0036B429E@axcs04.cos.agilent.com> To: dwmartin@nortelnetworks.com, stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Date: Fri, 20 Oct 2000 17:56:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 257 Status: RO Content-Type: text/plain; charset="iso-8859-1" Content-Length: 10251 David, Like most LAN people I'm not a great fan of byte stuffing however, some of the points you make in items 2 and 3 seem very stretched and reduce credibility. Frame loss effect of frame expansion - The maximum expansion of a frame is to twice its length. For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and assuming that errors are uncorrelated, probability of loosing the frame due to a bit error is: 1 - ((Pgoodbit)^bits ~ 0.0012%) where Pgoodbit is the probability that a bit is not errored = 1 - BER and bits = 1518 * 8 doubling the number of bits changes this to 0.0024%. A factor of 2 is not going to make a significant difference to throughput and most of the time (unless someone is maliciously creating expanding frames) the factor is a lot less than 2. What bothers me more is item 3. A bit hit in a frame will trash the frame whether it creates a false delimiter, damages a delimiter or just changes data. This is true for all the existing Ethernet codings. Once the error ends and a delimiter is received, the following frames will be received successfully. Since a hit on the length field of the protocol proposed for GFP by Nortel and Lucent causes frame sync to be lost and a bunch of frames can then be lost until sync has been regained, it seems that this might not be a topic you would want to introduce. It really isn't a weakness for LAPS but a case can be made for it as a weakness for GFP. The point about service impacting effects does have validity at least where the frame queuing decision is made disconnected from the LAPS transmission time. If there is a device with separate queues for different service levels and it gives the LAPS a frame at a time, only choosing the next frame when the last one is being finished, this shouldn't produce much delay. Worst case is for that is a lower service level frame delays a higher service level frame for twice the maximum packet size because of expansion. If, however, the queuing mechanism is disconnected from knowledge of LAPS transmission time, then the effect you are talking about does occur. If for instance, a switch is feeding stream into an Ethernet link which is then converted into a LAPS stream and the Sonet data rate is less than twice the Ethernet links rate, expansion can introduce as much delay as there is FIFO provided and too much expansion can overrun the FIFO causing packet loss. What is our objective here? My understanding is that the LAPS is almost sure to get approval at this point. LAPS does have some weaknesses and if I was constrained to a byte stuffing approach, I would have done it a bit differently. It would be better to scramble then delimit because then the scheme would not be subject to expansion by unlucky decisions in applications or malicious packet content. Frankly, the long tail of the distribution doesn't bother me as long as packet loss due to it is sigificantly below packet loss due to design bit error rate. Any of these scrambled rather than block coded transmission schemes has a distribution for run lengths of successive 1's or 0's which has a similar very long very skinny tail. That distribution can continue on to infinity but as long as the probablity of a run long enough that the receiver makes bit errors is low, it doesn't matter how long the tail is. Also, I think they put the LSB of each Ethernet byte into the LSB of the Sonet byte and Sonet sends MSB first so they reduce the burst error protection of the CRC code - a mistake that was also made in 100BASE-T, so it isn't the end of the world - but flipping the byte as it was put into Sonet would have been preferable. Are we trying to generate comments about what should be changed to improve the LAPS spec; generate a justification that will cause the LAPS spec to fail to get approval; propose criteria for when LAPS should be used versus GFP and 10GBASE-W; or something else? Regards, Pat -----Original Message----- From: David Martin [mailto:dwmartin@nortelnetworks.com] Sent: Friday, October 20, 2000 12:05 PM To: stds-802-3-etholaps Subject: Comments On LAPS All, Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. Background LAPS is a modified version of PPP with the following similarities: * Uses the same HDLC-like frame * Uses the same byte-stuffing / flag pattern delineation mechanism * Supports only point-to-point Layer 2 topology (i.e. no address/label fields) Differences wrt PPP: * Uses a much-simpler version of Link Control Protocol (no 'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 actions, and 11 LCP frame formats") * Uses the 'Address' field to identify among IPv4, IPv6, etc. (PPP fixes it as FF). The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean that LAPS shares the same drawbacks in throughput performance and the service effects of flag/byte-stuffing delineation. The following elaborates on these issues. Comments Packet based traffic generally requires received frames to be error-free. Any frames lost due to bit errors within the frame payload or due to loss of frame delineation will usually trigger a request for re-transmission at a higher layer. The re-transmission requests will then generate more traffic. This positive feedback mechanism makes frame loss performance an important parameter for packet-based traffic in general. Three aspects of throughput are discussed: deterministic versus statistical behaviour, the effect of frame inflation on throughput, and the effect of delineation performance on throughput. 1. Deterministic vs Statistical Throughput All currently defined Ethernet physical layers provide a deterministic throughput capacity. The throughput capacity is independent of the data contents. This is an important attribute, since it permits predictable performance. For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a unique one-byte pattern is used to detect both beginning and end of each frame. To ensure the flag pattern is unique, any occurrences of it must be removed from the data prior to encapsulation. This is done by replacing each occurrence of the flag pattern with a sequence of two bytes: a special 'escape' byte, followed by a slightly modified version of the flag pattern. Because of its special meaning, the 'escape' character must also be 'escaped'. Consequently, the frame length of the payload is inflated in a non-deterministic manner. Since two byte patterns are replaced by pairs of bytes, the probability that a random data byte will be 'escaped' is p = 1/128. For a frame F bytes long prior to 'escaping', the average frame-length after 'escaping' will be: F' = F + m bytes Where F is the un-escaped frame length in bytes m is the mean of the distribution of the number of bytes that must be escaped in the original F-byte frame Assuming random data the number of bytes 'escaped' per F-byte frame follows a binomial distribution with: probability of 'success': p = 2/256 = 1/128 probability of 'failure': q = 1 - p = 127/128 number of trials: n = F mean of the distribution is: m (mu) = np = F*(1/128) bytes standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 The tail of this distribution is extremely long: it reaches zero only after a potential doubling of the frame size. Non-Random Data The assumption of random data could easily be invalidated by applications that happen to produce the escaped octet values more frequently than a random process would. Vulnerability to Emulation Attacks The inflation problem is aggravated by the possibility of emulation attacks. Malicious users can generate frames with a high density of octet values which must be 'escaped'. This definitely invalidates the assumption of random data and skews the distribution towards the worst-case of a doubling of frame size. Service-Impacting Effects of Non-Deterministic Inflation The non-deterministic inflation imposed by LAPS byte stuffing could make tightly controlled frame delay variation (with acceptable absolute delays) very difficult if not impossible to achieve. The quality of frame-based real-time services, such as voice-over-IP, would suffer as a consequence. 2. LAPS Frame Inflation: Effect on Throughput The throughput capacity of an error-free link is inversely related to the overhead required by a given encapsulation mechanism. The inflation introduced by LAPS reduces throughput in a non-deterministic manner, by adding more overhead in an error-free environment. Once errors are introduced, throughput is diminished in two ways: random errors occurring within the frame; and frames lost through loss of delineation. For frames on a link with given BER, the probability of errors within the frame are a function of the frame length: the longer the frame the higher the probability of an error occurring in the frame. As seen above, LAPS inflation can significantly increase the frame length. This degrades the throughput by providing a larger target for random errors to hit. 3. LAPS Delineation Performance: Effect on Throughput The second factor affecting throughput on a link with non-zero BER is frame delineation. It is also affected by choice of encapsulation. LAPS frames rely on error-free matches to the flag pattern to indicate start and end of frame for every frame. This leads to an unnecessarily high probability of lost frames due to loss of delineation. This in turn contributes to a lower absolute throughput than could be realized with a more robust delineation mechanism. More robust delineation mechanisms are possible that are designed to be error-tolerant. This allows them to coast through random bit errors that would defeat a flag delineation mechanism. This would reduce the number of frames lost due to delineation failures. Conclusion Mapping approaches for Ethernet over SONET/SDH which do not use flag-based delineation are preferable. David W. Martin & Tim Armstrong Nortel Networks ========================= From owner-stds-802-3-etholaps@ieee.org Sun Oct 22 23:13 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id XAA09875 for ; Sun, 22 Oct 2000 23:13:02 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA198C for ; Sun, 22 Oct 2000 23:11:15 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id SAA15867; Sun, 22 Oct 2000 18:11:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20001022163655.00b4ba10@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Oct 2000 17:09:21 -0500 To: pat_thaler@agilent.com, dwmartin@nortelnetworks.com, From: Roy Bynum Subject: RE: Comments On LAPS In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0036B429E@axcs04.cos.agilen t.com> Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 287 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 12048 Pat, The points that David has made are valid. I have been building PPP/HDLC and POS IP data networks for years. The effects indicated in all of these points are empirically observed over IP networks that use Packet Over SONET/SDH (POS) links. This is a primary reason that the Internet as it is currently implemented has non-deterministic data jitter and latency. The empirical data loss in the Internet (POS) backbone transport is a much as 5%. 99% of the data loss in due to packets being dropped in the PPP to SONET gearbox with no indication of why. Over design of bandwidth utilization is normalized at minimum of 20% in loaded conditions. The design bandwidth utilization of non-converged redundant network links is at 40% per in order to allow for convergence traffic loading an still have a 20% overhead to account for data expansion due to byte stuffing. As a side issue, ironically, TDM sub-rate PPP link interfaces do not have the data loss that is observed in POS interfaces. The nominal data packet loss is about 1%. Bandwidth utilization design parameters are the same for TDM sub-rate links as they are for POS interfaces. I believe that the reason TDM sub-rate interfaces have a lower packet failure is that the minor clock tolerance adjustment of the self synchronizing data within the TDM payload is at bit level granularity. The clock tolerance adjustment of the self synchronizing data within SONET OCnC or SDH STMnC SPE is at byte level granularity. At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: >David, > >Like most LAN people I'm not a great fan of byte stuffing however, some of >the points you make in >items 2 and 3 seem very stretched and reduce credibility. > >Frame loss effect of frame expansion - The maximum expansion of a frame is >to twice its length. >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and >assuming that errors are >uncorrelated, probability of loosing the frame due to a bit error is: > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > and bits = 1518 * 8 > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not >going to make a significant >difference to throughput and most of the time (unless someone is maliciously >creating expanding frames) >the factor is a lot less than 2. > >What bothers me more is item 3. A bit hit in a frame will trash the frame >whether it creates a false >delimiter, damages a delimiter or just changes data. This is true for all >the existing Ethernet codings. >Once the error ends and a delimiter is received, the following frames will >be received successfully. > >Since a hit on the length field of the protocol proposed for GFP by Nortel >and Lucent causes frame >sync to be lost and a bunch of frames can then be lost until sync has been >regained, it seems that >this might not be a topic you would want to introduce. It really isn't a >weakness for LAPS but a case >can be made for it as a weakness for GFP. > >The point about service impacting effects does have validity at least where >the frame queuing decision >is made disconnected from the LAPS transmission time. If there is a device >with separate queues >for different service levels and it gives the LAPS a frame at a time, only >choosing the next frame >when the last one is being finished, this shouldn't produce much delay. >Worst case is for that is a >lower service level frame delays a higher service level frame for twice the >maximum packet size because >of expansion. If, however, the queuing mechanism is disconnected from >knowledge of LAPS transmission >time, then the effect you are talking about does occur. If for instance, a >switch is feeding stream into >an Ethernet link which is then converted into a LAPS stream and the Sonet >data rate is less than twice >the Ethernet links rate, expansion can introduce as much delay as there is >FIFO provided and too much >expansion can overrun the FIFO causing packet loss. > >What is our objective here? > >My understanding is that the LAPS is almost sure to get approval at this >point. > >LAPS does have some weaknesses and if I was constrained to a byte stuffing >approach, I would have >done it a bit differently. > >It would be better to scramble then delimit because then the scheme would >not be subject to expansion >by unlucky decisions in applications or malicious packet content. Frankly, >the long tail of the distribution >doesn't bother me as long as packet loss due to it is sigificantly below >packet loss due to design bit >error rate. Any of these scrambled rather than block coded transmission >schemes has a distribution >for run lengths of successive 1's or 0's which has a similar very long very >skinny tail. That distribution >can continue on to infinity but as long as the probablity of a run long >enough that the receiver makes >bit errors is low, it doesn't matter how long the tail is. > >Also, I think they put the LSB of each Ethernet byte into the LSB of the >Sonet byte and Sonet sends >MSB first so they reduce the burst error protection of the CRC code - a >mistake that was also made >in 100BASE-T, so it isn't the end of the world - but flipping the byte as it >was put into Sonet would >have been preferable. > >Are we trying to > generate comments about what should be changed to improve the LAPS spec; > generate a justification that will cause the LAPS spec to fail to get >approval; > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; >or > something else? > >Regards, >Pat > >-----Original Message----- >From: David Martin [mailto:dwmartin@nortelnetworks.com] >Sent: Friday, October 20, 2000 12:05 PM >To: stds-802-3-etholaps >Subject: Comments On LAPS > > > > >All, > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > >Background > >LAPS is a modified version of PPP with the following similarities: > > > * Uses the same HDLC-like frame >* Uses the same byte-stuffing / flag pattern delineation mechanism >* Supports only point-to-point Layer 2 topology (i.e. no address/label >fields) > >Differences wrt PPP: > > > * Uses a much-simpler version of Link Control Protocol (no >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 >actions, and 11 LCP frame formats") > > * Uses the 'Address' field to identify among IPv4, IPv6, etc. >(PPP fixes it as FF). > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean >that LAPS shares the same drawbacks in throughput performance and the >service effects of flag/byte-stuffing delineation. The following elaborates >on these issues. > >Comments > >Packet based traffic generally requires received frames to be error-free. >Any frames lost due to bit errors within the frame payload or due to loss of >frame delineation will usually trigger a request for re-transmission at a >higher layer. The re-transmission requests will then generate more traffic. >This positive feedback mechanism makes frame loss performance an important >parameter for packet-based traffic in general. > >Three aspects of throughput are discussed: deterministic versus statistical >behaviour, the effect of frame inflation on throughput, and the effect of >delineation performance on throughput. > >1. Deterministic vs Statistical Throughput > >All currently defined Ethernet physical layers provide a deterministic >throughput capacity. The throughput capacity is independent of the data >contents. This is an important attribute, since it permits predictable >performance. > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a >unique one-byte pattern is used to detect both beginning and end of each >frame. To ensure the flag pattern is unique, any occurrences of it must be >removed from the data prior to encapsulation. This is done by replacing each >occurrence of the flag pattern with a sequence of two bytes: a special >'escape' byte, followed by a slightly modified version of the flag pattern. >Because of its special meaning, the 'escape' character must also be >'escaped'. Consequently, the frame length of the payload is inflated in a >non-deterministic manner. Since two byte patterns are replaced by pairs of >bytes, the probability that a random data byte will be 'escaped' is p = >1/128. > >For a frame F bytes long prior to 'escaping', the average frame-length after >'escaping' will be: F' = F + m bytes > >Where F is the un-escaped frame length in bytes > > > m is the mean of the distribution of the number of bytes that >must be escaped in the original F-byte frame > >Assuming random data the number of bytes 'escaped' per F-byte frame follows >a binomial distribution with: > >probability of 'success': p = 2/256 = 1/128 >probability of 'failure': q = 1 - p = 127/128 >number of trials: n = F >mean of the distribution is: m (mu) = np = F*(1/128) bytes >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > >The tail of this distribution is extremely long: it reaches zero only after >a potential doubling of the frame size. > >Non-Random Data > >The assumption of random data could easily be invalidated by applications >that happen to produce the escaped octet values more frequently than a >random process would. > >Vulnerability to Emulation Attacks > >The inflation problem is aggravated by the possibility of emulation attacks. >Malicious users can generate frames with a high density of octet values >which must be 'escaped'. This definitely invalidates the assumption of >random data and skews the distribution towards the worst-case of a doubling >of frame size. > >Service-Impacting Effects of Non-Deterministic Inflation > >The non-deterministic inflation imposed by LAPS byte stuffing could make >tightly controlled frame delay variation (with acceptable absolute delays) >very difficult if not impossible to achieve. The quality of frame-based >real-time services, such as voice-over-IP, would suffer as a consequence. > > >2. LAPS Frame Inflation: Effect on Throughput > >The throughput capacity of an error-free link is inversely related to the >overhead required by a given encapsulation mechanism. The inflation >introduced by LAPS reduces throughput in a non-deterministic manner, by >adding more overhead in an error-free environment. > >Once errors are introduced, throughput is diminished in two ways: random >errors occurring within the frame; and frames lost through loss of >delineation. > >For frames on a link with given BER, the probability of errors within the >frame are a function of the frame length: the longer the frame the higher >the probability of an error occurring in the frame. As seen above, LAPS >inflation can significantly increase the frame length. This degrades the >throughput by providing a larger target for random errors to hit. > >3. LAPS Delineation Performance: Effect on Throughput > >The second factor affecting throughput on a link with non-zero BER is frame >delineation. It is also affected by choice of encapsulation. LAPS frames >rely on error-free matches to the flag pattern to indicate start and end of >frame for every frame. This leads to an unnecessarily high probability of >lost frames due to loss of delineation. This in turn contributes to a lower >absolute throughput than could be realized with a more robust delineation >mechanism. > >More robust delineation mechanisms are possible that are designed to be >error-tolerant. This allows them to coast through random bit errors that >would defeat a flag delineation mechanism. This would reduce the number of >frames lost due to delineation failures. > >Conclusion > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based >delineation are preferable. > > >David W. Martin & Tim Armstrong > Nortel Networks > >========================= From owner-stds-802-3-etholaps@ieee.org Mon Oct 23 00:00 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id AAA10126 for ; Mon, 23 Oct 2000 00:00:36 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA199B for ; Sun, 22 Oct 2000 23:58:50 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id SAA19222; Sun, 22 Oct 2000 18:58:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20001022174843.00b50d40@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Oct 2000 17:57:13 -0500 To: From: Roy Bynum Subject: Ethernet over LAPS adhoc document web site Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 41 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1690 All, David Law has placed several documents on the web site: http://www.ieee802.org/3/ad_hoc/etholaps/public/index.html These documents are: "3151r1.pdf", with the title of "ETHERNET FRAME OVER SDH/WDM" - This was the original proposal put before the ITU and was sent to IEEE 802.3 by ISO as part of the liaison letter that was discussed at the Montreal meeting in July '99. This document is "scary". It, in effect proposes a new MAC/PHY for Ethernet data switches. It fully maps the Ethernet frame into the LAPS frame, removing the Ethernet FCS with the process. "3203R1.pdf", with the title of "Draft new Recommendation X.86 (X.eos) on Ethernet over LAPS" - This is the draft document for the current version of the proposal. It now recognizes the MAC definition from the 802.3 standard. It still proposes a WAN PHY based on encapsulation of Ethernet frames within the LAPS frame. It also retains the Ethernet FCS. "draftX86rev1.pdf", with the title of "DRAFT NEW RECOMMENDATION X.86 (X.eos) ON ETHERNET OVER LAPS" - This is the official draft proposal. This is the document that will be approved in January '00, if there are no comments, and/or recommended modifications from 802.3. These documents are A1 format, so you may have some problems printing them with standard letter size paper. I went out and got some A1 paper for myself. After you have had a chance to take a look at these, please make any comments on this reflector. Any consensus that is reached will be presented at the next 802.3 Plenary. Also, all of those on this reflector that are voting members of 802.3, please send me a direct e-mail indicating your voting status. Thank you, Roy Bynum From owner-stds-802-3-etholaps@ieee.org Wed Oct 25 13:31 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id NAA06308 for ; Wed, 25 Oct 2000 13:31:17 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA387C for ; Wed, 25 Oct 2000 13:29:26 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id IAA06921; Wed, 25 Oct 2000 08:29:08 -0400 (EDT) From: pat_thaler@agilent.com Message-ID: <1BEBA5E8600DD4119A50009027AF54A0036B4840@axcs04.cos.agilent.com> To: rabynum@mindspring.com, pat_thaler@agilent.com, dwmartin@nortelnetworks.com, stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Date: Wed, 25 Oct 2000 06:29:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 318 Status: RO Content-Type: text/plain; charset="iso-8859-1" Content-Length: 12589 Roy, I have no doubt that a packet loss of 5% will have severe performance effects. However, the points David made do not explain such a loss rate. It seems most likely that much of the loss you are seeing is because of the particular designs rather than because of the encapsulation. Regards, Pat Thaler -----Original Message----- From: Roy Bynum [mailto:rabynum@mindspring.com] Sent: Sunday, October 22, 2000 3:09 PM To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Pat, The points that David has made are valid. I have been building PPP/HDLC and POS IP data networks for years. The effects indicated in all of these points are empirically observed over IP networks that use Packet Over SONET/SDH (POS) links. This is a primary reason that the Internet as it is currently implemented has non-deterministic data jitter and latency. The empirical data loss in the Internet (POS) backbone transport is a much as 5%. 99% of the data loss in due to packets being dropped in the PPP to SONET gearbox with no indication of why. Over design of bandwidth utilization is normalized at minimum of 20% in loaded conditions. The design bandwidth utilization of non-converged redundant network links is at 40% per in order to allow for convergence traffic loading an still have a 20% overhead to account for data expansion due to byte stuffing. As a side issue, ironically, TDM sub-rate PPP link interfaces do not have the data loss that is observed in POS interfaces. The nominal data packet loss is about 1%. Bandwidth utilization design parameters are the same for TDM sub-rate links as they are for POS interfaces. I believe that the reason TDM sub-rate interfaces have a lower packet failure is that the minor clock tolerance adjustment of the self synchronizing data within the TDM payload is at bit level granularity. The clock tolerance adjustment of the self synchronizing data within SONET OCnC or SDH STMnC SPE is at byte level granularity. At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: >David, > >Like most LAN people I'm not a great fan of byte stuffing however, some of >the points you make in >items 2 and 3 seem very stretched and reduce credibility. > >Frame loss effect of frame expansion - The maximum expansion of a frame is >to twice its length. >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and >assuming that errors are >uncorrelated, probability of loosing the frame due to a bit error is: > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > and bits = 1518 * 8 > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not >going to make a significant >difference to throughput and most of the time (unless someone is maliciously >creating expanding frames) >the factor is a lot less than 2. > >What bothers me more is item 3. A bit hit in a frame will trash the frame >whether it creates a false >delimiter, damages a delimiter or just changes data. This is true for all >the existing Ethernet codings. >Once the error ends and a delimiter is received, the following frames will >be received successfully. > >Since a hit on the length field of the protocol proposed for GFP by Nortel >and Lucent causes frame >sync to be lost and a bunch of frames can then be lost until sync has been >regained, it seems that >this might not be a topic you would want to introduce. It really isn't a >weakness for LAPS but a case >can be made for it as a weakness for GFP. > >The point about service impacting effects does have validity at least where >the frame queuing decision >is made disconnected from the LAPS transmission time. If there is a device >with separate queues >for different service levels and it gives the LAPS a frame at a time, only >choosing the next frame >when the last one is being finished, this shouldn't produce much delay. >Worst case is for that is a >lower service level frame delays a higher service level frame for twice the >maximum packet size because >of expansion. If, however, the queuing mechanism is disconnected from >knowledge of LAPS transmission >time, then the effect you are talking about does occur. If for instance, a >switch is feeding stream into >an Ethernet link which is then converted into a LAPS stream and the Sonet >data rate is less than twice >the Ethernet links rate, expansion can introduce as much delay as there is >FIFO provided and too much >expansion can overrun the FIFO causing packet loss. > >What is our objective here? > >My understanding is that the LAPS is almost sure to get approval at this >point. > >LAPS does have some weaknesses and if I was constrained to a byte stuffing >approach, I would have >done it a bit differently. > >It would be better to scramble then delimit because then the scheme would >not be subject to expansion >by unlucky decisions in applications or malicious packet content. Frankly, >the long tail of the distribution >doesn't bother me as long as packet loss due to it is sigificantly below >packet loss due to design bit >error rate. Any of these scrambled rather than block coded transmission >schemes has a distribution >for run lengths of successive 1's or 0's which has a similar very long very >skinny tail. That distribution >can continue on to infinity but as long as the probablity of a run long >enough that the receiver makes >bit errors is low, it doesn't matter how long the tail is. > >Also, I think they put the LSB of each Ethernet byte into the LSB of the >Sonet byte and Sonet sends >MSB first so they reduce the burst error protection of the CRC code - a >mistake that was also made >in 100BASE-T, so it isn't the end of the world - but flipping the byte as it >was put into Sonet would >have been preferable. > >Are we trying to > generate comments about what should be changed to improve the LAPS spec; > generate a justification that will cause the LAPS spec to fail to get >approval; > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; >or > something else? > >Regards, >Pat > >-----Original Message----- >From: David Martin [mailto:dwmartin@nortelnetworks.com] >Sent: Friday, October 20, 2000 12:05 PM >To: stds-802-3-etholaps >Subject: Comments On LAPS > > > > >All, > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > >Background > >LAPS is a modified version of PPP with the following similarities: > > > * Uses the same HDLC-like frame >* Uses the same byte-stuffing / flag pattern delineation mechanism >* Supports only point-to-point Layer 2 topology (i.e. no address/label >fields) > >Differences wrt PPP: > > > * Uses a much-simpler version of Link Control Protocol (no >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 >actions, and 11 LCP frame formats") > > * Uses the 'Address' field to identify among IPv4, IPv6, etc. >(PPP fixes it as FF). > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean >that LAPS shares the same drawbacks in throughput performance and the >service effects of flag/byte-stuffing delineation. The following elaborates >on these issues. > >Comments > >Packet based traffic generally requires received frames to be error-free. >Any frames lost due to bit errors within the frame payload or due to loss of >frame delineation will usually trigger a request for re-transmission at a >higher layer. The re-transmission requests will then generate more traffic. >This positive feedback mechanism makes frame loss performance an important >parameter for packet-based traffic in general. > >Three aspects of throughput are discussed: deterministic versus statistical >behaviour, the effect of frame inflation on throughput, and the effect of >delineation performance on throughput. > >1. Deterministic vs Statistical Throughput > >All currently defined Ethernet physical layers provide a deterministic >throughput capacity. The throughput capacity is independent of the data >contents. This is an important attribute, since it permits predictable >performance. > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a >unique one-byte pattern is used to detect both beginning and end of each >frame. To ensure the flag pattern is unique, any occurrences of it must be >removed from the data prior to encapsulation. This is done by replacing each >occurrence of the flag pattern with a sequence of two bytes: a special >'escape' byte, followed by a slightly modified version of the flag pattern. >Because of its special meaning, the 'escape' character must also be >'escaped'. Consequently, the frame length of the payload is inflated in a >non-deterministic manner. Since two byte patterns are replaced by pairs of >bytes, the probability that a random data byte will be 'escaped' is p = >1/128. > >For a frame F bytes long prior to 'escaping', the average frame-length after >'escaping' will be: F' = F + m bytes > >Where F is the un-escaped frame length in bytes > > > m is the mean of the distribution of the number of bytes that >must be escaped in the original F-byte frame > >Assuming random data the number of bytes 'escaped' per F-byte frame follows >a binomial distribution with: > >probability of 'success': p = 2/256 = 1/128 >probability of 'failure': q = 1 - p = 127/128 >number of trials: n = F >mean of the distribution is: m (mu) = np = F*(1/128) bytes >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > >The tail of this distribution is extremely long: it reaches zero only after >a potential doubling of the frame size. > >Non-Random Data > >The assumption of random data could easily be invalidated by applications >that happen to produce the escaped octet values more frequently than a >random process would. > >Vulnerability to Emulation Attacks > >The inflation problem is aggravated by the possibility of emulation attacks. >Malicious users can generate frames with a high density of octet values >which must be 'escaped'. This definitely invalidates the assumption of >random data and skews the distribution towards the worst-case of a doubling >of frame size. > >Service-Impacting Effects of Non-Deterministic Inflation > >The non-deterministic inflation imposed by LAPS byte stuffing could make >tightly controlled frame delay variation (with acceptable absolute delays) >very difficult if not impossible to achieve. The quality of frame-based >real-time services, such as voice-over-IP, would suffer as a consequence. > > >2. LAPS Frame Inflation: Effect on Throughput > >The throughput capacity of an error-free link is inversely related to the >overhead required by a given encapsulation mechanism. The inflation >introduced by LAPS reduces throughput in a non-deterministic manner, by >adding more overhead in an error-free environment. > >Once errors are introduced, throughput is diminished in two ways: random >errors occurring within the frame; and frames lost through loss of >delineation. > >For frames on a link with given BER, the probability of errors within the >frame are a function of the frame length: the longer the frame the higher >the probability of an error occurring in the frame. As seen above, LAPS >inflation can significantly increase the frame length. This degrades the >throughput by providing a larger target for random errors to hit. > >3. LAPS Delineation Performance: Effect on Throughput > >The second factor affecting throughput on a link with non-zero BER is frame >delineation. It is also affected by choice of encapsulation. LAPS frames >rely on error-free matches to the flag pattern to indicate start and end of >frame for every frame. This leads to an unnecessarily high probability of >lost frames due to loss of delineation. This in turn contributes to a lower >absolute throughput than could be realized with a more robust delineation >mechanism. > >More robust delineation mechanisms are possible that are designed to be >error-tolerant. This allows them to coast through random bit errors that >would defeat a flag delineation mechanism. This would reduce the number of >frames lost due to delineation failures. > >Conclusion > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based >delineation are preferable. > > >David W. Martin & Tim Armstrong > Nortel Networks > >========================= From owner-stds-802-3-etholaps@ieee.org Wed Oct 25 18:36 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id SAA08839 for ; Wed, 25 Oct 2000 18:36:20 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA3B5A for ; Wed, 25 Oct 2000 18:34:32 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id NAA06857; Wed, 25 Oct 2000 13:34:22 -0400 (EDT) Message-ID: From: "David Martin" To: stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Date: Wed, 25 Oct 2000 13:25:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03EA8.8B8AA140" X-Lines: 711 Status: RO Content-Length: 36352 ------_=_NextPart_001_01C03EA8.8B8AA140 Content-Type: text/plain; charset="iso-8859-1" X-Sun-Content-Length: 13102 Pat, It's possible that the packet loss Roy refers to arises due to the byte stuffing mechanism, where occasionally a 'highly byte stuffed' HDLC frame spills a buffer. It could be argued that such a problem is a design issue. ...Dave -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, October 25, 2000 8:29 AM To: rabynum@mindspring.com; pat_thaler@agilent.com; Martin, David [SKY:1I63-M:EXCH]; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Roy, I have no doubt that a packet loss of 5% will have severe performance effects. However, the points David made do not explain such a loss rate. It seems most likely that much of the loss you are seeing is because of the particular designs rather than because of the encapsulation. Regards, Pat Thaler -----Original Message----- From: Roy Bynum [mailto:rabynum@mindspring.com] Sent: Sunday, October 22, 2000 3:09 PM To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Pat, The points that David has made are valid. I have been building PPP/HDLC and POS IP data networks for years. The effects indicated in all of these points are empirically observed over IP networks that use Packet Over SONET/SDH (POS) links. This is a primary reason that the Internet as it is currently implemented has non-deterministic data jitter and latency. The empirical data loss in the Internet (POS) backbone transport is a much as 5%. 99% of the data loss in due to packets being dropped in the PPP to SONET gearbox with no indication of why. Over design of bandwidth utilization is normalized at minimum of 20% in loaded conditions. The design bandwidth utilization of non-converged redundant network links is at 40% per in order to allow for convergence traffic loading an still have a 20% overhead to account for data expansion due to byte stuffing. As a side issue, ironically, TDM sub-rate PPP link interfaces do not have the data loss that is observed in POS interfaces. The nominal data packet loss is about 1%. Bandwidth utilization design parameters are the same for TDM sub-rate links as they are for POS interfaces. I believe that the reason TDM sub-rate interfaces have a lower packet failure is that the minor clock tolerance adjustment of the self synchronizing data within the TDM payload is at bit level granularity. The clock tolerance adjustment of the self synchronizing data within SONET OCnC or SDH STMnC SPE is at byte level granularity. At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: >David, > >Like most LAN people I'm not a great fan of byte stuffing however, some of >the points you make in >items 2 and 3 seem very stretched and reduce credibility. > >Frame loss effect of frame expansion - The maximum expansion of a frame is >to twice its length. >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and >assuming that errors are >uncorrelated, probability of loosing the frame due to a bit error is: > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > and bits = 1518 * 8 > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not >going to make a significant >difference to throughput and most of the time (unless someone is maliciously >creating expanding frames) >the factor is a lot less than 2. > >What bothers me more is item 3. A bit hit in a frame will trash the frame >whether it creates a false >delimiter, damages a delimiter or just changes data. This is true for all >the existing Ethernet codings. >Once the error ends and a delimiter is received, the following frames will >be received successfully. > >Since a hit on the length field of the protocol proposed for GFP by Nortel >and Lucent causes frame >sync to be lost and a bunch of frames can then be lost until sync has been >regained, it seems that >this might not be a topic you would want to introduce. It really isn't a >weakness for LAPS but a case >can be made for it as a weakness for GFP. > >The point about service impacting effects does have validity at least where >the frame queuing decision >is made disconnected from the LAPS transmission time. If there is a device >with separate queues >for different service levels and it gives the LAPS a frame at a time, only >choosing the next frame >when the last one is being finished, this shouldn't produce much delay. >Worst case is for that is a >lower service level frame delays a higher service level frame for twice the >maximum packet size because >of expansion. If, however, the queuing mechanism is disconnected from >knowledge of LAPS transmission >time, then the effect you are talking about does occur. If for instance, a >switch is feeding stream into >an Ethernet link which is then converted into a LAPS stream and the Sonet >data rate is less than twice >the Ethernet links rate, expansion can introduce as much delay as there is >FIFO provided and too much >expansion can overrun the FIFO causing packet loss. > >What is our objective here? > >My understanding is that the LAPS is almost sure to get approval at this >point. > >LAPS does have some weaknesses and if I was constrained to a byte stuffing >approach, I would have >done it a bit differently. > >It would be better to scramble then delimit because then the scheme would >not be subject to expansion >by unlucky decisions in applications or malicious packet content. Frankly, >the long tail of the distribution >doesn't bother me as long as packet loss due to it is sigificantly below >packet loss due to design bit >error rate. Any of these scrambled rather than block coded transmission >schemes has a distribution >for run lengths of successive 1's or 0's which has a similar very long very >skinny tail. That distribution >can continue on to infinity but as long as the probablity of a run long >enough that the receiver makes >bit errors is low, it doesn't matter how long the tail is. > >Also, I think they put the LSB of each Ethernet byte into the LSB of the >Sonet byte and Sonet sends >MSB first so they reduce the burst error protection of the CRC code - a >mistake that was also made >in 100BASE-T, so it isn't the end of the world - but flipping the byte as it >was put into Sonet would >have been preferable. > >Are we trying to > generate comments about what should be changed to improve the LAPS spec; > generate a justification that will cause the LAPS spec to fail to get >approval; > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; >or > something else? > >Regards, >Pat > >-----Original Message----- >From: David Martin [mailto:dwmartin@nortelnetworks.com] >Sent: Friday, October 20, 2000 12:05 PM >To: stds-802-3-etholaps >Subject: Comments On LAPS > > > > >All, > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > >Background > >LAPS is a modified version of PPP with the following similarities: > > > * Uses the same HDLC-like frame >* Uses the same byte-stuffing / flag pattern delineation mechanism >* Supports only point-to-point Layer 2 topology (i.e. no address/label >fields) > >Differences wrt PPP: > > > * Uses a much-simpler version of Link Control Protocol (no >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 >actions, and 11 LCP frame formats") > > * Uses the 'Address' field to identify among IPv4, IPv6, etc. >(PPP fixes it as FF). > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean >that LAPS shares the same drawbacks in throughput performance and the >service effects of flag/byte-stuffing delineation. The following elaborates >on these issues. > >Comments > >Packet based traffic generally requires received frames to be error-free. >Any frames lost due to bit errors within the frame payload or due to loss of >frame delineation will usually trigger a request for re-transmission at a >higher layer. The re-transmission requests will then generate more traffic. >This positive feedback mechanism makes frame loss performance an important >parameter for packet-based traffic in general. > >Three aspects of throughput are discussed: deterministic versus statistical >behaviour, the effect of frame inflation on throughput, and the effect of >delineation performance on throughput. > >1. Deterministic vs Statistical Throughput > >All currently defined Ethernet physical layers provide a deterministic >throughput capacity. The throughput capacity is independent of the data >contents. This is an important attribute, since it permits predictable >performance. > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a >unique one-byte pattern is used to detect both beginning and end of each >frame. To ensure the flag pattern is unique, any occurrences of it must be >removed from the data prior to encapsulation. This is done by replacing each >occurrence of the flag pattern with a sequence of two bytes: a special >'escape' byte, followed by a slightly modified version of the flag pattern. >Because of its special meaning, the 'escape' character must also be >'escaped'. Consequently, the frame length of the payload is inflated in a >non-deterministic manner. Since two byte patterns are replaced by pairs of >bytes, the probability that a random data byte will be 'escaped' is p = >1/128. > >For a frame F bytes long prior to 'escaping', the average frame-length after >'escaping' will be: F' = F + m bytes > >Where F is the un-escaped frame length in bytes > > > m is the mean of the distribution of the number of bytes that >must be escaped in the original F-byte frame > >Assuming random data the number of bytes 'escaped' per F-byte frame follows >a binomial distribution with: > >probability of 'success': p = 2/256 = 1/128 >probability of 'failure': q = 1 - p = 127/128 >number of trials: n = F >mean of the distribution is: m (mu) = np = F*(1/128) bytes >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > >The tail of this distribution is extremely long: it reaches zero only after >a potential doubling of the frame size. > >Non-Random Data > >The assumption of random data could easily be invalidated by applications >that happen to produce the escaped octet values more frequently than a >random process would. > >Vulnerability to Emulation Attacks > >The inflation problem is aggravated by the possibility of emulation attacks. >Malicious users can generate frames with a high density of octet values >which must be 'escaped'. This definitely invalidates the assumption of >random data and skews the distribution towards the worst-case of a doubling >of frame size. > >Service-Impacting Effects of Non-Deterministic Inflation > >The non-deterministic inflation imposed by LAPS byte stuffing could make >tightly controlled frame delay variation (with acceptable absolute delays) >very difficult if not impossible to achieve. The quality of frame-based >real-time services, such as voice-over-IP, would suffer as a consequence. > > >2. LAPS Frame Inflation: Effect on Throughput > >The throughput capacity of an error-free link is inversely related to the >overhead required by a given encapsulation mechanism. The inflation >introduced by LAPS reduces throughput in a non-deterministic manner, by >adding more overhead in an error-free environment. > >Once errors are introduced, throughput is diminished in two ways: random >errors occurring within the frame; and frames lost through loss of >delineation. > >For frames on a link with given BER, the probability of errors within the >frame are a function of the frame length: the longer the frame the higher >the probability of an error occurring in the frame. As seen above, LAPS >inflation can significantly increase the frame length. This degrades the >throughput by providing a larger target for random errors to hit. > >3. LAPS Delineation Performance: Effect on Throughput > >The second factor affecting throughput on a link with non-zero BER is frame >delineation. It is also affected by choice of encapsulation. LAPS frames >rely on error-free matches to the flag pattern to indicate start and end of >frame for every frame. This leads to an unnecessarily high probability of >lost frames due to loss of delineation. This in turn contributes to a lower >absolute throughput than could be realized with a more robust delineation >mechanism. > >More robust delineation mechanisms are possible that are designed to be >error-tolerant. This allows them to coast through random bit errors that >would defeat a flag delineation mechanism. This would reduce the number of >frames lost due to delineation failures. > >Conclusion > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based >delineation are preferable. > > >David W. Martin & Tim Armstrong > Nortel Networks > >========================= ------_=_NextPart_001_01C03EA8.8B8AA140 Content-Type: text/html; charset="iso-8859-1" X-Sun-Content-Length: 22975 RE: Comments On LAPS

Pat,

It's possible that the packet loss Roy refers to arises due
to the byte stuffing mechanism, where occasionally a 'highly byte
stuffed' HDLC frame spills a buffer. It could be argued that
such a problem is a design issue.

...Dave

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Wednesday, October 25, 2000 8:29 AM
To: rabynum@mindspring.com; pat_thaler@agilent.com; Martin, David
[SKY:1I63-M:EXCH]; stds-802-3-etholaps@ieee.org
Subject: RE: Comments On LAPS


Roy,

I have no doubt that a packet loss of 5% will have severe performance
effects.
However, the points David made do not explain such a loss rate. It seems
most
likely that much of the loss you are seeing is because of the particular
designs
rather than because of the encapsulation.

Regards,
Pat Thaler

-----Original Message-----
From: Roy Bynum [mailto:rabynum@mindspring.com]
Sent: Sunday, October 22, 2000 3:09 PM
To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com;
stds-802-3-etholaps@ieee.org
Subject: RE: Comments On LAPS



Pat,

The points that David has made are valid.  I have been building PPP/HDLC
and POS IP data networks for years.  The effects indicated in all of these
points are empirically observed over IP networks that use Packet Over
SONET/SDH (POS) links.  This is a primary reason that the Internet as it is
currently implemented has non-deterministic data jitter and latency.

The empirical data loss in the Internet (POS) backbone transport is a much
as 5%.  99% of the data loss in due to packets being dropped in the PPP to
SONET gearbox with no indication of why.  Over design of bandwidth
utilization is normalized at minimum of 20% in loaded conditions.   The
design bandwidth utilization of non-converged redundant network links is at
40% per in order to allow for convergence traffic loading an still have a
20% overhead to account for data expansion due to byte stuffing.

As a side issue, ironically, TDM sub-rate PPP link interfaces do not have
the data loss that is observed in POS interfaces.  The nominal data packet
loss is about 1%.  Bandwidth utilization design parameters are the same for
TDM sub-rate links as they are for POS interfaces.

I believe that the reason TDM sub-rate interfaces have a lower packet
failure is that the minor clock tolerance adjustment of the self
synchronizing data within the TDM payload is at bit level granularity.  The
clock tolerance adjustment of the self synchronizing data within SONET OCnC
or SDH STMnC SPE is at byte level granularity.


At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote:

>David,
>
>Like most LAN people I'm not a great fan of byte stuffing however, some of
>the points you make in
>items 2 and 3 seem very stretched and reduce credibility.
>
>Frame loss effect of frame expansion - The maximum expansion of a frame is
>to twice its length.
>For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and
>assuming that errors are
>uncorrelated, probability of loosing the frame due to a bit error is:
>
>   1 - ((Pgoodbit)^bits ~ 0.0012%)
>
>where Pgoodbit is the probability that a bit is not errored = 1 - BER
>     and bits = 1518 * 8
>
>doubling the number of bits changes this to 0.0024%. A factor of 2 is not
>going to make a significant
>difference to throughput and most of the time (unless someone is
maliciously
>creating expanding frames)
>the factor is a lot less than 2.
>
>What bothers me more is item 3. A bit hit in a frame will trash the frame
>whether it creates a false
>delimiter, damages a delimiter or just changes data. This is true for all
>the existing Ethernet codings.
>Once the error ends and a delimiter is received, the following frames will
>be received successfully.
>
>Since a hit on the length field of the protocol proposed for GFP by Nortel
>and Lucent causes frame
>sync to be lost and a bunch of frames can then be lost until sync has been
>regained, it seems that
>this might not be a topic you would want to introduce. It really isn't a
>weakness for LAPS but a case
>can be made for it as a weakness for GFP.
>
>The point about service impacting effects does have validity at least where
>the frame queuing decision
>is made disconnected from the LAPS transmission time. If there is a device
>with separate queues
>for different service levels and it gives the LAPS a frame at a time, only
>choosing the next frame
>when the last one is being finished, this shouldn't produce much delay.
>Worst case is for that is a
>lower service level frame delays a higher service level frame for twice the
>maximum packet size because
>of expansion. If, however, the queuing mechanism is disconnected from
>knowledge of LAPS transmission
>time, then the effect you are talking about does occur. If for instance, a
>switch is feeding stream into
>an Ethernet link which is then converted into a LAPS stream and the Sonet
>data rate is less than twice
>the Ethernet links rate, expansion can introduce as much delay as there is
>FIFO provided and too much
>expansion can overrun the FIFO causing packet loss.
>
>What is our objective here?
>
>My understanding is that the LAPS is almost sure to get approval at this
>point.
>
>LAPS does have some weaknesses and if I was constrained to a byte stuffing
>approach, I would have
>done it a bit differently.
>
>It would be better to scramble then delimit because then the scheme would
>not be subject to expansion
>by unlucky decisions in applications or malicious packet content. Frankly,
>the long tail of the distribution
>doesn't bother me as long as packet loss due to it is sigificantly below
>packet loss due to design bit
>error rate. Any of these scrambled rather than block coded transmission
>schemes has a distribution
>for run lengths of successive 1's or 0's which has a similar very long very
>skinny tail. That distribution
>can continue on to infinity but as long as the probablity of a run long
>enough that the receiver makes
>bit errors is low, it doesn't matter how long the tail is.
>
>Also, I think they put the LSB of each Ethernet byte into the LSB of the
>Sonet byte and Sonet sends
>MSB first so they reduce the burst error protection of the CRC code - a
>mistake that was also made
>in 100BASE-T, so it isn't the end of the world - but flipping the byte as
it
>was put into Sonet would
>have been preferable.
>
>Are we trying to
>    generate comments about what should be changed to improve the LAPS
spec;
>    generate a justification that will cause the LAPS spec to fail to get
>approval;
>    propose criteria for when LAPS should be used versus GFP and 10GBASE-W;
>or
>    something else?
>
>Regards,
>Pat
>
>-----Original Message-----
>From: David Martin [mailto:dwmartin@nortelnetworks.com]
>Sent: Friday, October 20, 2000 12:05 PM
>To: stds-802-3-etholaps
>Subject: Comments On LAPS
>
>
>
>
>All,
>
>Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling.
>
>Background
>
>LAPS is a modified version of PPP with the following similarities:
>
>
>         *       Uses the same HDLC-like frame
>*       Uses the same byte-stuffing / flag pattern delineation mechanism
>*       Supports only point-to-point Layer 2 topology (i.e. no
address/label
>fields)
>
>Differences wrt PPP:
>
>
>         *       Uses a much-simpler version of Link Control Protocol (no
>'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12
>actions, and 11 LCP frame formats")
>
>         *       Uses the 'Address' field to identify among IPv4, IPv6,
etc.
>(PPP fixes it as FF).
>
>The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean
>that LAPS shares the same drawbacks in throughput performance and the
>service effects of flag/byte-stuffing delineation. The following elaborates
>on these issues.
>
>Comments
>
>Packet based traffic generally requires received frames to be error-free.
>Any frames lost due to bit errors within the frame payload or due to loss
of
>frame delineation will usually trigger a request for re-transmission at a
>higher layer. The re-transmission requests will then generate more traffic.
>This positive feedback mechanism makes frame loss performance an important
>parameter for packet-based traffic in general.
>
>Three aspects of throughput are discussed: deterministic versus statistical
>behaviour, the effect of frame inflation on throughput, and the effect of
>delineation performance on throughput.
>
>1.      Deterministic vs Statistical Throughput
>
>All currently defined Ethernet physical layers provide a deterministic
>throughput capacity. The throughput capacity is independent of the data
>contents. This is an important attribute, since it permits predictable
>performance.
>
>For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a
>unique one-byte pattern is used to detect both beginning and end of each
>frame. To ensure the flag pattern is unique, any occurrences of it must be
>removed from the data prior to encapsulation. This is done by replacing
each
>occurrence of the flag pattern with a sequence of two bytes: a special
>'escape' byte, followed by a slightly modified version of the flag pattern.
>Because of its special meaning, the 'escape' character must also be
>'escaped'. Consequently, the frame length of the payload is inflated in a
>non-deterministic manner. Since two byte patterns are replaced by pairs of
>bytes, the probability that a random data byte will be 'escaped' is p =
>1/128.
>
>For a frame F bytes long prior to 'escaping', the average frame-length
after
>'escaping' will be:    F' = F + m bytes
>
>Where  F        is the un-escaped frame length in bytes
>
>
>         m       is the mean of the distribution of the number of bytes
that
>must be escaped in the original F-byte frame
>
>Assuming random data the number of bytes 'escaped' per F-byte frame follows
>a binomial distribution with:
>
>probability of 'success':               p = 2/256 = 1/128
>probability of 'failure':               q = 1 - p = 127/128
>number of trials:                               n = F
>mean of the distribution is:    m (mu) = np = F*(1/128) bytes
>standard deviation is:          s (sigma) = sqrt (npq) = sqrt (F*127) / 128
>
>The tail of this distribution is extremely long: it reaches zero only after
>a potential doubling of the frame size.
>
>Non-Random Data
>
>The assumption of random data could easily be invalidated by applications
>that happen to produce the escaped octet values more frequently than a
>random process would.
>
>Vulnerability to Emulation Attacks
>
>The inflation problem is aggravated by the possibility of emulation
attacks.
>Malicious users can generate frames with a high density of octet values
>which must be 'escaped'. This definitely invalidates the assumption of
>random data and skews the distribution towards the worst-case of a doubling
>of frame size.
>
>Service-Impacting Effects of Non-Deterministic Inflation
>
>The non-deterministic inflation imposed by LAPS byte stuffing could make
>tightly controlled frame delay variation (with acceptable absolute delays)
>very difficult if not impossible to achieve. The quality of frame-based
>real-time services, such as voice-over-IP, would suffer as a consequence.
>
>
>2.      LAPS Frame Inflation: Effect on Throughput
>
>The throughput capacity of an error-free link is inversely related to the
>overhead required by a given encapsulation mechanism. The inflation
>introduced by LAPS reduces throughput in a non-deterministic manner, by
>adding more overhead in an error-free environment.
>
>Once errors are introduced, throughput is diminished in two ways: random
>errors occurring within the frame; and frames lost through loss of
>delineation.
>
>For frames on a link with given BER, the probability of errors within the
>frame are a function of the frame length: the longer the frame the higher
>the probability of an error occurring in the frame. As seen above, LAPS
>inflation can significantly increase the frame length. This degrades the
>throughput by providing a larger target for random errors to hit.
>
>3.      LAPS Delineation Performance: Effect on Throughput
>
>The second factor affecting throughput on a link with non-zero BER is frame
>delineation. It is also affected by choice of encapsulation. LAPS frames
>rely on error-free matches to the flag pattern to indicate start and end of
>frame for every frame. This leads to an unnecessarily high probability of
>lost frames due to loss of delineation. This in turn contributes to a lower
>absolute throughput than could be realized with a more robust delineation
>mechanism.
>
>More robust delineation mechanisms are possible that are designed to be
>error-tolerant. This allows them to coast through random bit errors that
>would defeat a flag delineation mechanism. This would reduce the number of
>frames lost due to delineation failures.
>
>Conclusion
>
>Mapping approaches for Ethernet over SONET/SDH which do not use flag-based
>delineation are preferable.
>
>
>David W. Martin & Tim Armstrong
>            Nortel Networks
>
>=========================

------_=_NextPart_001_01C03EA8.8B8AA140-- From owner-stds-802-3-etholaps@ieee.org Thu Oct 26 15:55 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id PAA17105 for ; Thu, 26 Oct 2000 15:55:22 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA47C3 for ; Thu, 26 Oct 2000 15:53:31 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id KAA17717; Thu, 26 Oct 2000 10:53:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20001026093236.00af6cb0@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Oct 2000 09:44:00 -0500 To: pat_thaler@agilent.com, pat_thaler@agilent.com, dwmartin@nortelnetworks.com, From: Roy Bynum Subject: RE: Comments On LAPS In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0036B4840@axcs04.cos.agilen t.com> Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 342 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 14400 Pat, Everyone wants to say that it is a design or an implementation problem. If that were the case, then someone would have found the specific implementation solution and fixed it. No one has. This is a problem with ALL implementations. There are NO vendors that do not have these problems in a legacy IP network implementations. It is such a pervasive problem that it is considered as part of the status quo, and a function of IP itself. There is not something within the IP (Layer 3 Only) protocol itself that can be linked to the cause of this data loss. It is not a function of the routing protocols normally used, OSPF and BGP, because RIP exhibits the same data loss. It is not a function of the bit error rate of the physical transport, a 10E-10 to 10E-14 bit error rate does not translate to a 10E-3 to 10E-4 packet error rate. Having eliminated all of the things that can not be the cause of the observed data loss, the only thing that is left is the HDLC and the gear box used to insert the self-synchronizing data stream into the synchronized transport service. I think that 10GbE will help us determine if it is the gearbox or the HDLC. Thank you, Roy Bynum At 06:29 AM 10/25/00 -0600, pat_thaler@agilent.com wrote: >Roy, > >I have no doubt that a packet loss of 5% will have severe performance >effects. >However, the points David made do not explain such a loss rate. It seems >most >likely that much of the loss you are seeing is because of the particular >designs >rather than because of the encapsulation. > >Regards, >Pat Thaler > >-----Original Message----- >From: Roy Bynum [mailto:rabynum@mindspring.com] >Sent: Sunday, October 22, 2000 3:09 PM >To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com; >stds-802-3-etholaps@ieee.org >Subject: RE: Comments On LAPS > > > >Pat, > >The points that David has made are valid. I have been building PPP/HDLC >and POS IP data networks for years. The effects indicated in all of these >points are empirically observed over IP networks that use Packet Over >SONET/SDH (POS) links. This is a primary reason that the Internet as it is >currently implemented has non-deterministic data jitter and latency. > >The empirical data loss in the Internet (POS) backbone transport is a much >as 5%. 99% of the data loss in due to packets being dropped in the PPP to >SONET gearbox with no indication of why. Over design of bandwidth >utilization is normalized at minimum of 20% in loaded conditions. The >design bandwidth utilization of non-converged redundant network links is at >40% per in order to allow for convergence traffic loading an still have a >20% overhead to account for data expansion due to byte stuffing. > >As a side issue, ironically, TDM sub-rate PPP link interfaces do not have >the data loss that is observed in POS interfaces. The nominal data packet >loss is about 1%. Bandwidth utilization design parameters are the same for >TDM sub-rate links as they are for POS interfaces. > >I believe that the reason TDM sub-rate interfaces have a lower packet >failure is that the minor clock tolerance adjustment of the self >synchronizing data within the TDM payload is at bit level granularity. The >clock tolerance adjustment of the self synchronizing data within SONET OCnC >or SDH STMnC SPE is at byte level granularity. > > >At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: > > >David, > > > >Like most LAN people I'm not a great fan of byte stuffing however, some of > >the points you make in > >items 2 and 3 seem very stretched and reduce credibility. > > > >Frame loss effect of frame expansion - The maximum expansion of a frame is > >to twice its length. > >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and > >assuming that errors are > >uncorrelated, probability of loosing the frame due to a bit error is: > > > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > > > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > > and bits = 1518 * 8 > > > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not > >going to make a significant > >difference to throughput and most of the time (unless someone is >maliciously > >creating expanding frames) > >the factor is a lot less than 2. > > > >What bothers me more is item 3. A bit hit in a frame will trash the frame > >whether it creates a false > >delimiter, damages a delimiter or just changes data. This is true for all > >the existing Ethernet codings. > >Once the error ends and a delimiter is received, the following frames will > >be received successfully. > > > >Since a hit on the length field of the protocol proposed for GFP by Nortel > >and Lucent causes frame > >sync to be lost and a bunch of frames can then be lost until sync has been > >regained, it seems that > >this might not be a topic you would want to introduce. It really isn't a > >weakness for LAPS but a case > >can be made for it as a weakness for GFP. > > > >The point about service impacting effects does have validity at least where > >the frame queuing decision > >is made disconnected from the LAPS transmission time. If there is a device > >with separate queues > >for different service levels and it gives the LAPS a frame at a time, only > >choosing the next frame > >when the last one is being finished, this shouldn't produce much delay. > >Worst case is for that is a > >lower service level frame delays a higher service level frame for twice the > >maximum packet size because > >of expansion. If, however, the queuing mechanism is disconnected from > >knowledge of LAPS transmission > >time, then the effect you are talking about does occur. If for instance, a > >switch is feeding stream into > >an Ethernet link which is then converted into a LAPS stream and the Sonet > >data rate is less than twice > >the Ethernet links rate, expansion can introduce as much delay as there is > >FIFO provided and too much > >expansion can overrun the FIFO causing packet loss. > > > >What is our objective here? > > > >My understanding is that the LAPS is almost sure to get approval at this > >point. > > > >LAPS does have some weaknesses and if I was constrained to a byte stuffing > >approach, I would have > >done it a bit differently. > > > >It would be better to scramble then delimit because then the scheme would > >not be subject to expansion > >by unlucky decisions in applications or malicious packet content. Frankly, > >the long tail of the distribution > >doesn't bother me as long as packet loss due to it is sigificantly below > >packet loss due to design bit > >error rate. Any of these scrambled rather than block coded transmission > >schemes has a distribution > >for run lengths of successive 1's or 0's which has a similar very long very > >skinny tail. That distribution > >can continue on to infinity but as long as the probablity of a run long > >enough that the receiver makes > >bit errors is low, it doesn't matter how long the tail is. > > > >Also, I think they put the LSB of each Ethernet byte into the LSB of the > >Sonet byte and Sonet sends > >MSB first so they reduce the burst error protection of the CRC code - a > >mistake that was also made > >in 100BASE-T, so it isn't the end of the world - but flipping the byte as >it > >was put into Sonet would > >have been preferable. > > > >Are we trying to > > generate comments about what should be changed to improve the LAPS >spec; > > generate a justification that will cause the LAPS spec to fail to get > >approval; > > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; > >or > > something else? > > > >Regards, > >Pat > > > >-----Original Message----- > >From: David Martin [mailto:dwmartin@nortelnetworks.com] > >Sent: Friday, October 20, 2000 12:05 PM > >To: stds-802-3-etholaps > >Subject: Comments On LAPS > > > > > > > > > >All, > > > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > > > >Background > > > >LAPS is a modified version of PPP with the following similarities: > > > > > > * Uses the same HDLC-like frame > >* Uses the same byte-stuffing / flag pattern delineation mechanism > >* Supports only point-to-point Layer 2 topology (i.e. no >address/label > >fields) > > > >Differences wrt PPP: > > > > > > * Uses a much-simpler version of Link Control Protocol (no > >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 > >actions, and 11 LCP frame formats") > > > > * Uses the 'Address' field to identify among IPv4, IPv6, >etc. > >(PPP fixes it as FF). > > > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean > >that LAPS shares the same drawbacks in throughput performance and the > >service effects of flag/byte-stuffing delineation. The following elaborates > >on these issues. > > > >Comments > > > >Packet based traffic generally requires received frames to be error-free. > >Any frames lost due to bit errors within the frame payload or due to loss >of > >frame delineation will usually trigger a request for re-transmission at a > >higher layer. The re-transmission requests will then generate more traffic. > >This positive feedback mechanism makes frame loss performance an important > >parameter for packet-based traffic in general. > > > >Three aspects of throughput are discussed: deterministic versus statistical > >behaviour, the effect of frame inflation on throughput, and the effect of > >delineation performance on throughput. > > > >1. Deterministic vs Statistical Throughput > > > >All currently defined Ethernet physical layers provide a deterministic > >throughput capacity. The throughput capacity is independent of the data > >contents. This is an important attribute, since it permits predictable > >performance. > > > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a > >unique one-byte pattern is used to detect both beginning and end of each > >frame. To ensure the flag pattern is unique, any occurrences of it must be > >removed from the data prior to encapsulation. This is done by replacing >each > >occurrence of the flag pattern with a sequence of two bytes: a special > >'escape' byte, followed by a slightly modified version of the flag pattern. > >Because of its special meaning, the 'escape' character must also be > >'escaped'. Consequently, the frame length of the payload is inflated in a > >non-deterministic manner. Since two byte patterns are replaced by pairs of > >bytes, the probability that a random data byte will be 'escaped' is p = > >1/128. > > > >For a frame F bytes long prior to 'escaping', the average frame-length >after > >'escaping' will be: F' = F + m bytes > > > >Where F is the un-escaped frame length in bytes > > > > > > m is the mean of the distribution of the number of bytes >that > >must be escaped in the original F-byte frame > > > >Assuming random data the number of bytes 'escaped' per F-byte frame follows > >a binomial distribution with: > > > >probability of 'success': p = 2/256 = 1/128 > >probability of 'failure': q = 1 - p = 127/128 > >number of trials: n = F > >mean of the distribution is: m (mu) = np = F*(1/128) bytes > >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > > > >The tail of this distribution is extremely long: it reaches zero only after > >a potential doubling of the frame size. > > > >Non-Random Data > > > >The assumption of random data could easily be invalidated by applications > >that happen to produce the escaped octet values more frequently than a > >random process would. > > > >Vulnerability to Emulation Attacks > > > >The inflation problem is aggravated by the possibility of emulation >attacks. > >Malicious users can generate frames with a high density of octet values > >which must be 'escaped'. This definitely invalidates the assumption of > >random data and skews the distribution towards the worst-case of a doubling > >of frame size. > > > >Service-Impacting Effects of Non-Deterministic Inflation > > > >The non-deterministic inflation imposed by LAPS byte stuffing could make > >tightly controlled frame delay variation (with acceptable absolute delays) > >very difficult if not impossible to achieve. The quality of frame-based > >real-time services, such as voice-over-IP, would suffer as a consequence. > > > > > >2. LAPS Frame Inflation: Effect on Throughput > > > >The throughput capacity of an error-free link is inversely related to the > >overhead required by a given encapsulation mechanism. The inflation > >introduced by LAPS reduces throughput in a non-deterministic manner, by > >adding more overhead in an error-free environment. > > > >Once errors are introduced, throughput is diminished in two ways: random > >errors occurring within the frame; and frames lost through loss of > >delineation. > > > >For frames on a link with given BER, the probability of errors within the > >frame are a function of the frame length: the longer the frame the higher > >the probability of an error occurring in the frame. As seen above, LAPS > >inflation can significantly increase the frame length. This degrades the > >throughput by providing a larger target for random errors to hit. > > > >3. LAPS Delineation Performance: Effect on Throughput > > > >The second factor affecting throughput on a link with non-zero BER is frame > >delineation. It is also affected by choice of encapsulation. LAPS frames > >rely on error-free matches to the flag pattern to indicate start and end of > >frame for every frame. This leads to an unnecessarily high probability of > >lost frames due to loss of delineation. This in turn contributes to a lower > >absolute throughput than could be realized with a more robust delineation > >mechanism. > > > >More robust delineation mechanisms are possible that are designed to be > >error-tolerant. This allows them to coast through random bit errors that > >would defeat a flag delineation mechanism. This would reduce the number of > >frames lost due to delineation failures. > > > >Conclusion > > > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based > >delineation are preferable. > > > > > >David W. Martin & Tim Armstrong > > Nortel Networks > > > >========================= From owner-stds-802-3-etholaps@ieee.org Sat Oct 28 14:12 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id OAA04745 for ; Sat, 28 Oct 2000 14:12:52 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA5FE5 for ; Sat, 28 Oct 2000 14:11:06 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id JAA24386; Sat, 28 Oct 2000 09:10:32 -0400 (EDT) Message-Id: <5.0.0.25.2.20001028080326.009dd150@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 28 Oct 2000 08:08:42 -0500 To: From: Roy Bynum Subject: ITU Proposed Standard Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 12 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 361 Everyone, Those of you that have not had a chance to look at the proposal from ITU for Ethernet over LAPS, please do so. That site is: http://www.ieee802.org/3/ad_hoc/etholaps/public/index.html. Those of you that have, please respond and comment. The Plenary meeting is a week away and we do not have anything to present so far. Thank you, Roy Bynum From owner-stds-802-3-etholaps@ieee.org Sat Oct 28 21:37 BST 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id VAA09092 for ; Sat, 28 Oct 2000 21:37:18 +0100 (BST) Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA6223 for ; Sat, 28 Oct 2000 21:35:32 +0100 Received: by ruebert.ieee.org (8.9.3/8.9.3) id QAA25823; Sat, 28 Oct 2000 16:35:28 -0400 (EDT) Message-Id: <5.0.0.25.2.20001028143354.00a2f130@pop.mindspring.com> X-Sender: rabynum@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 28 Oct 2000 15:33:38 -0500 To: , pat_thaler@agilent.com From: Roy Bynum Subject: History of HDLC and LAP Mime-Version: 1.0 Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 33 Status: RO Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Length: 1672 Pat, I did some research into the history of HDLC just to verify my memory. HDLC is the ISO variant of Synchronous Data Link Control (SDLC) protocol from IBM. SDLC is the data link protocol under Systems Network Architecture (SNA). SNA replaced Binary Synchronous (BSC) protocol in the 1970s at the primary mainframe to mainframe communications protocol. SDLC was and has remained the data link protocol for remote terminal and data entry equipment for mainframe systems. The Normal Response Mode (NRM) of HDLC is equivalent to SDLC. There are five primary variants of HDLC, Normal Response Mode (NRM), Link Access Procedure (LAP), Link Access Procedure Balanced (LAPB), Link Access Procedure for ISDN D Channel (LAPD), and Link Access Procedure for Modems (LAPM). LAP was the original data link protocol for X.25. It was replaced in X.25 by LAPB. Point to Point Protocol (PPP) from IETF is a variant of LAPB. Link Access Procedure for SDH (LAPS) is a variant of the original LAP protocol. HDLC uses a complex link initialization procedure. I believe that it is this procedure which is also in PPP that causes a major delay in traffic restoration of Internet Protocol (IP) links over optical/SONET/SDH protected networks. I did some experimentation with this in 1999. The best that I could achieve was a traffic restoration of ~800ms. The use of LAPS to transport Ethernet will in all likely hood have the same traffic restoration delay that is seen in PPP. Compared to a 2ms traffic restoration delay that is seen with optical GbE, the Ethernet over LAPS PHY will not have the resilience of IEEE 802.3 PHYs. Thank you, Roy Bynum From owner-stds-802-3-etholaps@ieee.org Sun Oct 29 20:52 GMT 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id UAA20624 for ; Sun, 29 Oct 2000 20:52:04 GMT Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA6A72 for ; Sun, 29 Oct 2000 20:50:18 +0000 Received: by ruebert.ieee.org (8.9.3/8.9.3) id PAA02625; Sun, 29 Oct 2000 15:50:13 -0500 (EST) From: pat_thaler@agilent.com Message-ID: <1BEBA5E8600DD4119A50009027AF54A0036B4E42@axcs04.cos.agilent.com> To: dwmartin@nortelnetworks.com, stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Date: Sun, 29 Oct 2000 13:50:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 377 Status: RO Content-Type: text/plain; charset="iso-8859-1" Content-Length: 14040 Dave, It could be, though one wouldn't expect that to happen with such a high loss rate unless the design for allowing for frame growth was very poor or the frames were constructed fairly maliciously. I am still interested in the answers to the question I asked. What are we trying to accomplish with our comments? Regards, Pat -----Original Message----- From: David Martin [mailto:dwmartin@nortelnetworks.com] Sent: Wednesday, October 25, 2000 10:25 AM To: stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Pat, It's possible that the packet loss Roy refers to arises due to the byte stuffing mechanism, where occasionally a 'highly byte stuffed' HDLC frame spills a buffer. It could be argued that such a problem is a design issue. ...Dave -----Original Message----- From: pat_thaler@agilent.com [ mailto:pat_thaler@agilent.com ] Sent: Wednesday, October 25, 2000 8:29 AM To: rabynum@mindspring.com; pat_thaler@agilent.com; Martin, David [SKY:1I63-M:EXCH]; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Roy, I have no doubt that a packet loss of 5% will have severe performance effects. However, the points David made do not explain such a loss rate. It seems most likely that much of the loss you are seeing is because of the particular designs rather than because of the encapsulation. Regards, Pat Thaler -----Original Message----- From: Roy Bynum [ mailto:rabynum@mindspring.com ] Sent: Sunday, October 22, 2000 3:09 PM To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Pat, The points that David has made are valid. I have been building PPP/HDLC and POS IP data networks for years. The effects indicated in all of these points are empirically observed over IP networks that use Packet Over SONET/SDH (POS) links. This is a primary reason that the Internet as it is currently implemented has non-deterministic data jitter and latency. The empirical data loss in the Internet (POS) backbone transport is a much as 5%. 99% of the data loss in due to packets being dropped in the PPP to SONET gearbox with no indication of why. Over design of bandwidth utilization is normalized at minimum of 20% in loaded conditions. The design bandwidth utilization of non-converged redundant network links is at 40% per in order to allow for convergence traffic loading an still have a 20% overhead to account for data expansion due to byte stuffing. As a side issue, ironically, TDM sub-rate PPP link interfaces do not have the data loss that is observed in POS interfaces. The nominal data packet loss is about 1%. Bandwidth utilization design parameters are the same for TDM sub-rate links as they are for POS interfaces. I believe that the reason TDM sub-rate interfaces have a lower packet failure is that the minor clock tolerance adjustment of the self synchronizing data within the TDM payload is at bit level granularity. The clock tolerance adjustment of the self synchronizing data within SONET OCnC or SDH STMnC SPE is at byte level granularity. At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: >David, > >Like most LAN people I'm not a great fan of byte stuffing however, some of >the points you make in >items 2 and 3 seem very stretched and reduce credibility. > >Frame loss effect of frame expansion - The maximum expansion of a frame is >to twice its length. >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and >assuming that errors are >uncorrelated, probability of loosing the frame due to a bit error is: > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > and bits = 1518 * 8 > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not >going to make a significant >difference to throughput and most of the time (unless someone is maliciously >creating expanding frames) >the factor is a lot less than 2. > >What bothers me more is item 3. A bit hit in a frame will trash the frame >whether it creates a false >delimiter, damages a delimiter or just changes data. This is true for all >the existing Ethernet codings. >Once the error ends and a delimiter is received, the following frames will >be received successfully. > >Since a hit on the length field of the protocol proposed for GFP by Nortel >and Lucent causes frame >sync to be lost and a bunch of frames can then be lost until sync has been >regained, it seems that >this might not be a topic you would want to introduce. It really isn't a >weakness for LAPS but a case >can be made for it as a weakness for GFP. > >The point about service impacting effects does have validity at least where >the frame queuing decision >is made disconnected from the LAPS transmission time. If there is a device >with separate queues >for different service levels and it gives the LAPS a frame at a time, only >choosing the next frame >when the last one is being finished, this shouldn't produce much delay. >Worst case is for that is a >lower service level frame delays a higher service level frame for twice the >maximum packet size because >of expansion. If, however, the queuing mechanism is disconnected from >knowledge of LAPS transmission >time, then the effect you are talking about does occur. If for instance, a >switch is feeding stream into >an Ethernet link which is then converted into a LAPS stream and the Sonet >data rate is less than twice >the Ethernet links rate, expansion can introduce as much delay as there is >FIFO provided and too much >expansion can overrun the FIFO causing packet loss. > >What is our objective here? > >My understanding is that the LAPS is almost sure to get approval at this >point. > >LAPS does have some weaknesses and if I was constrained to a byte stuffing >approach, I would have >done it a bit differently. > >It would be better to scramble then delimit because then the scheme would >not be subject to expansion >by unlucky decisions in applications or malicious packet content. Frankly, >the long tail of the distribution >doesn't bother me as long as packet loss due to it is sigificantly below >packet loss due to design bit >error rate. Any of these scrambled rather than block coded transmission >schemes has a distribution >for run lengths of successive 1's or 0's which has a similar very long very >skinny tail. That distribution >can continue on to infinity but as long as the probablity of a run long >enough that the receiver makes >bit errors is low, it doesn't matter how long the tail is. > >Also, I think they put the LSB of each Ethernet byte into the LSB of the >Sonet byte and Sonet sends >MSB first so they reduce the burst error protection of the CRC code - a >mistake that was also made >in 100BASE-T, so it isn't the end of the world - but flipping the byte as it >was put into Sonet would >have been preferable. > >Are we trying to > generate comments about what should be changed to improve the LAPS spec; > generate a justification that will cause the LAPS spec to fail to get >approval; > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; >or > something else? > >Regards, >Pat > >-----Original Message----- >From: David Martin [ mailto:dwmartin@nortelnetworks.com ] >Sent: Friday, October 20, 2000 12:05 PM >To: stds-802-3-etholaps >Subject: Comments On LAPS > > > > >All, > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > >Background > >LAPS is a modified version of PPP with the following similarities: > > > * Uses the same HDLC-like frame >* Uses the same byte-stuffing / flag pattern delineation mechanism >* Supports only point-to-point Layer 2 topology (i.e. no address/label >fields) > >Differences wrt PPP: > > > * Uses a much-simpler version of Link Control Protocol (no >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 >actions, and 11 LCP frame formats") > > * Uses the 'Address' field to identify among IPv4, IPv6, etc. >(PPP fixes it as FF). > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean >that LAPS shares the same drawbacks in throughput performance and the >service effects of flag/byte-stuffing delineation. The following elaborates >on these issues. > >Comments > >Packet based traffic generally requires received frames to be error-free. >Any frames lost due to bit errors within the frame payload or due to loss of >frame delineation will usually trigger a request for re-transmission at a >higher layer. The re-transmission requests will then generate more traffic. >This positive feedback mechanism makes frame loss performance an important >parameter for packet-based traffic in general. > >Three aspects of throughput are discussed: deterministic versus statistical >behaviour, the effect of frame inflation on throughput, and the effect of >delineation performance on throughput. > >1. Deterministic vs Statistical Throughput > >All currently defined Ethernet physical layers provide a deterministic >throughput capacity. The throughput capacity is independent of the data >contents. This is an important attribute, since it permits predictable >performance. > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a >unique one-byte pattern is used to detect both beginning and end of each >frame. To ensure the flag pattern is unique, any occurrences of it must be >removed from the data prior to encapsulation. This is done by replacing each >occurrence of the flag pattern with a sequence of two bytes: a special >'escape' byte, followed by a slightly modified version of the flag pattern. >Because of its special meaning, the 'escape' character must also be >'escaped'. Consequently, the frame length of the payload is inflated in a >non-deterministic manner. Since two byte patterns are replaced by pairs of >bytes, the probability that a random data byte will be 'escaped' is p = >1/128. > >For a frame F bytes long prior to 'escaping', the average frame-length after >'escaping' will be: F' = F + m bytes > >Where F is the un-escaped frame length in bytes > > > m is the mean of the distribution of the number of bytes that >must be escaped in the original F-byte frame > >Assuming random data the number of bytes 'escaped' per F-byte frame follows >a binomial distribution with: > >probability of 'success': p = 2/256 = 1/128 >probability of 'failure': q = 1 - p = 127/128 >number of trials: n = F >mean of the distribution is: m (mu) = np = F*(1/128) bytes >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > >The tail of this distribution is extremely long: it reaches zero only after >a potential doubling of the frame size. > >Non-Random Data > >The assumption of random data could easily be invalidated by applications >that happen to produce the escaped octet values more frequently than a >random process would. > >Vulnerability to Emulation Attacks > >The inflation problem is aggravated by the possibility of emulation attacks. >Malicious users can generate frames with a high density of octet values >which must be 'escaped'. This definitely invalidates the assumption of >random data and skews the distribution towards the worst-case of a doubling >of frame size. > >Service-Impacting Effects of Non-Deterministic Inflation > >The non-deterministic inflation imposed by LAPS byte stuffing could make >tightly controlled frame delay variation (with acceptable absolute delays) >very difficult if not impossible to achieve. The quality of frame-based >real-time services, such as voice-over-IP, would suffer as a consequence. > > >2. LAPS Frame Inflation: Effect on Throughput > >The throughput capacity of an error-free link is inversely related to the >overhead required by a given encapsulation mechanism. The inflation >introduced by LAPS reduces throughput in a non-deterministic manner, by >adding more overhead in an error-free environment. > >Once errors are introduced, throughput is diminished in two ways: random >errors occurring within the frame; and frames lost through loss of >delineation. > >For frames on a link with given BER, the probability of errors within the >frame are a function of the frame length: the longer the frame the higher >the probability of an error occurring in the frame. As seen above, LAPS >inflation can significantly increase the frame length. This degrades the >throughput by providing a larger target for random errors to hit. > >3. LAPS Delineation Performance: Effect on Throughput > >The second factor affecting throughput on a link with non-zero BER is frame >delineation. It is also affected by choice of encapsulation. LAPS frames >rely on error-free matches to the flag pattern to indicate start and end of >frame for every frame. This leads to an unnecessarily high probability of >lost frames due to loss of delineation. This in turn contributes to a lower >absolute throughput than could be realized with a more robust delineation >mechanism. > >More robust delineation mechanisms are possible that are designed to be >error-tolerant. This allows them to coast through random bit errors that >would defeat a flag delineation mechanism. This would reduce the number of >frames lost due to delineation failures. > >Conclusion > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based >delineation are preferable. > > >David W. Martin & Tim Armstrong > Nortel Networks > >========================= From owner-stds-802-3-etholaps@ieee.org Sun Oct 29 20:57 GMT 2000 Received: from gatekeeper.pdd.3com.com (gatekeeper [161.71.169.3]) by isolan.pdd.3com.com (8.9.1b+Sun/8.9.3) with ESMTP id UAA20670 for ; Sun, 29 Oct 2000 20:57:52 GMT Received: from ruebert.ieee.org ([199.172.136.3]) by gatekeeper.pdd.3com.com (Netscape Messaging Server 3.6) with ESMTP id AAA6A75 for ; Sun, 29 Oct 2000 20:56:06 +0000 Received: by ruebert.ieee.org (8.9.3/8.9.3) id PAA03017; Sun, 29 Oct 2000 15:56:02 -0500 (EST) From: pat_thaler@agilent.com Message-ID: <1BEBA5E8600DD4119A50009027AF54A0036B4E43@axcs04.cos.agilent.com> To: rabynum@mindspring.com, pat_thaler@agilent.com, pat_thaler@agilent.com, dwmartin@nortelnetworks.com, stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Date: Sun, 29 Oct 2000 13:55:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-stds-802-3-etholaps@ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org X-Lines: 399 Status: RO Content-Type: text/plain; charset="iso-8859-1" Content-Length: 15274 Roy, If the problem has not been tracked to root cause, then we don't know the cause. There are lots of reasons a design can drop packets. As a customer, you may not be able to get close enough to that root cause to identify it, but the people who design the chips should be able to. If links are designed to have some reasonable room for packet size expansion, then that feature of the LAPS code should not cause a high drop rate. If there is a high drop rate, then probably either the designs are not allowing for enough inefficiency in the links or there is some other type of design problem. Regards, Pat -----Original Message----- From: Roy Bynum [mailto:rabynum@mindspring.com] Sent: Thursday, October 26, 2000 7:44 AM To: pat_thaler@agilent.com; pat_thaler@agilent.com; dwmartin@nortelnetworks.com; stds-802-3-etholaps@ieee.org Subject: RE: Comments On LAPS Pat, Everyone wants to say that it is a design or an implementation problem. If that were the case, then someone would have found the specific implementation solution and fixed it. No one has. This is a problem with ALL implementations. There are NO vendors that do not have these problems in a legacy IP network implementations. It is such a pervasive problem that it is considered as part of the status quo, and a function of IP itself. There is not something within the IP (Layer 3 Only) protocol itself that can be linked to the cause of this data loss. It is not a function of the routing protocols normally used, OSPF and BGP, because RIP exhibits the same data loss. It is not a function of the bit error rate of the physical transport, a 10E-10 to 10E-14 bit error rate does not translate to a 10E-3 to 10E-4 packet error rate. Having eliminated all of the things that can not be the cause of the observed data loss, the only thing that is left is the HDLC and the gear box used to insert the self-synchronizing data stream into the synchronized transport service. I think that 10GbE will help us determine if it is the gearbox or the HDLC. Thank you, Roy Bynum At 06:29 AM 10/25/00 -0600, pat_thaler@agilent.com wrote: >Roy, > >I have no doubt that a packet loss of 5% will have severe performance >effects. >However, the points David made do not explain such a loss rate. It seems >most >likely that much of the loss you are seeing is because of the particular >designs >rather than because of the encapsulation. > >Regards, >Pat Thaler > >-----Original Message----- >From: Roy Bynum [mailto:rabynum@mindspring.com] >Sent: Sunday, October 22, 2000 3:09 PM >To: pat_thaler@agilent.com; dwmartin@nortelnetworks.com; >stds-802-3-etholaps@ieee.org >Subject: RE: Comments On LAPS > > > >Pat, > >The points that David has made are valid. I have been building PPP/HDLC >and POS IP data networks for years. The effects indicated in all of these >points are empirically observed over IP networks that use Packet Over >SONET/SDH (POS) links. This is a primary reason that the Internet as it is >currently implemented has non-deterministic data jitter and latency. > >The empirical data loss in the Internet (POS) backbone transport is a much >as 5%. 99% of the data loss in due to packets being dropped in the PPP to >SONET gearbox with no indication of why. Over design of bandwidth >utilization is normalized at minimum of 20% in loaded conditions. The >design bandwidth utilization of non-converged redundant network links is at >40% per in order to allow for convergence traffic loading an still have a >20% overhead to account for data expansion due to byte stuffing. > >As a side issue, ironically, TDM sub-rate PPP link interfaces do not have >the data loss that is observed in POS interfaces. The nominal data packet >loss is about 1%. Bandwidth utilization design parameters are the same for >TDM sub-rate links as they are for POS interfaces. > >I believe that the reason TDM sub-rate interfaces have a lower packet >failure is that the minor clock tolerance adjustment of the self >synchronizing data within the TDM payload is at bit level granularity. The >clock tolerance adjustment of the self synchronizing data within SONET OCnC >or SDH STMnC SPE is at byte level granularity. > > >At 05:56 PM 10/20/00 -0600, pat_thaler@agilent.com wrote: > > >David, > > > >Like most LAN people I'm not a great fan of byte stuffing however, some of > >the points you make in > >items 2 and 3 seem very stretched and reduce credibility. > > > >Frame loss effect of frame expansion - The maximum expansion of a frame is > >to twice its length. > >For a 1518 byte frame and a relatively bad bit error rate of 10e-9 and > >assuming that errors are > >uncorrelated, probability of loosing the frame due to a bit error is: > > > > 1 - ((Pgoodbit)^bits ~ 0.0012%) > > > >where Pgoodbit is the probability that a bit is not errored = 1 - BER > > and bits = 1518 * 8 > > > >doubling the number of bits changes this to 0.0024%. A factor of 2 is not > >going to make a significant > >difference to throughput and most of the time (unless someone is >maliciously > >creating expanding frames) > >the factor is a lot less than 2. > > > >What bothers me more is item 3. A bit hit in a frame will trash the frame > >whether it creates a false > >delimiter, damages a delimiter or just changes data. This is true for all > >the existing Ethernet codings. > >Once the error ends and a delimiter is received, the following frames will > >be received successfully. > > > >Since a hit on the length field of the protocol proposed for GFP by Nortel > >and Lucent causes frame > >sync to be lost and a bunch of frames can then be lost until sync has been > >regained, it seems that > >this might not be a topic you would want to introduce. It really isn't a > >weakness for LAPS but a case > >can be made for it as a weakness for GFP. > > > >The point about service impacting effects does have validity at least where > >the frame queuing decision > >is made disconnected from the LAPS transmission time. If there is a device > >with separate queues > >for different service levels and it gives the LAPS a frame at a time, only > >choosing the next frame > >when the last one is being finished, this shouldn't produce much delay. > >Worst case is for that is a > >lower service level frame delays a higher service level frame for twice the > >maximum packet size because > >of expansion. If, however, the queuing mechanism is disconnected from > >knowledge of LAPS transmission > >time, then the effect you are talking about does occur. If for instance, a > >switch is feeding stream into > >an Ethernet link which is then converted into a LAPS stream and the Sonet > >data rate is less than twice > >the Ethernet links rate, expansion can introduce as much delay as there is > >FIFO provided and too much > >expansion can overrun the FIFO causing packet loss. > > > >What is our objective here? > > > >My understanding is that the LAPS is almost sure to get approval at this > >point. > > > >LAPS does have some weaknesses and if I was constrained to a byte stuffing > >approach, I would have > >done it a bit differently. > > > >It would be better to scramble then delimit because then the scheme would > >not be subject to expansion > >by unlucky decisions in applications or malicious packet content. Frankly, > >the long tail of the distribution > >doesn't bother me as long as packet loss due to it is sigificantly below > >packet loss due to design bit > >error rate. Any of these scrambled rather than block coded transmission > >schemes has a distribution > >for run lengths of successive 1's or 0's which has a similar very long very > >skinny tail. That distribution > >can continue on to infinity but as long as the probablity of a run long > >enough that the receiver makes > >bit errors is low, it doesn't matter how long the tail is. > > > >Also, I think they put the LSB of each Ethernet byte into the LSB of the > >Sonet byte and Sonet sends > >MSB first so they reduce the burst error protection of the CRC code - a > >mistake that was also made > >in 100BASE-T, so it isn't the end of the world - but flipping the byte as >it > >was put into Sonet would > >have been preferable. > > > >Are we trying to > > generate comments about what should be changed to improve the LAPS >spec; > > generate a justification that will cause the LAPS spec to fail to get > >approval; > > propose criteria for when LAPS should be used versus GFP and 10GBASE-W; > >or > > something else? > > > >Regards, > >Pat > > > >-----Original Message----- > >From: David Martin [mailto:dwmartin@nortelnetworks.com] > >Sent: Friday, October 20, 2000 12:05 PM > >To: stds-802-3-etholaps > >Subject: Comments On LAPS > > > > > > > > > >All, > > > >Some comments on LAPS (Draft X.86, April 2000) to get the ball rolling. > > > >Background > > > >LAPS is a modified version of PPP with the following similarities: > > > > > > * Uses the same HDLC-like frame > >* Uses the same byte-stuffing / flag pattern delineation mechanism > >* Supports only point-to-point Layer 2 topology (i.e. no >address/label > >fields) > > > >Differences wrt PPP: > > > > > > * Uses a much-simpler version of Link Control Protocol (no > >'Protocol' field, so no LCP frames; only 2 states instead of "16 events, 12 > >actions, and 11 LCP frame formats") > > > > * Uses the 'Address' field to identify among IPv4, IPv6, >etc. > >(PPP fixes it as FF). > > > >The simplified LCP is laudable, but the similarities to PPP/HDLC/SDH mean > >that LAPS shares the same drawbacks in throughput performance and the > >service effects of flag/byte-stuffing delineation. The following elaborates > >on these issues. > > > >Comments > > > >Packet based traffic generally requires received frames to be error-free. > >Any frames lost due to bit errors within the frame payload or due to loss >of > >frame delineation will usually trigger a request for re-transmission at a > >higher layer. The re-transmission requests will then generate more traffic. > >This positive feedback mechanism makes frame loss performance an important > >parameter for packet-based traffic in general. > > > >Three aspects of throughput are discussed: deterministic versus statistical > >behaviour, the effect of frame inflation on throughput, and the effect of > >delineation performance on throughput. > > > >1. Deterministic vs Statistical Throughput > > > >All currently defined Ethernet physical layers provide a deterministic > >throughput capacity. The throughput capacity is independent of the data > >contents. This is an important attribute, since it permits predictable > >performance. > > > >For byte-oriented LAPS, frame delineation uses a simple flag mechanism: a > >unique one-byte pattern is used to detect both beginning and end of each > >frame. To ensure the flag pattern is unique, any occurrences of it must be > >removed from the data prior to encapsulation. This is done by replacing >each > >occurrence of the flag pattern with a sequence of two bytes: a special > >'escape' byte, followed by a slightly modified version of the flag pattern. > >Because of its special meaning, the 'escape' character must also be > >'escaped'. Consequently, the frame length of the payload is inflated in a > >non-deterministic manner. Since two byte patterns are replaced by pairs of > >bytes, the probability that a random data byte will be 'escaped' is p = > >1/128. > > > >For a frame F bytes long prior to 'escaping', the average frame-length >after > >'escaping' will be: F' = F + m bytes > > > >Where F is the un-escaped frame length in bytes > > > > > > m is the mean of the distribution of the number of bytes >that > >must be escaped in the original F-byte frame > > > >Assuming random data the number of bytes 'escaped' per F-byte frame follows > >a binomial distribution with: > > > >probability of 'success': p = 2/256 = 1/128 > >probability of 'failure': q = 1 - p = 127/128 > >number of trials: n = F > >mean of the distribution is: m (mu) = np = F*(1/128) bytes > >standard deviation is: s (sigma) = sqrt (npq) = sqrt (F*127) / 128 > > > >The tail of this distribution is extremely long: it reaches zero only after > >a potential doubling of the frame size. > > > >Non-Random Data > > > >The assumption of random data could easily be invalidated by applications > >that happen to produce the escaped octet values more frequently than a > >random process would. > > > >Vulnerability to Emulation Attacks > > > >The inflation problem is aggravated by the possibility of emulation >attacks. > >Malicious users can generate frames with a high density of octet values > >which must be 'escaped'. This definitely invalidates the assumption of > >random data and skews the distribution towards the worst-case of a doubling > >of frame size. > > > >Service-Impacting Effects of Non-Deterministic Inflation > > > >The non-deterministic inflation imposed by LAPS byte stuffing could make > >tightly controlled frame delay variation (with acceptable absolute delays) > >very difficult if not impossible to achieve. The quality of frame-based > >real-time services, such as voice-over-IP, would suffer as a consequence. > > > > > >2. LAPS Frame Inflation: Effect on Throughput > > > >The throughput capacity of an error-free link is inversely related to the > >overhead required by a given encapsulation mechanism. The inflation > >introduced by LAPS reduces throughput in a non-deterministic manner, by > >adding more overhead in an error-free environment. > > > >Once errors are introduced, throughput is diminished in two ways: random > >errors occurring within the frame; and frames lost through loss of > >delineation. > > > >For frames on a link with given BER, the probability of errors within the > >frame are a function of the frame length: the longer the frame the higher > >the probability of an error occurring in the frame. As seen above, LAPS > >inflation can significantly increase the frame length. This degrades the > >throughput by providing a larger target for random errors to hit. > > > >3. LAPS Delineation Performance: Effect on Throughput > > > >The second factor affecting throughput on a link with non-zero BER is frame > >delineation. It is also affected by choice of encapsulation. LAPS frames > >rely on error-free matches to the flag pattern to indicate start and end of > >frame for every frame. This leads to an unnecessarily high probability of > >lost frames due to loss of delineation. This in turn contributes to a lower > >absolute throughput than could be realized with a more robust delineation > >mechanism. > > > >More robust delineation mechanisms are possible that are designed to be > >error-tolerant. This allows them to coast through random bit errors that > >would defeat a flag delineation mechanism. This would reduce the number of > >frames lost due to delineation failures. > > > >Conclusion > > > >Mapping approaches for Ethernet over SONET/SDH which do not use flag-based > >delineation are preferable. > > > > > >David W. Martin & Tim Armstrong > > Nortel Networks > > > >========================= From owner-stds-802-3-etholaps@ieee.org Mon Nov 20 15:37 GMT 2000 From: "David Martin" To: stds-802-3-etholaps@ieee.org Subject: ITU-T SG7 Liaison Reply Date: Mon, 20 Nov 2000 09:27:25 -0500 MIME-Version: 1.0 X-Orig: X-Resent-To: Multiple Recipients X-Listname: stds-802-3-etholaps X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: stds-802-3-etholaps-approval@majordomo.ieee.org Roy, At the closing plenary in Tampa, I recall an agreement that you & Geoff were going to generate a response to SG7 to close the liaison action. Has that been done? Can we see the letter? Thanks. ...Dave David W. Martin Nortel Networks