[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
detlef.bosau at web.de
Fri Jan 12 16:09:07 PST 2007
Joe Touch wrote:
> PS - this could also happen within a single CWND, e.g., if the network
> path temporarily shifts around the TCP-splitter. It doesn't require an
> entire window wrap to occur.
The only scenrios where I see a justification / necessity for doing
splitting or spoofing are scenarios where the TCP flow must pass the
split box / spoofing box / PEP anyway. These are scenarios without path
redundancy or path transparency. Hence, in these scenarios the path
cannot temporarily shift around the splitter because no alternative path
exist. If we want redundancy in those scenarios, we have to consider hot
stand by nodes for splitters which keep flow states and any other data
which is "hard" and cannot be recovered synchronously with the backed up
To be not misunderstood: I don´t want to make restrictions for the
benefit of a splitter. I think in scenarios where an alternative path to
a splitter exist, a splitter must not be used. In my opinion splitters
are to be used with maximum care and only in exceptional cases where any
known alternative is worse than a splitter.
To my understanding we can avoid wrap around problems by having the
receiver window sufficiently small. And of course, a splitter does flow
control by itself. I´m not convinced that it is necessary to have 4
GByte of unacknowledged data in the fly in all networks. And _if_ we
need windows of this size we can reconsider the length of our sequence
numbers. But at least for terrestrial networks 4 GByte of data in
transit seems extremely large to me.
WRT mobile networks: I´m still looking for material about delivery times
and their distributions. It´s absolutely not necessary to have accurate
quantitative data here. But it would be helpful to know wether we have
to cope with delay spikes of up to 1 second, up to 10 seconds or up to
10 minutes and whether these happen once a minute, once a day or once a
year. When we encounter maximum delay spikes of 1 second not more than
once a decade, the best idea is to simply ignore these. If a (wireless)
link offers 1 Gbps throghput and is blocked each other minute, the
situation might be somewhat different.
Particularly, and perhaps Anil could help me there, I want to get an
idea what is already done by NOs and where research is necessary. As I
said before, I presume that there happen quite a lot of things which are
not publicly documented. This can lead first to duplicate research. And
second this can lead to "strange" problems where protocols and
applications do not work for unkown reasons, and the real problem is
that there is some strange middlebox in use which does one of these neat
"company confidential" or "non disclosure" algorithms. Obscure
middleboxes can render our whole work completely worthless because they
can cause problems no one can solve.
Particularly, I eventually want to understand the problems TCP and other
protocols encounter on mobile links - and afterwards I can take a
position how these can be solved. As I said before, much of the
literature in this context appears quite obscure to me. It simply makes
no sense to e.g. talk about a splitter and its benefits in a mobile
network when it is yet unclear whether a splitter is even necessary.
> Agarwal, Anil wrote:
>> Joe Touch wrote -
>>>> Well, it´s just how I understand the semantics of a "CLOSE ACK". When a
>>>> receiver issues a CLOSE ACK, we know that all data has reached the
>>>> receiving socket.
>>> We should know that. But when we have intermidiates spoofing ACKs, all
>>> we know is that the two endpoints agree that they have closed. The data
>>> itself is not known.
>>> Case in point - if the intermediary ACKs data and continues to buffer
>>> it, and the window wraps, and then the intermediary goes down, the
>>> endpoints think the data reached the buffer correctly but it really
>> did not.
>> Are you describing a scenario where a TCP-Splitter buffers up 2^32 bytes
>> of sender
>> data without delivering any to the receive end-point, then goes down, and
>> the end-points continue the connection using the wrapped
>> sequence number, which in this case match up just right, so that the
>> 2^32 bytes disappear down a black hole, without the sender or receive
>> being any wiser?
>> Anil Agarwal
>> ViaSat Inc.
More information about the end2end-interest