Subject: Strange packet loss on STS-78

From: Stephen Casner <[email-masked]>
Date: Sat, 22 Jun 1996 02:16:50 -0700 (PDT)

Something strange is going on with the NASA shuttle video.  mtrace
shows zero packet loss between the source and my destination, yet the
RTP stats show almost exactly one packet lost for each video frame.
Snooping on the packets shows that most video frames are two packets
long.  The first (long) packet appears to be lost, and the last
(short) packet (with the RTP M bit set) is arriving.  On one frame
that was three packets long, the first was missing but the last two
were received.  I wonder if there is some packet-length-dependent
problem at or near the source.
							-- Steve
 
  Source        Response Dest    Packet Statistics For     Only For Traffic
128.102.84.134  224.0.1.32       All Multicast Traffic     From 128.102.84.134
     |       __/  rtt   42 ms    Lost/Sent = Pct  Rate       To 224.2.230.64
     v      /     hop  121 s     ---------------------     --------------------
128.102.84.150  arcbone.arc.nasa.gov 
     |     ^      ttl   32        0/78   =  0%   7 pps     0/77   =  0%   7 pps
     v     |      hop -120 s      0/6477 =  0%   7 pps     0/6395 =  0%   7 pps
192.203.230.242 mbone2.nsi.nasa.gov 
     |     ^      ttl   33        0/118  =  0%  11 pps     0/77   =  0%   7 pps
     v     |      hop -300 ms     0/9856 =  0%  12 pps     0/6395 =  0%   7 pps
192.203.230.241 mbone.nsi.nasa.gov 
     |     ^      ttl   64        0/149  =  0%  14 pps     0/77   =  0%   7 pps
     v     |      hop  -19 ms     0/11895=  0%  14 pps     0/6395 =  0%   7 pps
192.42.110.249  paloalto-mbone1.bbnplanet.net 
     |     ^      ttl   65        0/702  =  0%  70 pps     0/77   =  0%   7 pps
     v     |      hop  114 s     -1/56252=  0%  68 pps     0/6395 =  0%   7 pps
131.119.244.11  utumno.barrnet.net 
     |     ^      ttl   66        0/410  =  0%  41 pps     0/77   =  0%   7 pps
     v     |      hop -114 s      0/33412=  0%  40 pps     0/6395 =  0%   7 pps
204.162.119.8   hydra.precept.com 
     |     ^      ttl   67       -1/410  =  0%  41 pps     0/77   =  0%   7 pps
     v     |      hop   14 ms  -340/33410=  0%  40 pps     0/6395 =  0%   7 pps
204.162.116.8   little-bear.precept.com 
     |      \__   ttl   68          411         41 pps       77           7 pps
     v         \  hop  -27 ms       33738       41 pps       6395         7 pps
204.162.116.21  204.162.116.8
  Receiver      Query Source

---

From: Bill Fenner <[email-masked]>
Date: Sat, 22 Jun 1996 12:06:05 PDT

In message <[email-masked]> yo
u write:
>I wonder if there is some packet-length-dependent

I suspect it's on the source host or in the source application; the
lost RTP sequence number space does not consume IP ID# space, so I'd
say the problem is definitely on the source machine.

This is one of the symptoms of reception of ICMP error messages in
response to multicast packets.  I couldn't trigger an ICMP error
message in response to any of my own packets but perhaps the NASA
people could monitor for stray ICMP errors destined to the traffic
source.  Vic has a workaround for this problem, but it can still
be overwhelmed by lots of traffic, which may be what's happening.

Here's a snip of the tcpdump output upon which I'm basing this observation:

11:51:39.854436 shuttle-bone.arc.nasa.gov.1289 > 224.2.230.64.54166: udp/rtp 694 c31 + 31422 !opt (ttl 122, id 499)
11:51:39.970886 shuttle-bone.arc.nasa.gov.1289 > 224.2.230.64.54166: udp/rtp 524 c31 + 31424 !opt (ttl 122, id 500)
11:51:40.112788 shuttle-bone.arc.nasa.gov.1289 > 224.2.230.64.54166: udp/rtp 960 c31  31426 0x11d6 586400219 (ttl 122, id 501)
11:51:40.114690 shuttle-bone.arc.nasa.gov.1289 > 224.2.230.64.54166: udp/rtp 299 c31 + 31427 !opt (ttl 122, id 502)

Now admittedly, this tcpdump is interpreting these packets as RTPv1
packets, but the only thing we're interested in here is the RTP
sequence number, which is in the same place in RTPv2.

Note that between the first and second, and between the second and
third packet, the RTP sequence number increases by 2, but the IP ID
increases by one.  Barring a bizarre IP implementation, I'd say that
means that the missing RTP packets never made it far enough into the
IP stack to get given an ID number.

  Bill