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

From: [email-masked]
Date: Wed, 8 Sep 1999 14:56:05 -0400 (EDT)

Shahram_Davari wrote:
> 
> 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.

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

> 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

Right (transposed numbers 21 vs 12). Thanks, we'll correct that.
 
> 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.

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

> 4) Section 4.1
> 
> Average packet is 354 bytes not 384 bytes.

We seem to be using slightly different assumptions.
 
> 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. 

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

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

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

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

---

From: James Carlson <[email-masked]>
Date: 08 Sep 1999 17:19:52 -0400

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

Yes, I agree that the way I'm using scientific notation here is not
standard.  I chose to do this so that the numbers would be a little
easier to read, not to obscure the statistics -- they're in groups of
3.

If it makes anyone any happier at all, I'll forgo trying to get the
decimals to line up, and switch to straight X.XXXE-YY format while I
fix the typo.

> We seem to be using slightly different assumptions.

The "average" packet size is not a fixed thing.  It has been changing
over time and certain varies depending on whose network you're
monitoring and which particular links.  I have assumed 384 here
because larger packets are actually *WORSE* for SDL in terms of
unavailability, since larger packets mean fewer opportunities for
synchronization.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp