[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
touch at ISI.EDU
Wed Jan 10 13:39:47 PST 2007
Detlef Bosau wrote:
>>> 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.
The result is that you think you started/ended a connection correctly,
but that the wrong data got there?
As to PEPs...
> 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?
Pacing is a simpler version of what you're asking ACK clocking to do; if
ACK clocking works, pacing definitely should.
Sr. Network Engineer, USAF TSAT Space Segment
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070110/d6265b10/signature.bin
More information about the end2end-interest