<div>Hi All,</div>
<div> </div>
<div>First of all, let me express my gratitude for the elaborate and thoughtful replies from Ross, Xochitl and Morgan, and apologise in advance for the long text below, however - we are quite desparate...</div>
<div> </div>
<div>We've done some homework in order to answer the questions which have been previously asked, and here are the answers which might hopefully clear things up:</div>
<div> </div>
<div>We've compared two packet size settings, the default (1448) and a custom (1328 = 188*7 + 12) size. In both cases ethereal showed 43% packet loss (indicated by gaps in RTP sequence numbers).</div>
<div>During the test, we have constantly monitored our NAT box, and the bandwidth usage did not exceed 50% of the downstream capacity (and of course the upstream capacity too).</div>
<div>We have also examined the RTSP receiver report sent by the VLC player which revealed the following data:</div>
<div>a. Packets lost: 6361</div>
<div>b. Fraction lost: 48 / 256</div>
<div>c. Interarrival jitter: 301</div>
<div>I am not an expert enough to understand the interarrival jitter or fraction lost counters, however "packets lost" stand for itself.</div>
<div>We've also examined the TTL value of the packets which DID arrive, and it stood on 126 on ALL packets.</div>
<div>The RTP stream was sent over TCP, and we will later on try to eliminate the NAT from the equation and try testing with UDP transport.</div>
<div>I also think it's a good idea to describe the network topology utilized during the test to make things a bit more clear:</div>
<div> </div>
<div>Win2003 Server -> 1Gbit switch -> Internet -> ATM -> Checkpoint <a href="mailto:Safe@Office">Safe@Office</a> 500 7.0.33.x -> LAN</div>
<div>The internet connection from the checkpoint box is going over PPPoE through the ATM line.</div>
<div> </div>
<div>The ATM line contract is 4 Mbit downstream and 2 Mbit upstream (we have conducted the test with a transport stream encoded at approximately 2 Mbit/sec.), and the checkpoint box performs traffic shaping effectively limiting the incoming bandwidth at around
3.8 Mbit/sec.</div>
<div> </div>
<div>From past experience with multicast (although not 100% relevant in this case since we're using unicast streaming), PPPoE adds some excess overhead to the packets going out of the line, effectively reducing the MTU of the packets which can be sent out of the network, and also causes fragmentation of incoming packets on the IP level (since the incoming MTU is also reduced), and this is the reason we started experimenting with different packet sizes.
</div>
<div> </div>
<div>As you can see, there are quite a few devices and software along the way which could potentially affect the quality of service, yet again, from our extensive experience with Real Media and Windows Media (on the same network infrastructure) those potential infrastructure problems can be (and are) successfully dealt with in commercial software for the sake of the end-user experience. We are trying to do the same with Live555, with no positive results (and no apparent reason for failure) yet.
</div>
<div> </div>
<div>Any help, ideas and thoughts would be kindly appreciated...</div>
<div> </div>
<div>Many thanks,</div>
<div>Ilya</div>
<div> </div>
<div><span class="gmail_quote">On 4/26/07, <b class="gmail_sendername">Morgan Tørvolt</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:morgan.torvolt@gmail.com" target="_blank">morgan.torvolt@gmail.com
</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> Also, your email says you are using ATM (Asynchronous Transfer Mode?). I<br>> check this on wikipedia, and notice that the data must be divided into very
<br>> small cells for delivery. It seems like ATM is a protocol for<br>> time-sensitive data, like VoIP. RTP also is designed to meet special<br>> timing needs of the data. Could there be a problem combining these two
<br>> time-sensitive protocols? "If a circuit is exceeding its traffic contract,<br>> the network can either drop the cells or mark the Cell Loss Priority (CLP)<br>> bit (to identify a cell as discardable further down the line)." The RTP
<br>> delivery can be somewhat bursty, so maybe you need to check your ATM<br>> contract and make sure you have the correct one (VBR maybe?) one?<br><br>ATM is just a transport layer, as Ethernet, SDH and others. ATM is
<br>usually used in for example ADSL connections. That the packet size is<br>155 (or something like that) is not obvious, or even visible, to the<br>end hardware. It sees only an ordinary Ethernet link.<br>ATM is not very suited to do anything really. It is like a duck, it
<br>can swim, fly and make sound, but does neither extremely well. For<br>extremely time sensitive data one uses SDH, which even keeps the<br>original input clock through the links. For time insensitive data one<br>uses Ethernet. ATM is very good at prioritizing traffic though, and it
<br>could sound like the Ethernet packets are given a low priority,<br>possibly due to the fact that it is UDP. I have experienced this<br>before, and the configuration of a Ethernet card in one of the nodes<br>was to blame. It did not keep it's config due to hardware failure. In
<br>your case this should be configurable in the ATM nodes, or management<br>software.<br><br>As a "most likely" option, I would have to opt for bandwidth problem.<br>I have spent too many hours saying that it is not so on ATM networks
<br>before. Check that your VCs and VPs are set up correctly, and try<br>transmitting TCP and UDP data from other sources than live. VLC stream<br>output would be a good place to start I believe.<br><br>I agree with Ross here. You say it works well without the ATM, but not
<br>with it. The reason for the problems is then too obvious. As there are<br>literally thousands of users of this software, I do believe that the<br>way it handles the Ethernet part works according to standard (unless<br>
your OS or some configurations therein is to blame). One should not<br>make custom fixes to allow for broken hardware or configuration. In<br>this case "your network" seems like a good term, as most of the other
<br>networks seems to work just fine.<br><br>-Morgan-<br>_______________________________________________<br>live-devel mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:live-devel@lists.live555.com" target="_blank">
live-devel@lists.live555.com</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel
</a><br></blockquote></div><br>