At 10:51 AM 1/9/01 -0500, Anil Agarwal wrote:
>1. In a purely, theoretical sense, the answer is YES, as stated by many
> authors. The spoofer acks packets to the sender that have not been
> delivered to the destination host.
this is what makes me wonder "what is the objective here"?
If what we're trying to do is make the sender put additional data in
flight, we don't have to acknowledge the data that is outstanding. We only
need to increase the window, and do so in a manner that triggers additional
transmissions. For example,
Receiver <-> Spoofer <-> Sender
if Receiver says that it will accept a window of N octets starting with
octet n, Spoofer can increment the window to tell Sender that Destination
is willing to receive N+M octets starting at octet n. Doing this will go
through standard slow-start, and so will not actually increase Sender's
transmission rate until several RTTs have gone by. If Spoofer is trying to
get Sender to send more quickly NOW, he must increment the window in
several successive messages: he can send a message every 10 milliseconds
(say) which says Receiver will accept a window of N+m*MSS octets starting
at octet n, for m = 1, 2, ..., M/MSS. That way, Sender will be provoked to
send the next segment every 10 ms, achieving a high rate quickly, and
Receiver will be none the wiser. We don't actually acknowledge anything
until Receiver acknowledges it, so there is not a question of things being
lost in flight. As long as there is no loss, this works just fine.
If window size is an issue (if we are trying to move more than 64K bytes
per RTT), someone who can add to the offered window can insert a window
scaling option as well. And selective ack while he's at it.
The problem, of course, is when a loss or massive reordering event occurs.
Receiver receives messages (and acks them) up until the loss point, and
then receives as much as its window allows after that, but discards all the
stuff that Sender has sent over that. Sender will use the fast
retransmission algorithm to get moving again, but will be in the fast
retransmit phase (essentially sending one segment per RTT) for a really
long period. The only way around that is for Spoofer to take responsibility
for his actions and retransmit on Sender's behalf. Spoofer has to buffer
Sender's data and retransmit it in a manner that appears normal to Destination.
The shared-fate issue is still there - if Spoofer dies an untimely death,
Destination and Sender have no chance of figuring out what he did, and will
do better to tear down the connection and try again.
In all, the best approach from my humble vantage point is to actually
terminate and reopen the TCP connection, and (at least conceptually) copy
data between them. We break the end to end semantic in the sense that an
untimely loss of Spoofer leaves Reciever and Sender unable to recover, but
everything else still works without having to wrap ourselves around an axle.
What is the objective in this case? Is it to increase transfer rate? If so,
why is pre-acknowledging data on the table?
Joe mentioned the problem of having > 2 billion bytes outstanding so that
the window wraps. While this is a theoretical problem, until we have
terabit links with RTTs on the order of seconds, this is not a practical issue.
This archive was generated by hypermail 2b29 : Tue Jan 09 2001 - 18:55:32 EST