Gary,
Good information to share. I hope the rest of the thread can
bennifit as I have in our exchanges.<G>
Oh... I'm sure this was a typo..but for clarification...
Not at all....let me explain.
ATM is Connection oriented...Not connection-less.
Not neccessariliy. Here are the specific levels of service for
well know technologies today:
----------------------------------------------
network arch. Service protocols
Internet connection-oriented TCP
connectionless UDP
----------------------------------------------
OSI connection-oriented TP0, TP1, TP2, TP3, TP4
connectionless CLTP
----------------------------------------------
ATM circuit-like AAL1 connection-oriented AAL3/4, AAL5, assured
connectionless AAL3/4, AAL4, unassured
For furthur study:
gaia.cs.umass.edu
IP is connection-less. That is, it does not need a connection (VC)
to be pre-determined.
Actually I said:
>In otherwords unless you are not using a connection-oriented
>application (all TCP applications such as TCP, most httml, ftp)
>you are SOL. This includes most IP routing updates (UDP and ICMP
> based), SNMP, TFTP, some httml.
TCP is indeed connection-oriented, in the sense of the true
definition: That a connection is established, and a socket bound
(as in a telnet connection), where a two-way communication can
take place, but in order for it to live each sent packet
must be acknowledged by an acknowledgement packet to the sender,
thus establishing the reliable connection (or session)
that could not be possible with a connection-less UDP session.
For furthor reading this is most helpful:
foner.www.media.mit.edu
You are confusing Virtual Connetions, be it PVC or SVC,
with the concept of reliable and unreliable traffice flow,
otherwise known as connection-oriented or connectionless
session binding. The status of how a connection is made from
point A to point B is of no meaning when it comes the reliability
of the VC when data is passed. This is defined in QoS, or relative
to the applications via connection/connnectionless session definition.
These technologies came about because end points had error
correction built into them.
I understand fully. Please read my explanation of X.25
(connection oriented) and the evolution of Frame Relay
(connectionless) in my previous post.
So, my response about traffic management didn't specifically
address your first issue. But, cell loss usually happens because
of bad traffic management (buffers getting filled), not because
of packet loss, bad CRC, etc.. This just doesn't happen often
enough anymore (in the states) where the overhead is worth
worrying about...
I agree with your view on the statistics of this happening, but
I must say that I am suprised you take the stance of that it
does not happen enough to not worry about. The selection of
reliable network protocols that can deal with CRC errors (I have seen
many a DSU/CSU go bust with only CRC erros as a symtom). I find
it my responsibility to take this into account.
Comparing the overhead of error correcting each frame versus
the overhead of re-sending a lost frame every so often weighed
in favor of not error correcting.
I agree in most cases that this is true. At least take the load
off the network, and distribute it to the hosts, which is what is
done when reliable applications are utilized.
This decision was made over 10 years ago. Are you suggesting
we go back to this technology and error correct and check each
packet as it winds its way through the bacbone?
No, that is not what I said. It is something that every responsible
network archetect must be aware of, and must take into account.
For example tell clients to utilize ftp (TCP, connection-oriented,
based) vs tftp (UTP, connectionless based) applications.
Can you imagine a voice call going through the internet given
the response times we all experience?
Voice can tollerate some loss. Data can tolerate no loss.
This comes back to the question of QoS and how it can be implemented
without utilizing QoS/ATM.
Regards, Paul |
