[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
detlef.bosau at web.de
Fri Jan 5 12:45:44 PST 2007
Joe Touch wrote:
>> Shouldn´t the ACKs be clocked by the TCP data packets, at least in
>> symmetric paths? Thus, the ACK clocking should reflect the TCP rate
>> which is achieved downstream?
> It does - 'downstream' is really the splitter, i.e., the thing
> generating the ACKs. Since the path to the splitter and back has no
> bottleneck, there's no ACK pacing going on.
O.k. That´s the general problem with splitting and ACK pacing. When you
do dumb spoofing, the sender is not correctly paced by the ACKs. In case
of a (imminent) buffer overrun at the splitter the sender is throttled
by TCP flow control.
>> It´s interesting what handles to the final CLOSE ACK here which is
>> typically not spoofed in splitters to ensure poper ACK semantics.
> I don't understand "proper ACK semantics". The splitter destroys those.
> The semantics that may be kept are at the connection level
> (open/closed), but the semantics of data ACKs are irrevocably destroyed.
I think of the semantics at the connection level. Which I think to be
sufficient in many cases. In fact, I think the main problem is that a
splitter introduces a single point of failure / hard state into the
path: If a router fails, the flow may continue along an alternate path.
If a splitter fails, the flow is dead because we cannot recover from the
However, we should careful look at the technology in use: Particularly
in mobile wireless networks, I´m not totally convinced (perhaps somebody
can comment on this one?) that there are no single points of failure in
the path, e.g. a SGSN in GPRS. In that case, the state is "hard" anyway
and "making it harder", e.g. by putting a PEP at the SGSN, does not
really worsen the situation.
>> Perhaps, the scheduling caused variations in packet delivery times are
>> the most distinguishing mark for mobile wide area networks compared to
>> other network technologies. (I would be glad to get comments on this
> Variations in delivery times can be handled via PEPs that don't spoof
> ACKs, e.g., ones that pace the data and/or ACK paths, but don't actively
> participate in the communication.
Really? I agree with you for the Remote Socket Architecture
(Schlager/Wolisz) because that architecture actually does not split the
connection but places the PEP mechanism at the application/socket interface.
Otherwise the problem is: When the bandwidth sender - splitter is, e.g.,
the average bandwidth / rate splitter-sender but far less than the
maximum rate splitter / sender than a simple router perhaps would hardly
store any data and thus hardly equalize the rate / delivery times.
Thierry describes delay spikes of several seconds. If we think about
UMTS, we can imagine a wireless link were nothing happens for up to
several seconds - thus even no data is clocked out from the sender - and
then we have about 2 Mbps throuhput for a short time - which is perhaps
much more than the actual Internet path can carry. In such a scenario we
want to have the router / splitter / PEP / whateverbox buffer the data
and equalize the rate variations. Can this be achieved by pure pacing in
the one or other direction?
More information about the end2end-interest