There are a couple arguments that this isn't so bad though:
1) Eager ACK is probably only important on short lived flows so you
wouldn't do it for long connections (and you certainly wouldn't for
telnet traffic)
2) As long as TCP close is precise, then this isn't really a new failure
mode, since the receiver node could always crash after receiving the
data
3) It is possible as Tom said, to replicate hard state between detour
boxes if this is a real issue (I'm not so excited about this idea
though)
Finally, I don't think any of us are very excited about doing things
that break TCP end-to-end reliability semantics for its own sake. We
only end up doing so when there's no other way to get the result we
want. For example, while our design philosophy has been to not change
end-host systems, if we relaxed this position then we could solve the
slow-start problem a different way. We might instead charge TCP to
accept a piggy-backed indication of the bottleneck bandwidth so it can
do quick startup. If anyone can think of a better way to induce a show
flow sender to send faster without breaking end-to-end reliability, then
I'd love to hear it (from my examination of BSD, it doesn't look like
dupdup-acks will work).
- Stefan
> -----Original Message-----
> From: Kenichi Ishikawa [SMTP:ishi@cs.washington.edu]
> Sent: Thursday, June 25, 1998 4:08 PM
> To: syn@cs
> Subject: side effect of eager-ACK
>
> Hi, I'm close-tongued person, Kenichi.
>
> I think eager-ACK is harmful.
> How do you think about these two problem?
>
> 1 A detour router crash causes breaking all TCP connection on it.
>
> if one doesn't use detour router, a crash of a router causes changing
> the routing tables and existing TCP connection will eventually select
> a new route with keeping the same TCP connection.
>
> in the case of detour router crash, eager-ACKed packets were lost and
> unrecoverable. this causes breaking the TCP connection. and both or
> either end must restart a new TCP connection.
>
> Isn't this a problem for long-lived persistent applications?
> examples of these application:
> o 24-7 connected telnet session.
> o VPN or some tunnel connections.
>
>
> 2 KeepAlive doesn't work as expected.
>
> Some application uses KeepAlive to detect the failure of the route
> when they doesn't transferring any packet.
>
> Should the detour router eager-ACK to KeepAlive datagram?
>
> --
> Kenichi Ishikawa
>
>
>