[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Detlef Bosau]

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 
lost state.

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
>> claim!)
>>     
>
> 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?

Detlef