[Cisco] Local vs Remote vs Late Collisions -- calling all experts

Thu Apr 28 15:36:31 EST 2005

Dear Kevork

Having read both Emails, I was aware of the implications of your follow-up question.  My 2 cents-worth:

1.  Any 2 stations seperated by repeaters are struggling away to send data, seperated by time (latency).  So if one end detects no traffic, it can start sending.

Unfortunately, due to the time delay, the station at the other end may not detect this new traffic for quite some time, and if it interprets this silent time as a legitimate time to send data, then the circumstances for a collision have been setup.

If TOO MANY repeaters and/or ILLEGAL LINE LENGTHS in summation cause the  round-trip delay (and consequently slot-time) to be beyond maximum allowable, then for some (remote collision) frames, particularly short/minimum-length ones the 'Jam' signal will arrive back beyond the end of the frame.

This is the major evil in this sort of network design (not uncommonly done in networks that 'cheated a little').  Since the first station sent the whole frame without sensing a 'Jam' during sending, it must assume (and record) that the frame was successfully sent, and therefore will not be triggered to re-send the scrambled frame later.  (This is anathema for a 'reliable' media). 

Of course the remote station will have sensed the collision as a local one (caused by the repeater), and will automatically re-send, no harm done there!  It is the first (nearside) station that will be experiencing severe problems in RELIABLE data transfer.

In a large practical network that I have seen (not too far from here), now managed by one of my old Networking students, it was common enough.  Sends and collisions between people attached to intermediate repeaters and the tips of the network were handled OK automatically.

However collisions between stations at far tips of the network were a problem.  On the assumption that this occurred infrequently, and that if it did, that the re-sent data was unlikely to align perfectly with the same stations the second time, the network ran happily for many years (though a little slowly and unreliably at the tips).

Of course, at the near end, re-sends relying on being re-triggered by TCP timeouts, or higher protocol levels (for UDP, etc.) were very slow to perform compared with 'reliable delivery at the Access Layer' (1/2).  Ie. our part of the network ran like a dog (while others nearer to the core ran relatively well, and swore that we were just 'wingers').

Eventual re-wiring and Switched networking (now common) solved the problem, and to this extent this problem is now mostly only of historical significance.  However 'Late Collisions' were the bane of networks, at that time unfixable without great expense, and hence a favourite of syllabus-writers.

I hope this settles the rest of your concerns, and that you are clear about the obligations of Repeaters in terms of propagating collision-signals (such as 'Jams').

Regards    - Rob B.

Rob Bernard
E&E Dept. (TAFE-Hawthorn)
Swinburne Uni (Mail #H47)
P.O. Box 218
Hawthorn, Vic.  3122
Ph.  61 (03) 9214 8464

>>> Kroset at novell1.fhc.vic.edu.au 04/28/05 10:34 am >>>
Hi Straube,

  Actually I would have called yours a $2K worth ( a great deal higher than 2 cents ! ) 

I am happy with the clarification. I guess what threw me is the statements in Slide 6.2.6 about remote collisions :
" A repeater will not forward an over-voltage state, and cannot cause a station to have both the TX and RX pairs active at the same time. The station would have to be transmitting to have both pairs active, and that would constitute a local collision. "

   That is, if station A is still transmitting for a remote collision to occur, then how can it recognise something is coming back be it a jamming signal or a frame fragment , if it cannot have both Rx and Tx active ? How can it NOT have a signal come back on Rx while Tx is active if it is to detect the problem while it is transmitting ?

   Can you see where I am coming from ?

With thanks
Kevork

>>> J.Straube at bhtafe.edu.au 04/27/05 04:29pm >>>
Hi Kevork,

Here you have my 2 cents worth of thought.

"The question is :  Is the sending machine still transmitting for a
remote collision to occur? "

Yes, the 2 machines are still sending (within the first 64 octects)

"If not, then is it not a Late collision?" 

No, because it will be detected within the 64 octets. 

"Also, how can the sending machine know there was a remote collision ?
Does it get fragments of the collision back across the repeater with the
FCS not matching ?" 

Two scenarios: 
1)Let's assume machine A and machine B are separated by a repeater.

A ------ R ----xxx-- B

In here we see that the remote collision for A (represented by xxx) is
also a local collision for B. When B detects the collision it sends a
Jamming signal (which is repeated) that can be detected by A which will
in turn also send the Jamming signal.

2) Let's now assume 3 repeaters in the logical segment (worst case
scenario).

A ------ R ------ R ---xxx--- R ------ B

In this case the collision is remote to both sources. A or B can only
detect the collision by checking the FCS (which in any case will be
incorrect) of the received frame. In this case you could say that the
collision can also be seen as 'Late' collision due to the fact that the
FCS is at the end of the frame.

"and does that happen before the 64 bytes slot time is exhausted ?"

Please refer to the previous answer.

I hope it helps to clarify a bit.

Regards,
Straube

-----Original Message-----
From: Kevork Krozian [mailto:Kroset at novell1.fhc.vic.edu.au] 
Sent: Wednesday, 27 April 2005 2:07 PM
To: cisco at edulists.com.au 
Subject: [Cisco] Local vs Remote vs Late Collisions -- calling all
experts

  Hi Folks,

        I am wondering if anyone can help me here. 
I am reading contradictory information about Collision types on
Ethernet.

 Local collisions look OK.  These happen during the first 64 bytes of
transmission ( also known as slot time ). There is an amplitude increase
on the local segment, and both Rx and Tx wires become active hence the
collision. The sending machine has to resend. No problems here.

 Remote Collsions . Happen on the other side of repeaters, which is does
not send back the amplitude increase or send back a signal on the Rx
wire. However, these must happen while the sending machine is still
transmitting the first 64 bytes which means it is still transmitting
when a remote collision occurs. See Slide 6.2.6 Semester 1. 
 The question is :  Is the sending machine still transmitting for a
remote collision to occur? If not, then is it not a Late collision ?
Also, how can the sending machine know there was a remote collision ?
Does it get fragments of the collision back across the repeater with the
FCS not matching ? and does that happen before the 64 bytes slot time is
exhausted ?

  Late Collisions :  These happen after the slot time is exhausted and
the sending machine does not know there was a collision. The higher
layers handle the error.

   I am happy to hear any and all suggestions

With thanks

Kevork Krozian
IT Manager , Forest Hill College
Mailing List(s) Creator and Administrator
http://www.edulists.com.au 
k.krozian at fhc.vic.edu.au 
Mobile: 0419 356 034

_______________________________________________
cisco mailing list
cisco at edulists.com.au 
http://www.edulists.com.au/mailman/listinfo/cisco 

Confidentiality and Privacy Statement

This message is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and destroy the original message. 
Box Hill Institute of TAFE is committed to protecting your privacy and the confidentiality and security of personal information provided by you to us. For further information visit www.bhtafe.edu.au or email privacy at bhtafe.edu.au.

_______________________________________________
cisco mailing list
cisco at edulists.com.au 
http://www.edulists.com.au/mailman/listinfo/cisco 

_______________________________________________
cisco mailing list
cisco at edulists.com.au 
http://www.edulists.com.au/mailman/listinfo/cisco
Swinburne University of Technology
CRICOS Provider Code: 00111D

NOTICE
This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment.