CHANNEL SELECTION
5.1 Criteria For Channel Selection:
The server must choose between TCP and UDP based on the response size and network conditions. When the network is not congested and packet loss is low, then the best strategy for the server would be to maintain no state for sent responses. This strategy optimizes for the common case of no packet loss, at the expense of having to re-generate the response after a loss does occur.
However, when the network is congested, this strategy is extremely poor. Not only do the UDP responses have to be regenerated and re-transmitted often, but even TCP responses may arrive at clients so slowly that clients send duplicate requests for them. The result is that the server sends many duplicate responses, which will further increase the network congestion. The same situation may occur with compute-intensive responses, which may take a long time to reach the client.
To address this issue, DHTTP server must maintain some information, which will inform the server about current network condition. For this server maintains two counters namely a “fresh requests counter” and “resent requests counter”.
Fresh Request Counter:
This counter is incremented any time the server sends a response by UDP to a request with unset resent flag,
Resent Request Counter:
It counts the number of resent requests received by the server.
Server then chooses a channel using parameters threshold parameter (L) and a size threshold parameter(s).
All the responses exceeding the size threshold are send over UDP. Also the responses to the resend requests are also sent over TCP.
The choice for the remaining responses depends on the threshold parameter L and ratio of resent request counter to fresh request counter. If this ratio is below L, these responses use UDP. The ratio above L indicates high packet loss and would suggest sending all responses by TCP. However, the server must still send a small number of responses over UDP to monitor the loss rate, since the TCP layer masks losses in the TCP channel. Therefore, server arbitrarily to send (1-L) fraction (or 99%) of small responses over TCP and the remaining small responses over UDP in the high loss condition.
5.2 Handling resent TCP requests:
There is still a race condition, where a client may time out and resend a request before the TCP response to this request arrives. To address this race condition, our server maintains a circular buffer of global request IDs that have been responded to by TCP. Global request ID is a combination of the client IP address and request ID from a request.
The buffer has room for 10000 global request IDs. When a resent request arrives, the master process ignores it if it is found in the buffer, since the response was already sent by TCP that has reliable delivery.
A potential limitation of the above algorithm is that the server maintains aggregate packet loss statistics. While the aggregate statistics reflect well the congestion of the server link to the Internet, congestion of network paths to individual clients may vary. Thus, enough clients with congested links can make the server use TCP even for clients with non-congested links. Conversely, the server may use UDP for an occasional congested client if its connection to the rest of the clients is uncongested. If a UDP response to the congested client is lost, the
client will resend its request with the resent flag set, forcing the server to use TCP for this interaction.
5.3 Choosing Size Threshold value:
Choosing a size threshold presents another interesting tradeoff as far the performance is considered. A large value will reduce the number of TCP connections by sending more responses over UDP; however, if it exceeds one MTU (1460 bytes), some responses in the current version of DHTTP will be fragmented. Fragmentation degrades router performance and entails resending the entire response upon a loss of any fragment. Thus, in a high loss environment such as Internet, s should be limited to one MTU.
Next: INTERCEPTION CACHE
Previous : Introduction to Dual Transport HTTP
0 comments:
Post a Comment
Thanks for your Valuable comment