Subject: RE: [Simple] MSRP: Flow Control

From: [email-masked]
Date: Tue, 29 Apr 2003 10:46:41 +0300

Henning,

I totally agree with you. IMHO, we should think long and hard why we want the relays to multiplex many sessions on a single transport connection before we run with the idea and go off specifying all kinds of flow control mechanisms and size limits on the app layer.

I don't think im-sessions-01 gives a proper motivation for message switching relays. It does motivate the concept of relays (nat/fw traversal), but *assumes* they also need to do message switching instead of connection switching.

Cheers,
Aki

 > -----Original Message-----
 > From: ext Henning Schulzrinne [mailto:[email-masked]]
 > Sent: 29 April, 2003 01:23
 > To: Adam Roach
 > Cc: Ben Campbell; 'Paul Kyzivat'; James Undery; Simple WG
 > Subject: Re: [Simple] MSRP: Flow Control
 > 
 > 
 > > Admittedly, my knowledge in this area is a bit rusty, but
 > > I seem to recall (and my intuition backs this up) that
 > > a window of size 2 is *much*, *much* better than a window
 > > of size 1, and that increasing beyond that provides
 > > asymptotically diminishing returns.
 > 
 > I assume you're talking about window flow control at the transport 
 > layer. The thing that matters is how much data can be in 
 > flight at any 
 > given time - you want to be able to keep the pipe filled. 
 > This has to do 
 > with the number of bytes outstanding, not the number of packets.
 > 
 > If you didn't put multiple sessions on a single TCP or SCTP 
 > connection, 
 > there would be no issue - the relays and TCP/SCTP would 
 > automatically 
 > push back all the way to the source *as long as each relay can start 
 > forwarding before it has received the complete message*. (Otherwise, 
 > you'd get a version of re-assembly blocking.) This pushback 
 > is maximally 
 > efficient, i.e., no duplicate messages, etc. The pushback 
 > also occurs if 
 > you have a fast link/slow link situation and slows down the 
 > sender to 
 > the speed of the slowest link in the chain.
 > 
 > Thus, the whole problem only occurs if we insist on multiplexing 
 > multiple sessions on one transport connection and if we insist on 
 > message-based forwarding where the message size can exceed the relay 
 > buffer size.
 > 
 > I would much rather allow/support cut-through switching on 
 > individual 
 > TCP connections than limit the transfer size.
 > 
 > If we do have some app-level XON/XOFF, just sending a status 
 > code after 
 > the message is half-way across seems counter-productive, 
 > since you'd end 
 > up dropping the parts that are already on the wire and have to 
 > retransmit them. (TCP flow control won't help you there - 
 > the buffer can 
 > be quite large.) You would need a "mother-may-I" mechanism that asks 
 > first and sends later.
 > 
 > Henning
 > 
 > _______________________________________________
 > Simple mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/simple
 > 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 29 Apr 2003 08:39:30 -0500

> I don't think im-sessions-01 gives a proper motivation for message switching relays. It does motivate the concept of relays (nat/fw traversal), but *assumes* they also need to do message switching…

As I mentioned in a previous message, the primary motivation for message
switching is connection sharing. While I recognize that we do not have a
requirements document for this, I think we have had consensus for some
time that connection sharing is a good thing, for reasons of congestion
control and effecient use of a scarce resource (number of TCP
connections) at relays.

Adam has recently pointed out that this may not really help from a
congestion control viewpoint. If we determine that connection sharing is
not worth the trouble, then it may make sense to revisit the tunneling
relay approach.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Apr 2003 09:56:58 -0400

> not worth the trouble, then it may make sense to revisit the tunneling

Now that we seem to have explored the downside, in terms of complexity 
and functional restriction, of connection sharing, I would suggest we 
consider if dropping this objective would yield a more tractable design.

Since MSRP clearly has to work without relays, connection sharing can't 
be crucial to congestion control. I doubt that the socket limitation 
will be a real limitation in practice, given the experience with IRC 
servers that somebody else mentioned earlier. If we posit a per-host 
application-layer forwarding rate of around 60 Mb/s, each such 
connection would only get about 1 kb/s. (Clearly, not all connections 
are going to be active at any given time, but if you're sending only a 
message every few hours, session mode is probably not the right answer 
anyway - your friendly broken neighborhood NAT will have dropped the TCP 
connection long ago unless you use keep-alives.)