TCP PEP (Performance Enhancing Proxy) Correctness Project


There is plenty of evidence (and commercial products) showing that TCP PEPs improve E2E performance.  Some forms of PEP (Performance Enhancing Proxy), however, do so only by breaking the E2E TCP semantics.  Specifically, the PEP may acknowledge packets that it has received, but that have not yet been acknowledged by the true end host.  As a result, PEPs are considered a bad idea by both the research and standards communities in spite of their performance advantages.

I suspect that PEPs have to an extent unfairly gotten a bad rap.  The reason is that TCP correctness is typically decoupled from application correctness---indeed, the application cannot even tell, through the socket interface, which bytes have been acknowledged by the other end and which have not.  If the application provides its own acknowledgment, then a bogus acknowledgment from TCP will not compromise the correctness of the application (i.e. the sender won't be mistaken about what the receiver has gotten).

I would like to better understand what exactly the consequences of breaking TCP reliability semantics are from the application's point of view.  To do this, I'd like each student to examine one application carefully (including looking at its software) and determine analytically if its correctness would be broken by a broken TCP.  In doing this, the student should assume that the PEP has the following properties:

1.  The PEP can detect when E2E byte acknowledgment semantics have been broken (i.e. it acknowledges to the sender a byte that the receiver will never receive), and it resets the connection when this happens.
2a.  The PEP never makes transmission errors.
2b.  The PEP may make a transmission error (i.e. by itself corrupting bytes while it buffers the stream, but providing the receiver a checksum that computes correctly on the corrupted bytes).

Please mail to the class mailing list (cs619-l) which application you would like to analyze, and which public domain software package you will use.  Only pick an application that has not yet been claimed by another student.

The deliverable for this project will be a short description of whether the application will break (where breaking here means that the sending application thinks that the receiver has received something that it hasn't), if so how, and if not, why not.