Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva tion"

From: Mendelovich Meir <[email-masked]>
Date: Tue, 17 Jun 2003 11:28:38 +0300

Mark,
 I agree that ideally the TCP should handle these situations. But, today's
networks (GPRS & CDMA1X) don't solve it. E.g. they change the device IP.
 Even in the ideal network, I doubt that it would solve disconnection of
more than 10 seconds that are very common.
 Another situation that requires passivation is Web Mail (or the suggested
mobile proxy) that serves several hundreds of session simultaneously. Such
server needs to passivate IMAP4 sessions. E.g. if subscriber has 5 minutes
think time, we don't want to keep his IMAP4 session open. This really
influences the scalability of such systems.

	Meir :->

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]] 
Sent: Monday, June 16, 2003 5:55 PM
To: Mendelovich Meir
Cc: Vaudreuil, Greg M (Greg); [email-masked]; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Mobile messaging clients barriers - IMAP4 "passiva
tion"

On Mon, 16 Jun 2003, Mendelovich Meir wrote:
>  Mobile clients are working in very "noisy" environments: they change 
> cells, bearers and sometimes get out of signal. Every time that there 
> is a sudden momentary disconnection, the old session hangs and new one 
> should be initiated. Though part of the problem would be solved by 
> underlying standards like mobile IP, disconnections will still be a 
> problem.

This sounds like a bug in the TCP/IP implementation.  Abandoning a perfectly
good connection because of a momentary outage is, to my mind, a bad idea.
Abandoning that connection to initiate a new one is a terrible idea.

Back in the old days, we went to great effort to preserve sessions across
network outages, and to restore communication in the session promptly when
network connectivity is restored.  A fair amount of the architecture of TCP
becomes pointless if sessions (especially in highly stateful protocols like
IMAP) are destroyed before of a hiccup in a radio link.

Nor are the "noisy environment" problems new.  Refer to the old packet radio
work of 20-30 years ago.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate. Si
vis pacem, para bellum. _______________________________________________
lemonade mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Tue, 17 Jun 2003 06:41:03 -0700 (PDT)

> networks (GPRS & CDMA1X) don't solve it. E.g. they change the device IP.

Changing the IP address is a very serious problem.  CDPD manages not to
have that problem.  Will this issue go away with IPv6?

> more than 10 seconds that are very common.

I am very unhappy with any product that unilaterally breaks my connection
because of a mere 10 second network outage.  The benefit of TCP/IP
technology is that I could have a 10 *minute* network outage and still
recover my session when connectivity is restored.

There is a reason why RFC 3501 says that the server should wait 30 minutes
before abandoning a session due to inactivity.  Similarly, the client
should not abandon a session without permission from the user.

> influences the scalability of such systems.

Yes, I've seen many poorly-designed Web Mail systems that drop sessions or
spawn extraneous sessions for no good reason, and I've seen scalability
problems created by this excessive session-creation/destruction.  The
mentality of the designers of such systems clearly is to be aggressive in
destroying TCP connections, in the false believe that such connections are
expensive.

We did not make that mistake in our Web Mail system.

TCP connections are cheap.  Renegotiating authentication and TLS, and
rebuilding IMAP state, is not.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: [email-masked]
Date: Tue, 17 Jun 2003 07:55:39 -0700 (PDT)

> have that problem.  Will this issue go away with IPv6?

Agreed. IMO if IP address stability really is an issue that needs to be solved
we should at least look at things like RSERPOOL as a means to solve it.

> recover my session when connectivity is restored.

Agreed again. A TCP stack that breaks connections when there's a very short
network outage is BROKEN, and the way to fix that is to fix the stack. No other
approach is reasonable, really, since even if you were to deploy something on
top of a broken TCP implementation to restablish connections in the face of
frequent spurious disconnects due to short outages the resulting overhead and
latency would be unacceptable.

> destroying TCP connections, in the false believe that such connections are

Yep. This is a belief that seems to surface periodically and for no good
reason. The amount of overhead associated with a connection in a well designed
stack is surprisingly small.

> rebuilding IMAP state, is not.

Once again I agree. And let me add a meta-comment as well: This group seems to
be conflating geniune issues that crop up in the wireless space with issues
caused by exceedingly poor implementations. To the extent things fall in the
latter category, trying to solve such implementation problems with protocol
hacks is not only silly, it has been shown over and over and over again that it
just doesn't work. Instead what you end up doing is having your protocol
designs chase around after the latest round of implementations botches, with no
end in sight.

Let's please try not to heed the siren song of fixing broken implementations
with protocol hacks. Let's instead focus on the real issues. There are more
than enough of those that need to be addressed to keep us busy.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 17 Jun 2003 15:48:50 -0700

At 6:41 AM -0700 6/17/03, Mark Crispin wrote:

>  The benefit of TCP/IP

I regularly put my PowerBook to sleep and carry it to meetings.  It 
generally takes much several minutes for me to get there and 
reconnect to the network.  My ssh tunnels stay up during this period.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.               --Robert Benchley

---

From: Mark Crispin <[email-masked]>
Date: Tue, 17 Jun 2003 16:12:23 -0700 (Pacific Daylight Time)

> reconnect to the network.  My ssh tunnels stay up during this period.

This works like a champ in TOPS-20.  My favorite trick is to put TOPS-20,
running under VMware, to sleep, *reboot* the underlying machine, resume
TOPS-20 (perhaps after a few hours), and show folks that its TCP sessions
are still alive and communicating.  That's how TCP is supposed to work!

It also seems to work in UNIX, but I don't use UNIX on a laptop that much.

It doesn't seem to work in Windows XP; putting the PC to sleep seems to be
treated as a request to kill all open network connections.

I could perhaps understand if it threw up a panel and ask what I wanted to
do if it can't regain the lease on the same IP address.  But unilaterally
killing perfectly good TCP connections is a bug.

Data is not the same as voice calls.  An outage should not destroy a data
call without the user's permission.

-- Mark --

---

From: [email-masked]
Date: Tue, 17 Jun 2003 16:51:46 -0700 (PDT)

> reconnect to the network.  My ssh tunnels stay up during this period.

Indeed. I have to say that one of the most compelling reasons I've found for
upgrading from OS 9 to OS X is that OS 9 closed all connections when it went to
sleep whereas OS X does not. I take advantage of this several times every day
now.

I have to confess that until I experienced the OS X way I didn't realize just
how important this is and how much of a botch OS 9's behavior was.

				Ned