Subject: RE: [Simple] MSRP: Flow Control

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

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> 
> I recall a big push-back to the idea of not allowing overlap 
> on IMs back
> in the page-mode spec days. It is not clear to me that 
> allowing a small
> fixed number of pipelined messages is significantly better 
> than complete
> non-overlapping for the situations that people seem to care 
> about--that
> is, large file tranfers.

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.

> > If you add this, Head-of-line blocking goes away, since
> > relays can be engineered to buffer incoming messages,
> > with assurances that each session can take a well-known,
> > finite amount of memory. (You really want the application
> > to read information off the wire as it arrives, instead of
> > allowing the incoming TCP buffer to fill up, causing
> > retransmissions and backoff at the transport layer, anyway).
> 
> I assume you mean it, plus a  message size limit, makes HoLB go away,
> right?

Right. I thought I had said that. Apparently, I'm losing my mind.

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Apr 2003 17:35:49 -0400

inite amount of memory. (You really want the application
>>>retransmissions and backoff at the transport layer, anyway).

Not reading at the application layer does *not* cause retransmissions 
and backoff in TCP. It causes the sender to shut up when the flow 
control window is exhausted (where the flow control window is no larger 
than the buffer space available at the receiver).

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Apr 2003 18:22:52 -0400

> 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