[Community-allwww-cvs] www/2005/devdocs ABD-SOD-001-AutoBwDetection.html, 1.1, 1.2
rishimathew at helixcommunity.org rishimathew at helixcommunity.orgUpdate of /cvsroot/helix-client/www/2005/devdocs
In directory cvs:/tmp/cvs-serv5360
Modified Files:
ABD-SOD-001-AutoBwDetection.html
Log Message:
Minor modifications
Index: ABD-SOD-001-AutoBwDetection.html
===================================================================
RCS file: /cvsroot/helix-client/www/2005/devdocs/ABD-SOD-001-AutoBwDetection.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ABD-SOD-001-AutoBwDetection.html 23 Jul 2005 06:41:00 -0000 1.1
+++ ABD-SOD-001-AutoBwDetection.html 23 Jul 2005 07:19:03 -0000 1.2
@@ -58,13 +58,15 @@
quickly on the fly.
<p> </p>
<p>Several methods were considered: </p>
-<big>2.1 Designated Calibration Server</big> <br>
+<big style="font-weight: bold;">2.1 Designated Calibration Server</big><span
+ style="font-weight: bold;"> </span><br>
<br>
This is not optimal since it doesn't measure end-to-end avaiable
bandwidth and adds the burden to deployment and maintenance of
such calibration server to make sure it's running 24x7.
<p> </p>
-2.2 ICMP(Internet Control Message Protocol)<br>
+<big style="font-weight: bold;">2.2 ICMP(Internet Control Message
+Protocol)</big><br>
<br>
This technique measures the avaialble bandwidth by "pinging" the server
and deduces the value from the message echoed back from the server.
@@ -73,7 +75,7 @@
most
firewall administrators.
<p> </p>
-<big>2.3 Packet Pair</big><br>
+<big style="font-weight: bold;">2.3 Packet Pair</big><br>
<br>
Packet pair technique sends two identically sized packets back-to-back,
and measures the difference in the time between the packets when they
@@ -87,12 +89,14 @@
<li>New client <--> Old server(without ABD) </li>
</ul>
<p> </p>
-<p><big>3.1 For New client <--> New server(with ABD)</big> </p>
+<p style="font-weight: bold;"><big>3.1 For New client <--> New
+server(with ABD)</big> </p>
This solution requires both client and server support. We will
implement packet pair technique as part of the RTSP conversation to
measure
the avaialble bandwidth between the client and the server.<br>
-<p><big>3.1.1 New Probing Packet Type</big> <br>
+<p><big style="font-weight: bold;">3.1.1 New Probing Packet Type</big><span
+ style="font-weight: bold;"> </span><br>
</p>
<p>For RDT </p>
<pre class="code">class TNGBWProbingPacket<br>{ <br>public: <br>UINT8* pack(UINT8* buf, UINT32 &len);<br>UINT8* unpack(UINT8* buf, UINT32 len); <br>const UINT32 static_size() {return 10;}<br><br>UINT8 length_included_flag; <br>UINT8 dummy0;<br>UINT8 dummy1; <br>UINT8 dummy2; <br>UINT16 packet_type; <br>UINT16 length; <br>UINT8 seq_no; <br>UINT32 timestamp;<br>buffer data;<br>}; <br><br>packet_type = 0xff0b<br></pre>
@@ -102,14 +106,14 @@
ABD calibration to get bandwidth info for
RTP. </p>
<p> </p>
-<p><big>3.1.2. "Supported: ABD-1.0" Header</big><br>
+<p><big style="font-weight: bold;">3.1.2. "Supported: ABD-1.0" Header</big><br>
</p>
The client will add a new header "Supported: ABD-1.0" in its OPTIONS
request to determine whether server supports ABD or not. The server is
expected to echo back
with "Supported: ABD-1.0" in OPTIONS response if it supports ABD.
<p> </p>
-<p><big>3.1.3. UDP Port Poking</big><br>
+<p><big style="font-weight: bold;">3.1.3. UDP Port Poking</big><br>
</p>
If the client determines the server supports ABD, before it
sends the ABD request via GET_PARAM as described in 3.1.4, the client
@@ -117,13 +121,14 @@
will retrieve the server port and poke the firewall UDP port by
sending a dummy RTT UDP packets to the server.
<p> </p>
-<p><big>3.1.4 ABD Request </big><br>
+<p><big><span style="font-weight: bold;">3.1.4 ABD Request</span> </big><br>
</p>
The client initiates the ABD by sending GET_PARAM with
"AutoBWDetection: 1", the server is expected to responsd back and send
ABD packets afterwards.
<p> </p>
-<p><big>3.1.5 Header Extensions </big><br>
+<p><big><span style="font-weight: bold;">3.1.5 Header Extensions</span>
+</big><br>
</p>
In addition to the "AutoBWDetection: 1" header, the client can also
tell the server how many probing packets to be sent and the size of
@@ -132,7 +137,7 @@
"AutoBWDetectionPacketSize: x"(in bytes)<br>
<p>The client may customize these 2 values to fine-tune the ABD. </p>
<p> </p>
-<p><big>3.1.6 Expected Server Behavior</big><br>
+<p><big style="font-weight: bold;">3.1.6 Expected Server Behavior</big><br>
</p>
By default, the server is expected to send 2 back-to-back
probing data packets, 1200 bytes payload(excluding the header). For
@@ -142,14 +147,15 @@
from JPEG) in order to avoid some middle ware optimization and mimic to
the actual type of data packets.
<p> </p>
-<p><big>3.1.7 Potential Race Condition </big><br>
+<p><big style="font-weight: bold;">3.1.7 Potential Race Condition </big><br>
</p>
The client needs to take care of the potential race condition when
UDP probing packets arrive earlier than the SETUP response. The client
keeps tracking the probing packets, there will also be timeout logic to
bail out the ABD and proceed the remaining RTSP conversation.
<p> </p>
-<p><big>3.1.8 Bandwidth Notification to Server</big><br>
+<p><big style="font-weight: bold;">3.1.8 Bandwidth Notification to
+Server</big><br>
</p>
The client will inform the server about estimated available bandwidth
at the startup time by setting "Bandwidth=xxx" in PLAY request, this
@@ -160,7 +166,8 @@
<pre class="code">Here is the new RTSP chat with ABD:<br>C -----------> S OPTIONS request with<br> "Supported: ABD-1.0"<br> <----------- OPTIONS response with <br> "Supported: ABD-1.0" if the server supports ABD <br><br>C -----------> S DESCRIBE request <br> <----------- DESCRIBE response <br><br>C -----------> S SETUP requset(1st stream)<br> <----------- SETUP response <br><br>C -----------> S poke UDP port if UDP is preferred transport<br><br>C -----------> S GET_PARAM request with <br> "AutoBWDetection: 1"<br> "AutoBWDetectionPackets: 2"<br> "AutoBWDetectionPacketSize: 1200"<br> <----------- GET_PARAM response(status 200) with<br> "AutoBWDetection: 1"<br><br>C <----------- S [probing packets]<br><br><span
style="font-weight: bold;">Note</span>: For TCP, the server is<br>expected to start sending back-to-back packets on the same TCP<br>connection and for UDP, the back-to-back packets will be sent to<br>the same UDP port as specified in SETUP response. The client<br>calculates the available bandwidth. If the client ASM is enabled, then<br>the client will apply the result to its ASM logic to determine<br>which stream to subscribe to and what rate the packets need to be<br>delivered at.<br><br>C -----------> S SETUP request(2nd stream)<br> SET_PARAMS request <br> PLAY request, with "Bandwidth=xxx" <br><br>C <----------- S SETUP response(2nd stream)<br> SET_PARAMS response <br> PLAY response<br></pre>
<p> </p>
-<p><big>3.1.9 Interaction with HTTP Cloaking v2</big><br>
+<p><big style="font-weight: bold;">3.1.9 Interaction with HTTP Cloaking
+v2</big><br>
</p>
For HTTP Cloaking V2, the client will pipeline the
OPTIONS/DESCRIBE/GET_PARAM request, where OPTIONS request contains
@@ -185,7 +192,8 @@
technique to cache the avaialble bandwidth of each playback in
order to reduce the noise from new ABD result.
<p> </p>
-<p><big>3.2 For New client <--> Old server(without ABD)</big> </p>
+<p style="font-weight: bold;"><big>3.2 For New client <--> Old
+server(without ABD)</big> </p>
<p>Separate ABD Calibration server will be used, more details at: </p>
<ul>
<li><a href="ABD-SOD-002-ABDCalibration.html">ABD Calibration Server
@@ -243,22 +251,14 @@
technique to cache the avaialble bandwidth of each playback in
order to reduce the noise from new ABD result.
<p> </p>
-<p><big>3.2 For New client <--> Old server(without ABD)</big> </p>
-<p>Separate ABD Calibration server will be used, more details at: </p>
-<ul>
- <li><a href="ABD-SOD-002-ABDCalibration.html">ABD Calibration Server
-Proposal</a><br>
- </li>
-</ul>
-<p> </p>
-<big>3.2.1. TCP Bandwidth</big><br>
+<big style="font-weight: bold;">3.2.1. TCP Bandwidth</big><br>
<br>
The client ASM logic measures TCP bandwidth based on packet's latency
instead of back-to-back packets, this is probably because we don't have
control over the sending rate of TCP and TCP flow control can skew the
back-to-back result. Some investigation needs to be done to find out
more on this to decide whether we need separate mechansim for TCP.
-<p><big>3.2.2 Size of the packet </big><br>
+<p><big style="font-weight: bold;">3.2.2 Size of the packet </big><br>
</p>
The size needs to be close to the actual data packet size the server
sends at, depending on how many back-to-back packets required, we also