Framing errors with TCP-IP

robertwessel2@yahoo.com meinte am 12.08.03
zum Thema "Re: Framing errors with TCP-IP":

> I think "self-clocking" is probably synonymous with your term
> "adjust for any skew".

At least what Ethernet is concerned, I think so.

> All synchronous protocols need periodic "clock deskewing".  If you

Absolutely. Yes.

> attempted to just match clock rates over the course of a single
> 1500 byte Ethernet packet without any reclocking, you'd need the
> sender's and receiver's clocks synchronized within less than 1 part
> per 24000 (which would be darn tough), or the receiver would drift
> complete off data bits by the end of the frame.  The receiver's
> clock *is* synchronized during the preamble, but is continuously
> resync'd as clock signals go by.  With various tweaks, this is true
> of all synchronous line disciplines.

Nevertheless, refering to the posed question, in my opionion
Ethernet is an asynchronous protocol. And this becomes even more
clear from your remarks: It is no trivial task to even keep
a receiver synchronized with "the packet's clock" for the
duration of the frame. After the frame has ended, the receiver
is not synchronous at all with either potential sender.

> Manchester encoding provides a fairly continuous stream of clock
> transitions with a very simple implementation, but requires
> considerable extra signal bandwidth (x2).  Manchester encoding

I see. So, what about Differential Manchester encoding, as it=20
is used in Token Ring. How large is the bandwith overhead=20
with this encoding scheme?=20

> guarantees at least one signal transition for each bit (although
> there will be 1.5 on average).  This means that the receiver needs
> only to be able to sync his clock to within 20% or so of the
> senders (although in practice it's much better than that).

What about the according guarantees in Differential Manchester
Enconding? I have to admit: I never really thought about this in
detail, but it would be interesting to know about this one.

A last question: Just refering to the original question: Would
you categorize Ethernet as an asynchronous protocol or as a=20
synchronous protocol? Myself, I tend to categorize it as an
asynchronous protocol, but when I talked to some colleagues no
one agreed or disagreed, they simply did not have a clear opinion
here ...

DB
--
Mit so einen begrenzten,dass ich gar nicht sage psychisch- retardierten
Individuum,m=F6chte ich mich keinesfalls weiter
rekreieren.
(Hannelore Brigic in d.s.w.c.)

robertwessel2@yahoo.com meinte am 12.08.03
zum Thema "Re: Framing errors with TCP-IP":

> Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message
> news:<8rmLtkvjSJB@Detlef.Bosau>...
>> (...)
>> In my opinion, Manchester Encoding is chosen
>> amongst others for bandwidth reasons (the signal bandwidth
>> is different depending on the coding scheme you chose) and
>> perhaps even to keep the line free from direct current.


> BTW, Manchester encoding does not eliminate DC current flow,
> although differential Manchester does.

Could you please explain this a little bit more detailed?
I think, this is interesting.

Thank you!

DB
--
Mit so einen begrenzten,dass ich gar nicht sage psychisch- retardierten
Individuum,m=F6chte ich mich keinesfalls weiter
rekreieren.
(Hannelore Brigic in d.s.w.c.)

Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message news:<8rmQCLPjSJB@Detlef.Bosau>...
> > attempted to just match clock rates over the course of a single
> > 1500 byte Ethernet packet without any reclocking, you'd need the
> > sender's and receiver's clocks synchronized within less than 1 part
> > per 24000 (which would be darn tough), or the receiver would drift
> > complete off data bits by the end of the frame.  The receiver's
> > clock *is* synchronized during the preamble, but is continuously
> > resync'd as clock signals go by.  With various tweaks, this is true
> > of all synchronous line disciplines.
> 
> Nevertheless, refering to the posed question, in my opionion
> Ethernet is an asynchronous protocol. And this becomes even more
> clear from your remarks: It is no trivial task to even keep
> a receiver synchronized with "the packet's clock" for the
> duration of the frame. After the frame has ended, the receiver
> is not synchronous at all with either potential sender.


In all usage I am familiar with, "synchronous" line disciplines are
defined by the fact that they maintain clock synchronization over an
entire frame.  This usage goes back all the way to Bisync (and
probably earlier), where each frame was preceded by at least a couple
of SYN bytes, and terminated with an ETX (or some variant of that) -
IOW, just like an Ethernet preamble and ending delimiter.

Requiring that the receiver must be perpetually clock synchronized
with the sender would require continuous transmission by the sender,
and rule out any sort of broadcast based shared media environment that
doesn't provide for a continuous clock distribution (you'd have to
keep *all* stations exactly synchronized).  Even bisync allowed
multi-drop configurations where several modems were attached to a
single line.


> > Manchester encoding provides a fairly continuous stream of clock
> > transitions with a very simple implementation, but requires
> > considerable extra signal bandwidth (x2).  Manchester encoding
> 
> I see. So, what about Differential Manchester encoding, as it 
> is used in Token Ring. How large is the bandwith overhead 
> with this encoding scheme? 


Differential Manchester encoding has the same overhead as straight
Manchester.


> What about the according guarantees in Differential Manchester
> Enconding? I have to admit: I never really thought about this in
> detail, but it would be interesting to know about this one.


You still get at least one transition per bit.

Other schemes are in common use.  For example, 100base-TX (the common
form of Fast Ethernet) uses a 5/4 encoding scheme on top of a three
level signal scheme, which keeps the bandwidth requirement at 1.25x
the data rate (compared to 2x for 10Mbps Ethernet).  Copper GigE uses
a five level scheme (netting two bits per signal with some signal &#4294967295;
about .3 bits - left over for clocking and whatnot), transmitted over
all four pairs in parallel, at the same 125MHz rate as Fast Ethernet
(125x2x4=1000).


> A last question: Just refering to the original question: Would
> you categorize Ethernet as an asynchronous protocol or as a 
> synchronous protocol? Myself, I tend to categorize it as an
> asynchronous protocol, but when I talked to some colleagues no
> one agreed or disagreed, they simply did not have a clear opinion
> here ...


Definitely synchronous, as explained above.

Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message news:<8rmQCZ1jSJB@Detlef.Bosau>...
> robertwessel2@yahoo.com meinte am 12.08.03
> zum Thema "Re: Framing errors with TCP-IP":
> > BTW, Manchester encoding does not eliminate DC current flow,
> > although differential Manchester does.
> 
> Could you please explain this a little bit more detailed?
> I think, this is interesting.


I had a bit of a brain fade when I wrote that: neither straight
Manchester or Differential Manchester have any DC current flow.

With Manchester, you always have a transition in the middle of each
bit, thus half of each bit is transmitted at +Vx, and half at &#4294967295;Vx
(presumably driving the same load, thus current is the same in both
cases), thus netting zero net current flow.  In straight Manchester, a
"one" is distinguished by a &#4294967295;Vx at the start of the bit, in
Differential Manchester a "one" bit is distinguished by an additional
transition at the beginning of a bit.

Anyway, you want to avoid DC current flow because the entire
transmission system, including the transmitter electronics, the wire,
and the receiver electronics, has numerous components that can act as
capacitors, and store energy.  If there's DC current flow, things can
get charged up, which by itself can lead to saturation on transistors,
which can lead to reduced sensitivity or responsiveness at the
receiver, or just present a higher net impedance for any additional
signal with the same DC polarity.  And once charged up, it'll
discharge when the DC polarity reverses, which will almost certainly
result in a large burst of noise on the line.  If your signaling
scheme has DC current flow, you generally need to provide some method
for draining the current away before any of the bad things happen. 
It's typically easier just to avoid the problem in the first place.

Robert Wessel wrote:
> 
>  ...
> 
> Requiring that the receiver must be perpetually clock synchronized
> with the sender would require continuous transmission by the sender,
> and rule out any sort of broadcast based shared media environment that
> doesn't provide for a continuous clock distribution (you'd have to
> keep *all* stations exactly synchronized).    ...

There's no way to do that in the general case of point-to-point
messaging with significant (relative to a bit time) transit delay.
Remember that ETHERnet originated as a radio link protocol in the
Hawaiian islands. The basic CDMA (collision detect/multiple access)
scheme made co-channel operation possible.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

robertwessel2@yahoo.com meinte am 13.08.03
zum Thema "Re: Framing errors with TCP-IP":

>> Nevertheless, refering to the posed question, in my opionion
>> Ethernet is an asynchronous protocol. And this becomes even more
>> clear from your remarks: It is no trivial task to even keep
>> a receiver synchronized with "the packet's clock" for the
>> duration of the frame. After the frame has ended, the receiver
>> is not synchronous at all with either potential sender.


> In all usage I am familiar with, "synchronous" line disciplines are
> defined by the fact that they maintain clock synchronization over
> an entire frame.  This usage goes back all the way to Bisync (and
> probably earlier), where each frame was preceded by at least a
> couple of SYN bytes, and terminated with an ETX (or some variant of
> that) - IOW, just like an Ethernet preamble and ending delimiter.

> Requiring that the receiver must be perpetually clock synchronized
> with the sender would require continuous transmission by the

That's what's being done in SDH, PDH, ATM, IOW: all the line
switched networks. And, cum grano salis, in Token Ring and FDDI as well
as there is a token rotating continously.

> sender, and rule out any sort of broadcast based shared media
> environment that doesn't provide for a continuous clock
> distribution (you'd have to keep *all* stations exactly

When you leave out TR and FDDI, you're right. Of course, the line
switched disciplines mentioned above don't cover broadcast multiple
access networks.


>> A last question: Just refering to the original question: Would
>> you categorize Ethernet as an asynchronous protocol or as a
>> synchronous protocol? Myself, I tend to categorize it as an
>> asynchronous protocol, but when I talked to some colleagues no
>> one agreed or disagreed, they simply did not have a clear opinion
>> here ...


> Definitely synchronous, as explained above.

It's still somewhat confusing to me, but eventually it's a matter
of definition.=20

Nevertheless: When you definie synchronous with respect to a frame
and the receiver, how would an asynchronous network work then?
Would this be impossible?

DB
--
Mit so einen begrenzten,dass ich gar nicht sage psychisch- retardierten
Individuum,m=F6chte ich mich keinesfalls weiter
rekreieren.
(Hannelore Brigic in d.s.w.c.)

In article <8ruVvhSzSJB@Detlef.Bosau>,
Detlef Bosau <Detlef.Bosau@tesionmail.de> wrote:

> ...
>> sender, and rule out any sort of broadcast based shared media
>> environment that doesn't provide for a continuous clock
>> distribution (you'd have to keep *all* stations exactly
>
>When you leave out TR and FDDI, you're right. Of course, the line
>switched disciplines mentioned above don't cover broadcast multiple
>access networks.

From what I recall of FDDI, there is no continuous clock.  It's a more
complicated than either having or not having one, what with the
"elasticity buffer" and so forth.  FDDI on fiber used 4B/5B encoding
but also an elasticity buffer in every MAC (or was it the PHY?) to
accumulate clock differences and insert or remove idle symbols.  Is
adding or removing symbols more like fiddling with stop bits or more
like bit stuffing?

> ...
>> Definitely synchronous, as explained above.
>
>It's still somewhat confusing to me, but eventually it's a matter
>of definition.
>
>Nevertheless: When you definie synchronous with respect to a frame
>and the receiver, how would an asynchronous network work then?
>Would this be impossible?

I don't see the value in such exegesis.  Instead of trying to decide
whether FDDI is (a)syncrhonous, why not just learn how FDDI works?
The right or wrong superficial global (a)synchronous label won't change
the protocol.  It also won't tell you on how it works.

As far as I can recall, "asynchronous" link layer protocols deal with
clock problems by jiggering "stop" and "start" bits, while "synchronous"
protocols use "bit stuffing."  I think protocols that user neither of
those two specific, ancient tactics are neither fish nor fowl.


Vernon Schryver    vjs@rhyolite.com

Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message news:<8ruVvhSzSJB@Detlef.Bosau>...
> > Requiring that the receiver must be perpetually clock synchronized
> > with the sender would require continuous transmission by the
> 
> That's what's being done in SDH, PDH, ATM, IOW: all the line
> switched networks. And, cum grano salis, in Token Ring and FDDI as well
> as there is a token rotating continously.


All of which are essentially a collection of point-to-point links,
where it's possible to have continuous transmission.  In any event
token rings (both "Token Ring" and "FDDI") are a bit more complex in
how closely synchronized the clocks are.  There is no inherent
requirement in a ring that the clocks are precisely synchronized, so
long as some buffering is available.  Token Ring sets things up so
that the clocks *do* have to be closely synchronized, while FDDI
(IIRC) allows a few bits of drift of the course of a frame at each
station.


> > sender, and rule out any sort of broadcast based shared media
> > environment that doesn't provide for a continuous clock
> > distribution (you'd have to keep *all* stations exactly
> 
> When you leave out TR and FDDI, you're right. Of course, the line
> switched disciplines mentioned above don't cover broadcast multiple
> access networks.


I should have been clearer.  I do not consider TR and FDDI to be
broadcast based shared media environments at the PHY level (which is
what we're discussing), rather a collection of point-to-point links
arranged in a circle.


> 
> It's still somewhat confusing to me, but eventually it's a matter
> of definition. 
> 
> Nevertheless: When you definie synchronous with respect to a frame
> and the receiver, how would an asynchronous network work then?
> Would this be impossible?


There's no real problem.  Just do something to delimit the "frames"
(eg. define an STX and ETX character and pick some medium that allows
multi-drop operation (eg. RS-422).  Standard async protocol won't
allow you to do collision detection, but so long as your utilization
isn't too high, that's not much of a problem (the number of required
retransmissions would be modest).  Rather more commonly you'd have a
master station that send polls to the slave stations to keep
transmissions orderly (which can be considered a variation of a token
passing bus).  You can also trivially construct a ring with ordinary
async serial ports and some oddly wired RS-232 cables.

You just need to do something to mark the boundaries of your frames.

I was also discussing the definition of async vs. sync with a friend
last night, and perhaps a better, although functionally equivalent
definition, is a synchronous protocol is where a clock signal is
transmitted with the data, which could either be in-band (eg.
Manchester encoding) or out-of-band (eg. on a separate wire).  This
presents a slight difficulty with bisync where the reliable provision
of clock signals required the participation of protocol levels well
above the PHY.  Since there was no bit stuffing or anything, you had
to avoid sending certain characters that lacked transitions (eg. 0x55,
0xaa) over certain types of links.  You'd have to escape those bytes
in the presentation or application layer (keeping in mind that this
predates the OSI network model by a couple of decades).  You could
probably call that a form of "byte stuffing."

"Steve Horsley" <steve.horsley1@virgin.NO_SPAM.net> wrote in message
news:pan.2003.08.06.19.36.15.471612@virgin.NO_SPAM.net...
> On Wed, 06 Aug 2003 07:21:16 -0400, James Carlson wrote:
>
> >
> > Typically, no, though I suppose it's possible.  A "framing error"
> > means that you've violated the protocol used to describe the
> > boundaries between packets (or other data units).  The exact
> > definition of such an error (and how it would be detected) depends on
> > the link layer in use, and you haven't mentioned any of interest.
>
> For example, a Framing error in Ethernet is a packet which is not a
> multiple of 8 bits in length - not a whole number of octets. Ethernet
> controllers are not built to be able to send these, and they are detected
> by the controller chip before even considering the checksum - the checksum
> cannot even be reliably located in such packets.

Except that the standard allows such "dribble bits."

-- glen