- From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
- Date: Fri, 19 Feb 1999 12:51:56 +0100
- To: <spreitze@parc.xerox.com>, Chris Newman <chris@innosoft.com>
- Cc: ietf-http-ng@w3.org, discuss@apps.ietf.org
At 13:05 09.02.99 PST, spreitze@parc.xerox.com wrote: >Note that the charter isn't explicit on this point. I anticipate the WG to debate this, and decide that the reciever-given restraint in the mux layer should be an optional module, because some applications will need it and some won't. > If I was to be present at the debate (which I have no reason to think I would be), I'd make the argument that any kind of data transfer without receiver- given restraint is tantamount to a request for assisted suicide. An implication of muxing across TCP (I think) is that the receiver-given TCP window will be set by the mux layer, and depend solely on how fast the mux layer can put the data into queues at the layer "above"; blocking all mux channels because of one slow client will be unacceptable in many cases. However, losing data is also unacceptable in many cases, as is duplicating the loss recovery mechanisms in TCP; this means that one must never get into a state where the multiplex layer has to choose between throwing away data and refusing to pass data across *any* connection. Thus, the only case I can imagine where receiver-given restraint is not needed is where the higher layer protocol "guarantees" that there will never be a significant number of bytes passed between operations (for instance POP client-to-server without command streaming). However, this leaves a wide-open door to denial-of-service attacks (just send "LOGIN enormouslylongstringthatwillcertainlycauseabufferoverflow") and strange results from changed enviroments (streaming mode, for instance, where it makes perfect sense to send 500 LIST requests without waiting for the responses). My off-the-top-of-my-head thinking only.... Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no
Received on Friday, 19 February 1999 06:54:24 UTC