TCP problems with 2.0.x

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

Rodney Thayer wrote in a message to Mike Bilow:

>POP is inherently message granular.  Why bother with keepalive?

 RT> because when the intervening internet, or the ISP, or the
 RT> machine at the client end decided to go into an
 RT> inappropriately quiescient state you get some kicks that
 RT> have a chance of getting it out of that state. 

 RT> obviously this depends on what the code does in keepalive
 RT> processing (for example, is it smart enough to react to a
 RT> returning "port unreachable" icmp message)

 RT> Trust me, it would be more preferrable than what I do to the
 RT> poor support people at my ISP when POP3 decides to hose up
 RT> in my face (right, Rich?) 

Handling ICMP Port Unreachable is a difficult issue under any circumstances,
since this can often result from catastrophic failure to which adding lots of
traffic is not helpful.

In any case, it seems to me that the best situation for POP3 would be to have
the TCP circuit expire normally via timeout if one end just dies.  "Kick"
implies that the sender has gone into excessive backoff rather than died, and
TCP/IP assumes that such situations are indicative of congestion rather than
unreliability.  In fact, TCP/IP presumes that it is operating above some kind
of link and physical layers which are sufficiently relaible to support the
datagram nature of IP.  There is no point to kicking the receiver rather than
the sender, since the receiver will send TCP ACK frames quite promptly after a
very short delay.

It is considered evil to compensate for unreliability below the IP layer by
making backoff more aggressive, the Internet equivalent of running a red light.
 
-- Mike