Delta Encoding

In this situation, a delta refers to the difference between two files. On UNIX systems, the ``diff'' command can be used to generate the delta between two files. Using the changed file, and the delta, the original file can be regenerated again, and vice-versa.

For delta encoding on the web, the client initially requests a document and the complete document is downloaded. This will result in about a 55% benefit if using T/TCP and taking into account the mean size of a document. Once the client has the page, it can be cached and stored indeterminately. When the client requests the document the next time, the browser will already have the original document cached, so, using delta encoding, the browser would present the web server with the last date the cached document was modified. The server determines if the document has been updated since the cached copy was stored, and if so, a delta of the server side document is created. The delta, rather than the original document is transferred.

Of course, there are quite a few difficulties that need to be considered.

1. The client needs to retain a cached copy of the document. This is not so much a hassle with more modern browsers, as this is already done. In fact the HTTP protocol defines a command that can be used to request the last modified date from a document on a server. This is then compared to the cached document and a decision made whether to download the new file, or display the original.
2. From the server side, multiple versions of the document have to be cached to allow the server to create deltas. A decision has to be made of how many changed versions are allowed. Should the older versions be kept in the user side, or should a separate database of old versions be kept? A more detailed study of the impact of caching documents can be found in [8].
3. In the case where there have been a number of updates to the server side document since the client side was cached, it should be decided how many updates are allowed before the new document is sent - as opposed to sending a delta. The more changes applied to a document, the larger a delta is, hence, a loss in the savings by using delta encoding.
4. Again there is the question of the load placed on the server by generating a delta for each document requested, similar to the compression method.

Mogul et al. [11], investigated the effect that delta encoding has on the web. In their testing, they not only used delta encoding, they also compressed the delta generated to further reduce the amount of information transferred. They discovered that using the ``vdelta'' delta generator and compression they could achieve up to 83% savings in the transmission of data.

If this method was used with T/TCP, there could be as much as a further 66% savings in packets transferred, a total of 94% reduction in packet transfer.

It should be noted however that this is a best case scenario. In this situation, the document will already have been cached on both the server and the client side, and the client and server will previously have completed the three way handshake in order to facilitate the TAO tests.