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

Dennis J. Streveler (
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
>Just a thought...
>Miami, FL


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,

Local Hostname:
Local Address:
Local Address:

TraceRoute (
58 bytes from time=1880 ms
1 5 5
2 37 32 SanFrancisco01-Max1.POP.InterNex.Net
3 41 4 SanFrancisco01-rtr.POP.InterNex.Net
4 47 6
5 47 0 region-1A-rtr-fddi.InterNex.Net
6 240 193
7 48 -192 Fddi0-0.San-Jose6.CA.Alter.Net
8 49 1 Hssi1-0.Palo-Alto2.CA.ALTER.NET
9 249 200 Fddi0-0.Palo-Alto1.CA.Alter.Net
10 115 -134 Hssi2-0.CR2.SCL1.Alter.Net
11 141 26 107.Hssi4-0.CR2.EWR1.Alter.Net
12 122 -19 Hssi1-0.CR1.PSK1.Alter.Net
13 117 -5
14 121 4
15 126 5
16 239 113
17 315 76
18 252 -63
19 256 4
20 369 113 dante.WiN-IP.DFN.DE
21 318 -51 DFN-gw.Radio-MSU.NET
22 328 10
23 2129 1801
24 593 -1536
25 620 27
26 670 50
27 * * timed out
28 807 137
29 1011 204
host reached

Dennis J. Streveler, Ph.D., | Internet:
Systems Consultant | CIS: 71036,1645
| web:
-Future Technologies in Medicine / | CUSeeMe:
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.