Subject: Juniper's ID

From: [email-masked] (Subra Dravida)
Date: Wed, 5 Nov 97 14:46:38 EST

Dennis, Ravi,

I read your ID on scrambler - well researched work!            
I have the following comments.

1. I agree with you on the location of the scrambler.
You can't locate it in front of the HDLC framer because at the
receiver the deframer will discard packets for failed CRCs
and scramblers need to work with a continuous bit stream.

If it were possible to locate the scrambler in front of the framer
it would have solved another problem - where the user deliberately
and continuously sends flag octets in his/her datagrams.  
Right now, becuase of byte stuffing the packet size will get doubled
and this messes with bandwidth and QOS management.
Putting the scrambler ahead of the framer can only be done
if the HDLC deframer when it encounters a packet with a failed CRC,
still passes up the data through the scrambler to the
higher layer along with a primitive saying that the data is errored
and the application may choose to use it or discard it (a real time
application may choose to use it).

2. The choice of the ATM self-synchronizing scrambler in the ATM world
was shortsighted. It has haunted us many times.
When AAL-2 (ATM adaptation layer -2) was being designed for
wireless and PBX trunking applications the scrambler messed with self-delineation
and even correction options.

When pure ATM (not ATM on SONET but ATM on any transmission medium) 
also called cell based ATM was standardized the self-synchronizing
scrambler was avoided because of the error multiplication it creates.
Instead a continuously running pseudo-random sequence generator was
standardized.

3. You have examined effect of the scramblers on short bursts
in great detail.
Did you also examine the impact on minimum Hamming distance as well?
For example, the CRC-16 provides a minimum Hamming distance of 4 without the
scramblers.
If you scramble it using the self-synchronizing scrambler 1+x**23+x**43,
then depending on error loacations the Hamming distance may be reduced.
For example in a 1428 byte packet, the error polynomial 1+x**20+x**11396+x**11419 which can occur when the last two correlated errors of the scrambler
fall at the beginning of the packet and the first two errors occur at the end of the
packet then the errors go undetected by the 16 bit CRC.

4. There is a much bigger issue concerning error multiplication
in HDLC which I think outweighs error multiplication created by the
scramblers.
When a data octet is errored to look like a flag, HDLC prematurely
terminates the packet creating a huge burst of errors.
You basically have to fall back on the burst error detection
capability of the CRC whihc is 2**-16.
Mind you, a single error in the right octet can create this burst.
Assuming all data octets are random, the proability that an octet is
one bit away from the flag is 1/256.
However if there are N data octets and as N gets bigger than 256
(at 1000 bytes there is 98% chance that at least one octet is of this
kind) there is a good chance of having an octet of this kind.
Then the overall probability of having an error and not
detecting is p*2**-16 where p is the bit error rate.
In terms of effective minimum hamming distance we are down to one.

On SONET lines the BER is expected to be 10**-8 or better depending
on how well they are maintained.

The main source of burst errors on SONET are protection switches
which occur on the order of once a day and it takes a few tens of
milliseconds to recover from protection switches.
During this period you basically have a wipe out.
At SONET speeds, there can be a random error every second at 10**-8
BER and it looks like this situation determines error performance.

Tinkering with the self-synchronizing scrambler to protect against burst error events is
not likely to help very much.
That is why, when we proposed the non-self-synchronizing scrambler,
we were not worried that a few hundred microseconds would be added
to a burst recovery event that has already lasted a few tens
of milliseconds.

Subra Dravida 
[email-masked]

---

From: Dennis Ferguson <[email-masked]>
Date: Wed, 05 Nov 1997 22:34:13 -0800

Subra,

While the draft certainly doesn't make it clear I personally think
that issues such as short burst detection and minimum Hamming distance
are pretty much esoterica, the considerations you use to make choices
between alternatives when there are no more important issues which
distinguish them.  The sole reason for spending the text on short
bursts is that there is an issue with bit ordering through the scrambler
which needs addressing, and we wanted to point out that if all other
considerations turn out to be equal there is an esoteric reason to
prefer consistent bit ordering from the CRC through the scrambler,
and even onto the wire.

In comparison systematically halving the long burst error detection
probability of the 16 bit CRC, which is what the ATM scrambler does,
is a serious issue, particularly because, as you point out, errors
which cause relatively long sequences of junk to be generated on
circuits are common and the long burst detection capability of the
CRC is the only thing that stands between those errors and the upper
layers (not that the upper layers necessarily can't deal with such
boo-boo's, it is just that doubling the number of mistakes made by
the link layer protection is not going to make things better).  It
is this, and only this, issue which we wanted to point out appeared
repairable by "tinkering" with the scrambler polynomial, the fact that
the same repair also happened to fix a short burst problem being a happy,
but mostly unimportant, coincidence.

I agree that using a self-synchronous scrambler for ATM is weird, but
would point out that HDLC doesn't even pretend to have any of the
grand aspirations of ATM.  Considering the more modest goals of HDLC
alone it is difficult to find differences between a self synchronous
scrambler and anything else that are worth caring about, except that
a self-synchronous scrambler is a whole lot easier and more flexible
to implement and, as a result, a whole lot more likely to be implementable
on existing equipment and interoperable out of the box.  I'd even
venture the opinion that HDLC is not likely to become the ultimate grand
unified minimum-baggage framing protocol for SONET, for some of the
reasons you've pointed out, but it is what we've got now and it works
pretty well for what it gets used for currently so taking the path of
least resistance to keeping it well working until there is something
better for the application seems most appropriate to me.

I would also point out that I am not personally all that attached to the
three tap scrambler, and in fact was not very happy to discover the
ATM scrambler's interaction with the 16 bit CRC in the first place.  I'd
just note that if the preservation of the 16 bit CRC for HDLC over SONET
needs to be a goal (an issue I'm personally not competent to judge, this
needs to come from operators of the equipment) then adding the third tap
needs to be considered.

Dennis Ferguson

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Nov 1997 18:42:24 +0100 (MET)

> and this messes with bandwidth and QOS management.

Has anyone started work on using COBS-style stuffing with PPP (see ACM
SIGCOMM '97)?  This would increase per-packet overhead by one byte in
many cases, but limit the worst-case overhead to the theoretical
minimum of about 1/255 (long packets).

If the PPP to SONET mapping has to be changed anyway, this might be a
good time to look at the state of the art for PPP framing formats.

Gruesse, Carsten

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Nov 1997 06:24:04 -0500

> good time to look at the state of the art for PPP framing formats.

Yes, I have worked with Stuart Cheshire (one of the two authors of
COBS) and written an I-D for this.  I sent it to the PPP chair for
consideration last week.

-- 
James Carlson, Consulting Engineer                <[email-masked]>
IronBridge Networks / 5 Corporate Drive            Vox:  +1 978 691 4644
Andover MA  01810-2448 / USA                       Fax:  +1 978 691 6300