Among the many lessons that we have learned by working with adaptive applications, the difficulty of modifying existing code ranks high on the list of awkward problems. Because of this, we have become very interested in methods of changing application behaviour without changing the application itself. One convenient way of doing this is to insert filters into the IP data stream, as was done with the BSSP protocol, discussed in Marcello Lioy's masters thesis. Inspired by some similar work done by Bruce Zenel at Columbia, we are now moving to a more general version of the BSSP.
While BSSP provides stream prioritization and maintenance during disconnection, we have identified several other useful services that could be provided by a similar utility. This thinking has led to the idea of a filter pipeline for each TCP stream. This would allow a client to "mix and match" filters for each stream, chosing from a selection of standard, hard-coded filters, or downloading customized ones as they are needed.
Filter pipelines will be identified by a key, generated uniquely from the source and destination address/port pairs. Wildcard keys are also permitted, allowing filters to be specified for more general traffic. Since more than one TCP stream might match a given wildcard key, filters on this type of traffic will exist only to observe it, and insert filters for the specific streams that are encountered. This leads to two general classes of filters that exist:
If a specific key matches the stream, then only the filter stream associated with that key will be called. If there is not an exact match, then all wildcard matches will be called, starting from the most general. This will always result in a specific entry being created for the stream (which may have a null filter pipeline). After all these wildcard matches have been called, the packet will be passed into this newly-created filter pipeline.
Filters are completely modular, and have no awareness of each other. When functions insert filters into a pipeline, however, an order may be specified. For example, a call to insert a compression filter may specify that it must be after a packet-dropping filter (if one exists). The insertion function may also say the filter being added should replace some filters (a compression filter may know that its presence makes some other classes redundant, so they should be removed while it is present), and should not be inserted in the presence of some others (for the same reason.) These precedence requirements will be stored with the filter, so they may continue to be applied to future insertions into the stream.
The types of service that we intend to provide include data compression and reduction (intentional loss). In order to do this, the sequence numbers of the packets received by the client will be different than those sent by the remote source. One standard filter, included in the BSSP daemon, will maintain a table that correlates the numbers sent and received, allowing the client to acknowledge the receipt of different data than was actually sent, while not violating TCP semantics.