ENFOQUE METODOLÓGICO

The backbone capacity consumed by the MbD approach depends on how often updates are sent across the backbone. At the expiration of every Update Interval, the top-level

manager estimates backbone utilization (using round-trip time from ping) and invokes an update if its utilization estimate is suitably low. Henceforth, we assume that setting the Polling Interval to 60 seconds (1 minute) and the Update Interval to 360 seconds (6 minutes) is a reasonable way to use this system. Therefore, a lightly utilized backbone will see a ping request/response exchange, an Update Request, and a small Update Response every 6 minutes. The Update Response will carry 6 polling rounds worth of information. A heavily utilized backbone will see a ping response/request exchange every 6 minutes, but it will see Update Requests and large Update Responses on a less frequent basis. The frequency of Update Request/Response exchanges depends on how often the top-level manager finds the backbone utilization low enough to justify an Update. That is, a low Update Interval/Update ratio would indicate a lightly loaded backbone, and a high Update Interval/Update ratio would indicate a heavily loaded backbone.

The ratio of Update Interval to Polling Interval was used to vary the frequency of Update messages. The overhead incurred by ping exchanges that do not invoke Updates was accounted for and added in by hand. For example, a heavily utilized backbone might justify an Update exchange only once for every 16 Update Intervals (96 minutes). This scenario could be simulated by setting the Update Interval to 96 minutes, while keeping the Polling interval set to 1 minute. The traffic captured from the backbone network would then include 1 ping request, 1 ping response, 1 Update Request, and 1 Update Response. The other 15 (imaginary) ping request/exchanges that failed to invoke an Update are not part of the capture, so they must be accounted for artificially. The technique just described is how the capacity tests for the MbD scheme were conducted, with one exception. To avoid unnecessarily long simulation times, the Update Interval and Polling Intervals were scaled down by a constant factor.

Table 7-2 shows the results for testing the MbD scheme without security services in place. These results provide perspective when compared to the results for testing with security in place. An examination of the medium-heavy (med-heavy) row in Table 7-2 will help clarify the meaning of each entry. This row contains statistics for the unsecured test where the modeled workload was med-heavy, and the ratio of Update Intervals to Updates equals 8. It represents the scenario where the backbone utilization is heavy enough to justify an Update only once for every 8 Update Intervals, on average. An unsecured ping exchange transmits 164 bytes, 84 bytes for the request and another 84 bytes for the response. Therefore, this scenario includes 8 ´ 164 = 1344 bytes of ping overhead. The unsecured Update Request was observed to be 36 bytes. The Update Response was larger than the 1500-byte Maximum Transfer Unit (MTU) for Ethernet, so the Update Response was fragmented into two packets. The first packet was observed to be 158 bytes in length, and the second was observed to be the maximum size for Ethernet, 1,500 bytes. The total number of bytes transferred under this scenario was, therefore, 1344 + 36 + 158 + 1500 = 3038 bytes.

Table 7-2. Backbone Capacity Consumed by the Unsecured MbD Scheme

Modeled

Workload Update Intervals to Updates Ratio Ping Overhead (bytes) Update Request (bytes) Update Response(s) (bytes) Total Sent (bytes) Light 1 168 36 436 640 Med-Light 2 336 36 612 984 Medium 4 672 36 938 1646 Med-Heavy 8 1344 36 158 1500 3038 Heavy 16 2688 36 108 1500 1500 5832

The same technique was used to measure capacity consumption for the MbD scheme with security services in place. A tunnel-mode, gateway-to-gateway security association using ESP with MD5 and 3-DES was established between east and west. Each scenario was then tested five times with the resultant mean statistics shown in Table 7-3.

Table 7-3. Backbone Capacity Consumed by the Secure MbD Scheme

Modeled

Workload Update Intervals to Updates Ratio Ping Overhead (bytes) Update Request (bytes) Update Response(s) (bytes) Total Sent (bytes) Light 1 272 88 512 872 Med-Light 2 544 88 685 1317 Medium 4 1088 88 1021 2197 Med-Heavy 8 2176 88 209 1488 136 4097 Heavy 16 4352 88 184 1488 136 1488 136 7872

Comparing the med-heavy scenario of Table 7-3 to the med-heavy scenario of Table 7-2 proves interesting. The size of a secured ping exchange was observed to be 272 bytes, 136 bytes for both the request and response. Therefore, the med-heavy scenario includes 8 ´ 272 = 2176 bytes of ping overhead. The secured Update Request was observed to be 88 bytes. Now, notice that the Update Response was inefficiently fragmented. An explanation for this inefficiency follows.

The mid-level manager on dusk produced the Update Response, which was too big for the Ethernet link layer, so the IP layer on Dusk fragmented the datagram into two datagrams. One datagram was small in size (roughly 130 bytes) and the other was exactly 1,500 bytes, the maximum size payload allowed by Ethernet. Both datagrams

were then sent to west, the default gateway for the 10.0.3.0 subnet. West received the datagrams and, knowing that they belong to a defined IPSec security association, secured them in preparation for transmitting to east. The additional packet overhead required to support security services increased the small packet’s size to 209 bytes and the large packet’s size to something greater than Ethernet’s 1500-byte MTU. Thus, the 1500-byte datagram was fragmented into one 136-byte datagram and one 1488-byte datagram. The end result was that three datagrams were sent over the backbone network, when two would have sufficed.

Experimenting with the Ethernet MTU setting on dusk showed that an MTU of 1,442 bytes was the maximum MTU that did not cause fragmentation by the IPSec gateway, west. That is, an MTU of 1,442 bytes left enough headroom (1500 – 1442 = 58 bytes) such that west could add IPSec overhead without exceeding the 1500-byte Ethernet MTU. Changing the MTU on west saved about 60 bytes of overhead for each double- fragmented packet. The savings realized might not be justified if reducing the MTU causes other problems. Since this research strives to be link layer independent, the MTU was returned to 1,500 bytes for all subsequent testing. However, the MTU issue just discussed certainly deserves attention.