Subject: I-D ACTION:draft-ietf-pppext-sdl-04.txt

From: [email-masked]
Date: Tue, 07 Sep 1999 07:12:47 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: PPP over Simple Data Link (SDL) using SONET/SDH with 
                          ATM-like framing
	Author(s)	: J. Carlson,  P. Langner, E.J. Hernandez Valencia,
                          J. Manchester
	Filename	: draft-ietf-pppext-sdl-04.txt
	Pages		: 29
	Date		: 03-Sep-99
	
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links, and
RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over
Synchronous Optical Network (SONET) [4] and Synchronous Digital
Hierarchy (SDH) [5] circuits.  This document extends these standards
to include a new encapsulation for PPP called Simple Data Link (SDL)
[6].  SDL provides a very low overhead alternative to standard HDLC
encapsulation, and can also be used on SONET/SDH links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-sdl-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pppext-sdl-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pppext-sdl-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 7 Sep 1999 14:26:42 -0700

Hi,

I have found the following errors/shortcomings in this draft:

1) Section 4.4

False Sync can occur when a False Framing has occurred even if the scrambler
state message is correct. That is due to the fact that the header is not
scrambled, and therefore the two consecutive false CRC-16 match headers are
removed and are not descrambled, causing the other data bits to be in wrong
descrambling/sync position.

PFS = PFF  = 2^-16 = 1.5 E-5

rather than the very low value of 54.21 E-21 in the document.

2) Section 4.4

In first paragraph it is written 232.8E-21 = 2^-32 which is wrong and should
be 232.8 E-12 = 2.328 E-10

3) In almost all probabilities the scientific notation should include only
one decimal point before the fraction point like 3.679 E-1  rather than
367.9 E-3. Because this is the proper use of scientific notation and it
prevents the probabilities to look better than what they are at first
glance.

4) Section 4.1

Average packet is 354 bytes not 384 bytes.

5)In Applicability section

It can be easily shown that in the absence of malicious user, O-S HDLC adds
less than 1% overhead, and also O-S HDLC has one byte less fixed header
overhead than SDL. Therefore statements like "Significant higher throughput
can be obtained" is not correct. Besides SDL cost is higher than O-S HDLC
because you require multiple parallel framers, and you need to still have
the O-S HDLC (as default)and therefore you require both HDLC and SDL which
makes the equipment more complicated and more expensive.

6) Security section 

One potential security problem (in set-reset scrambler), which is not
mentioned, is the possibility of a Malicious user transmitting consecutive
data looking like Length+CRC16 which can significantly increase MTTF
(remember the set-rest scrambler can't help because it is disabled before
frame Sync. is achieved). For example a packet containing: FF CRC16 FF CRC16
FF CRC16 ... ,in which CRC16 is calculated over FF, can increase MTTF for
354 byte average packet to 185 packets rather than normal 1.5 packets.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 07, 1999 4:13 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pppext-sdl-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working
Group of the IETF.

	Title		: PPP over Simple Data Link (SDL) using SONET/SDH
with 
                          ATM-like framing
	Author(s)	: J. Carlson,  P. Langner, E.J. Hernandez Valencia,
                          J. Manchester
	Filename	: draft-ietf-pppext-sdl-04.txt
	Pages		: 29
	Date		: 03-Sep-99

Send a message to:
	[email-masked].
In the body type:

---

From: Shahram Davari <[email-masked]>
Date: Wed, 8 Sep 1999 14:51:05 -0700

Hi Enrique,

In the order of questions:

1) According to page 9 of the draft "The Scrambler is not clocked when SDL
header bits are transmitted". 

3) Sorry, I didn't mean that it was done in purpose.

4) I took the 354 bytes from some other Lucent's SDL paper, which had
exactly the same final service unavailability results.

5) Let's not generalize special cases. For example one can argue that in
voice applications which have very short packets, SDL has less throughput
than HDLC, because SDL has 8 bytes fixed header, vs. 7 bytes in HDLC. Plus
the fact that using set-reset scrambler requires one state transmission
every 8 frames. Now is one allowed to state "HDLC has higher throughput than
SDL"?

If you don't include parallel framers the performance will suffer. And if
you don't include HDLC, you will face interoperability issue.

6) As in (1) during miss-framing period wrong number of bits are potentially
passed through descrambler, and therefore your descrambler state and
therefore your byte sync. is wrong. And as you agree MTTF will also suffer.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 08, 1999 11:56 AM
To: [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pppext-sdl-04.txt

> descrambling/sync position.

You must still pass 2 header CRC-16s and 2 payload CRC-16s ...

> be 232.8 E-12 = 2.328 E-10

Right (transposed numbers 21 vs 12). Thanks, we'll correct that.
 
> prevents the probabilities to look better than what they are at first

No need to look for ulterior motives, you only need to ask.

> Average packet is 354 bytes not 384 bytes.

We seem to be using slightly different assumptions.
 
> can be obtained" is not correct. 

As you point out, the distinction is between short-term vs long-term 
throughputs, particularly for applications that natively generate large 
numbers of (relevant) control characters.

> Besides SDL cost is higher than O-S HDLC

Neither is required. Besides, the cost of implemented SDL in some chipsets 
is so low that you almost get it for free.

> 354 byte average packet to 185 packets rather than normal 1.5 packets.

We seem to be taking about a different mechanism. Still, such a packet 
cannot, by itself, force link re-synchronization (as was the issue for the 
killer packet). Thus, the probability of link resynch (already quite low) is

independent of the packet payload, which makes the overall probability of
such 
an event rather small. If this rare event does happen (link fails, only one 
framer, next frame is a malicious user frame)  it can only delay the 
time to frame, as oppose to bringing down the link.

Thanks for the comments,
Enrique