RE: side effect of eager-ACK

Stefan Savage (savage@cs.washington.edu)
Thu, 25 Jun 1998 16:22:02 -0700

Wrt keepalive,
Eager-ack was only a way to get connection bandwidth up quickly
when a connection is started. This is pretty easy to differentiate from
a keepalive datagram (connection otherwise idle, very small packet,
doesn't advance sequence numbers, etc....) Finally, there is
considerable debate about the utility of keepalive at the TCP level. I
don't believe that keepalive is mandated as part of the TCP spec, and
any application that truly needs to stay informed about availability
does an application level keepalive (since the application can crash and
TCP keepalives will keep going).

- 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
>
>
>