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

Fri Apr 29 18:41:38 EST 2005

... hearing someone else transmitting while it is still transmitting, in a Half-Duplex scenario.  

This is one role of the extended activity of the 'Jam' signal activated by the detection at the farside, and generated by the felon at that end, to assure that the other offender at this (nearside) end also reliably detects his part in the crime.  

(The 'Jam' signal appears to be a pattern designed to aggresssively collide with most common data formats in a single-wire/co-ax Ethernet medium, thus giving good signal intensities for that format.  Of course, any reverse-travelling data in Twisted Pair will trigger a collision detection in that medium when setup for Half-Duplex, so the aggressive pattern is not required - but doesn't hurt either!)

All this is great, PROVIDED the Jam arrives back to the nearside before the nearside has finished transmitting it's own frame (ie. is not a 'Late Collision').  

This is clearly not a risk for very long frames colliding either, as they will have heaps of time to register a crime before finishing, (though clearly standards do not seem to require operation in the time after a minimum-sized frame).

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
>>> kevork at edulists.com.au 04/28/05 6:47 PM >>>
Hi Rob,

   Great to hear the practical side of this theory in your local setting
and the evolution or revolution to switches to overcome the problems.
   Late collisions would truly have been the bane of networks, especially
when there was no solution to the problem at the time.

   To answer the original question, the nearside station detects the
remote collision on the other side of a repeater -- whilst it is still
transmitting -- by .....

  Best wishes
  Kevork

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