View source for The GEC4 Demo (Part 2)

[[Category:The SPP]]
[[Category:GEC4]]
<table align=right border=1 cellpadding=3 cellspacing=0 >
  <tr>
    <th>Phase</th>
    <th>QID</th>
    <th>Threshold <br> (#pkts)</th>
    <th>Bandwidth <br> (Mb/s)</th>
    <th>Description</th>
    </tr>
  <tr>
    <td align=center>1</td>
    <td align=right>9</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td>Base Case</td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>10</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td> <br> </td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>11</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td> <br> </td>
    </tr>

  <tr>
    <td align=center>2</td>
    <td align=right>9</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td>Change Thresholds</td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>10</td>
    <td align=center>2000</td>
    <td align=center>100</td>
    <td> <br> </td>
  <tr>
    <td> <br> </td>
    <td align=right>11</td>
    <td align=center>3000</td>
    <td align=center>100</td>
    <td> <br> </td>
    </tr>

  <tr>
    <td align=center>3</td>
    <td align=right>9</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td>Base Case</td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>10</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td> <br> </td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>11</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td> <br> </td>
    </tr>

  <tr>
    <td align=center>4</td>
    <td align=right>9</td>
    <td align=center>1000</td>
    <td align=center>100</td>
    <td>Change Quantums</td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>10</td>
    <td align=center>1000</td>
    <td align=center>50</td>
    <td> <br> </td>
    </tr>
  <tr>
    <td> <br> </td>
    <td align=right>11</td>
    <td align=center>1000</td>
    <td align=center>25</td>
    <td> <br> </td>
    </tr>
</table>

This part of the demo shows the effects of changing the threshold and bandwidth
parameters of packet queues at the bottleneck.
The ''threshold'' specifies the queue capacity, and the ''bandwidth'' specifies the
guaranteed bandwidth of the queue.
Specifically, the threshold specifies the ''number of packets'' that can be queued.
Packets arriving to a full queue are discarded.
The bandwidth parameter specifies the guaranteed bandwidth in ''kilobits per sec (Kb/s)''.

The conduct of the demo involves running the traffic scripts in Part 1 for a longer period of
time while another script ''changeQparams.sh'' continuously adjusts R1's queue parameters.
The procedure is:

* Start the three receivers on onl038, onl039 and onl040 by running the script ''start_recvs.sh'' on onl035.
* Start the three traffic generators on onl035, onl036 and onl037 by running the script ''start_xmits.sh 1200 120000 200'' on onl035.
* Run the ''changeQparams.sh'' script on R1's GPE.

The arguments to the ''start_xmits.sh'' script will send 1200-byte UDP packets at a rate
of 120,000 Kb/s (i.e., 120 Mb/s) for 200 seconds.
The 200 seconds allows you to start the ''changeQparams.sh'' script and observe the effect of changing
the queue parameters back and forth.
The changes result in a continuous repetition of the four phases (shown right).

Since each phase lasts 10 seconds, the monitoring charts show changes every 10 seconds with
the base case reappearing every 20 seconds; i.e., we see the changes for the
sequence (base case, threshold changes, base case, quantum changes) repeated every 40 seconds.
In the base case, all three queues (QID 9-11) have a threshold of 1,000 packets and a bandwidth
of 100 Mb/s.
The four monitoring charts are shown right.  Each chart on the right is equivalent to the
chart to its immediate left.
For example, the two charts on top show bandwidth but the Y-axis on the left chart is in
bytes/sec while the one on the right is in packets/sec.
Similarly, the bottom two charts are queue length charts with the one on the left showing
bytes and the one on the right showing packets.
There are two other charts that show
equivalent results but where the units of the output rate are bytes/sec instead of packets/sec
and the queue length units are in bytes instead of packets.
For example,
since the packets have a payload of 1,200 bytes, we expect the base case to show
maximum queue lengths of 1,200,000 bytes or 1,000 packets for each of the three queues.

<br clear=all>
<ul>
</ul>

[[ Image:GEC_4_Charts_Queue_Parameter_Changes.png | center | Changing Queue Parameters ]]


In phase 2, the thresholds are changed so that the capacity of queue 9 (H1 to H4) is still
1,000 packets.
But the capacity of queue 10 (H2 to H5) has been doubled to 2,000 packets, and the capacity
of queue 11 (H3 to H6) has been tripled to 3,000 packets.
The queue length chart shows that these changes did occur.

In phase 3, the queue thresholds and bandwidths have been reset back to the base case.

But in phase 4, the queue bandwidths are changed so that the guaranteed bandwidth
parameters are now 100 Mb/s, 50 Mb/s and 25 Mb/s.
These bandwidths should be viewed as parameters of a ''max-min fair share'' allocation;
i.e., bandwidth should be allocated in proportion to their ratios 4:2:1 when possible with
excess bandwidth redistributed to those with unmet demand.
If we ignore the traffic demands (sending rates), the H1 traffic should get about
171 Mb/s (= 300 Mbps x 4/7), H2 should get about 85.5 Mb/s, and H3 should get about 42.8 Mb/s.
But since each source is sending at 120 Mb/s, H1 would have an excess of 51 Mbps over the 120 Mb/s
it needs.
This excess is then divided according to the ratio 2:1 between the other two flows
so that the H2 traffic will get 120 Mb/s and the H3 traffic will get 60 Mb/s.
Expressing the allocation in MB/s (megabytes per second), we would expect the allocation
to be 15 MB/s, 15 MB/s and 7.5 MB/s.

But the bandwidth chart shows the traffic rates out of R1 to be about 16 MB/s, 14.3 MB/s and 7.2 MB/s.
The small discrepancies are due to the 78 non-payload bytes (IP header (20 bytes), UDP header (8 bytes),
IP/UDP encapsulation (28 bytes) and VLAN-enabled ethernet frame (22 bytes)) that should be
included in bandwidth calculations.
Detailed calculations that account for this 6.5% overhead will show that H1 traffic at
the ethernet level will actually be 127.8 Mb/s instead of 120 Mb/s.
That means that H2 and H3 traffic will get a little less bandwidth than first estimated but
their bandwdiths will still be in the ratio 2:1.