Re: where'd my typed text go???... a sample TraceRoute

Dennis J. Streveler (strev@mobius.net)
Sat, 13 Jul 1996 11:47:42 -0700

At 04:36 PM 7/12/96 -0400, Ron Elkayam wrote:
>On Fri, 12 Jul 1996, Dennis J. Streveler wrote:
>
>> There is only one way to assure the accountability for your message which
>> you are assuming. That is, at the beginning of each message which you send,
>> send a "serial number" along with it. For example, "1 Hi iceman, are you
>> there?" If later he sees "2 It's great weather here", he may realize he has
>> "missed" your message #1, and ask you to repeat it.
>
>That's a cute way to do it. I like that.
>
>> Is this a kludgey, silly, laborious way to get around this problem? Yes,
>> most definitely. If anybody has a better suggestion, I'm all ears.
>
>I'm not really sure where the problem is... Why can't CU-SeeMe do the
>serialization and verification and automatically resend lost text packets?
>I mean, nobody cares about a part of a video frame being lost (and the
>packet authentication process will be a massive overhead which will
>severely hamper image quality anyways), but for text messages, I really
>think a built-in mechanism should be used to guarrantee all packets
>are received. Since text is cheap compared to video, why not send 10
>copies of the packet and have the receiver discard the duplicates it
>receives?
>
>Just a thought...
>
>Ron
>Miami, FL

Ron,

Your suggestion of redundant broadcast of chat packets makes some sense,
although, in times of network conjestion, there is still a chance, although
a diminishing chance of even the tenth packet not getting thru (using the
UDP protocol).

As for a "builtin mechanism" to assure packet delivery, well, that is the
very essence of what the TCP/IP protocol is. If you use it however, it means
you would have long delays. A "message" is composed of many packets (in the
worst case) and thus the receivor will wait until all packets arrive and are
reassembled before they are sent to the client (your computer). Thus, the
delays would be very long for "real time" applications like voice.

We must remember that the Internet was not really designed to work in "real
time", as was, say, the telephone network itself. Whether more "interactive"
protocols will be added at some point in the future to support all these new
"real time" applications remains to be seen. It would mean that the routing
tables would also have to be better designed so that packets could be very
efficiently routed from origin to destination. Now they can be allowed to
meander seemingly forever.

I'll demonstrate what I mean. Below I have pasted in a "TraceRoute" which is
an Internet trace of the travel of a packet between my computer in San
Francisco and the computer with which I communicate (and do CUSeeMe) in
Moscow. You'll see that (today, Sunday) it takes a route which involves
being "handed off" 29 times. Why it takes ten times just to get it out of
the bay area and on to the East Coast of the US! From New York it hops
across the Atlantic to Hamburg then to Moscow where it gets rerouted many
times before it finally reaches its destination at AnimaTek Moscow. This
takes 1.880 seconds (1880 ms) which is not bad. This is a Sunday. On a
typical busy period, it takes about 4 seconds and can involve as many as 40
or so "hops".

Also note, at line 27, one "time out" occurs. Thus here there could have
been a "lost packet"!

Hope you find this interesting,
Dennis

----------------
Local Hostname: SanFrancisco01.pop.internex.net.ws1.streveler.xo.com
Local Address: 140.174.242.149
Local Address: 205.158.225.154

TraceRoute animatek.itep.ru (193.124.225.66)
58 bytes from 193.124.225.66: time=1880 ms
1 5 5 205.158.225.153
2 37 32 205.158.3.52 SanFrancisco01-Max1.POP.InterNex.Net
3 41 4 205.158.3.49 SanFrancisco01-rtr.POP.InterNex.Net
4 47 6 205.158.2.37
5 47 0 205.158.0.4 region-1A-rtr-fddi.InterNex.Net
6 240 193 198.32.136.42 san-jose3.ca.alter.net
7 48 -192 137.39.27.12 Fddi0-0.San-Jose6.CA.Alter.Net
8 49 1 137.39.101.162 Hssi1-0.Palo-Alto2.CA.ALTER.NET
9 249 200 137.39.47.1 Fddi0-0.Palo-Alto1.CA.Alter.Net
10 115 -134 137.39.100.50 Hssi2-0.CR2.SCL1.Alter.Net
11 141 26 137.39.58.9 107.Hssi4-0.CR2.EWR1.Alter.Net
12 122 -19 137.39.100.29 Hssi1-0.CR1.PSK1.Alter.Net
13 117 -5 192.157.69.13 f0-0.enss219.t3.ans.net
14 121 4 140.223.33.129 h2-0.t32-0.New-York.t3.ans.net
15 126 5 204.149.4.7 New-York2.dante.net
16 239 113 194.72.26.1 NL-s0.dante.bt.net
17 315 76 194.72.24.1 NL-f0-0.eurocore.bt.net
18 252 -63 194.72.24.213 DE-s1-2.eurocore.bt.net
19 256 4 194.72.24.194 DE-f0.dante.bt.net
20 369 113 188.1.56.9 dante.WiN-IP.DFN.DE
21 318 -51 188.1.56.6 DFN-gw.Radio-MSU.NET
22 328 10 194.67.82.18 DESY-P.Hamburg.DE.Radio-MSU.net
23 2129 1801 194.67.80.9 NPI-P.Moscow.RU.Radio-MSU.net
24 593 -1536 194.67.80.17 NPI-MSU.Moscow.RU.Radio-MSU.net
25 620 27 194.67.80.6 MSU-Tower-2.Moscow.RU.Radio-MSU.net
26 670 50 194.67.80.66 ITEP.Moscow.RU.Radio-MSU.net
27 * * timed out
28 807 137 192.148.166.250 animatek.itep.ru
29 1011 204 193.124.225.66 animatek.itep.ru
host reached

--------------------------------------+------------------------------
Dennis J. Streveler, Ph.D., | Internet: strev@mobius.net
Systems Consultant | CIS: 71036,1645
| web: www.usr.mobius.net/strev
-Future Technologies in Medicine / | CUSeeMe: ws1.streveler.xo.com
Telemedicine +------------------------------
-International Software Development | 415 239-1441
Methodologies | 415 469-9476 fax
+------------------------------
-Human-Computer Interface Design | 127 Lake Merced Hill
for Casual Users | San Francisco CA 94132 USA
--------------------------------------+------------------------------
My job? To send the appropriate electrons hurtling around the globe.