Subject: [lemonade] Imap-notify-07 - TCP overflow

From: Eric Burger <[email-masked]>
Date: Mon, 23 Jul 2007 06:39:05 -0500

Would it be reasonable to suggest to server writers that once they detect
the TCP window filling, they issue a NOTIFICATIONOVERFLOW on that stream and
cancel the subscription?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Ned Freed <[email-masked]>
Date: Sun, 29 Jul 2007 07:48:26 -0700 (PDT)

> the TCP window filling, they issue a NOTIFICATIONOVERFLOW on that stream and

No, I don't think it is reasonable to suggest this. For one thing, while 
applications usually have some control over the window size and the algorithms
used to fill and empty it, AFAIK calls to find out how full the window is don't
exist in a lot of cases.

But even if such calls were universally available I don't think applications
should be second-guessing the transport layer. After all, what's the window for
if it doesn't fill up from time to time?

If a genuine need exists to detect and deal with transport issues that
go beyond what timeouts can provide, we should be looking at a transport
other than TCP.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 29 Jul 2007 18:01:43 +0200

IMO reacting to a full window would be overreacting in the vast majority 
of cases.

The window does fill up now and then, e.g. while processing 'a uid fetch 
1:* flags' or 'b uid fetch 42 body.peek[2]'. Mostly the client takes 
care of its data, the window eventually empties, and all is well.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Sun, 29 Jul 2007 09:08:20 -0700 (PDT)

> used to fill and empty it, AFAIK calls to find out how full the window is don't

Exactly!  This is why the stuff in RFC 3501 section 5.3 is a pile of 
nonsense, put in (over my objections) to placate individuals who simply 
could not accept that purely asynchronous protocols are a pipedream.

Similarly, the stuff in RFC 3501 section 5.5 really is nothing more than 
command pipelining, but had to be couched with similar nonsense.

> go beyond what timeouts can provide, we should be looking at a transport

I recognized this on day 1, and originally intended that IMAP use UDP for 
this very reason.  The same individuals who screamed for asychronous 
protocols blocked this because "UDP is unreliable."

It's sadly amusing that, 20 years later, people are still unwilling to 
face the reality of protocol engineering; and that what looks good in a 
computer science textbook isn't so good in the real world.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.