Subject: RE: [Simple] MSRP: Flow Control

From: Adam Roach <[email-masked]>
Date: Mon, 28 Apr 2003 16:36:26 -0500

If we go down this path, I would at least want to define
a status code other than 503 that basically means, "You have
too many outstanding transactions IN THIS SESSION, so back
off until some of them complete. You can continue to create
other transactions for other sessions." It allows relays
to choose their own windows.

It still doesn't solve the no-relay case. I guess
transport-layer pushback will be sufficient for that,
though.

/a

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 16:25
> To: 'Adam Roach'; 'Paul Kyzivat'
> Cc: 'Henning Schulzrinne'; 'James Undery'; 'Simple WG'
> Subject: RE: [Simple] MSRP: Flow Control
> 
> 
> 
> I think flow control is a completely seperable issue from 
> HOLB, although the
> two can intersect.
> 
> The fundamental flow control problem is that if there is more 
> stuff flowing
> into a relay node than there is flowing out of it, then the 
> buffer space
> available on that node gets used up. This is an application issue, not
> really a transport issue, and it potentially applies to ANYTHING that
> operates in a store-and-forward manner.
> 
> I believe the flow control problem for MSRP, assuming messages are not
> infinitely long, is easily addressed by the allowing the 
> intermediate server
> to respond to a message request with a "Wait! I'm Full! Stop 
> Sending Me
> Stuff" response, perhaps along the lines of the "Retry After" 
> semantic in
> HTTP and SIP. Oddly enough, this is reminiscent of frame 
> relay's BECN or
> TCP's ECN functions, RS-232's XON and XOFF (or RTS/CTS), and 
> so on. It's
> also very similar to the way that SMTP works. Not rocket 
> science, and I
> don't think there's any need to develop a standardized 
> mathematical formula
> describing what "full" means to a server  . . . 
> 
> --
> Dean
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 28 Apr 2003 17:43:59 -0500

> other transactions for other sessions." It allows relays to 
> choose their own windows.
> 
> transport-layer pushback will be sufficient for that, though.

I think you're making this harder than it needs to be.

Ignoring our SIP-distortion of retry-after (I just reread a bunch of the
debate about that) let's consider what RFC 1945 says:

In Section 9:

   503 Service Unavailable

   The server is currently unable to handle the request due to a
   temporary overloading or maintenance of the server. The implication
   is that this is a temporary condition which will be alleviated
   after some delay.

       Note: The existence of the 503 status code does not imply
       that a server must use it when becoming overloaded. Some
       servers may wish to simply refuse the connection.

And in D.2.8 Retry-After:

   The Retry-After response-header field can be used with a 503 (service
   unavailable) response to indicate how long the service is expected to
   be unavailable to the requesting client. The value of this field can
   be either an HTTP-date or an integer number of seconds (in decimal)
   after the time of the response.

So this seems to me that the semantic is "I can't handle this request right
now, and optionally, I suggest you try again after the indicated period."
This says nothing about "too many outstanding transactions", "other
transactions", or "other sessions" -- it's just "this request". 

In the context of MSRP, whether a relay chooses to do the MSRP-equivalent of
HTTP-503 for every request on a session when downstream requests on that
session are backed up, for individual requests that would cause buffer
capacity to be exceeded, only for requests that appear to be correlated with
prior outstanding requests, for every request in every session, or some
other variation thereof is probably an implementation issue IN THE RELAY and
really only matters to the relay itself. All of these implementations can be
handled with a protocol semantic like that of HTTP's 503.

And as 1945 points out, it may be more appropriate, in some cases, to simply
refuse a connection or to let TCP windowing provide transport-level
throttling.

--
Dean