Subject: RE: [Simple] MSRP: Flow Control

From: Adam Roach <[email-masked]>
Date: Mon, 28 Apr 2003 22:22:33 -0500

> Adam, clearly you misunderstood what I said. Please re-read, 
> and respond again when you've rested and thought about it.
> You should probably also re-read the note from Henning that
> you referred to, as I believe it refutes the argument you
> are extending from it.

Ummm... the only argument I made based on his note
was "Keep in mind that 'get rid of connection re-use'
is one of the earlier suggestions that I made. It's a
nice, clean answer to both HoLB and flow-control."

How is this contradicted by Henning's argument, which boils
down to, and I quote: "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"?

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Apr 2003 23:26:04 -0500

> - the relays and TCP/SCTP would automatically push back all
Ah. I was thinking the part about:

"If we do have some app-level XON/XOFF, just sending a status code after 
the message is half-way across seems couner-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."

if a relay's buffer space is REALLY full (or if it is really ticked 
about a presumed DoS attack), it can shut down the listening socket. 
This results in a maximum transference of one window-size after the 
shutdown, followed by an RST in the other direction. And if it is REALLY 
REALLY ticked, it doesn't even send the RST and just starts silently 
discarding received packets.

The inefficiency that Henning points out actually applies even in the 
case of a no-mux scenario. Whenever there is store-and-forward, the 
potential for the output queue to congest exists, thereby generating the 
potential need to shut down the input queue. Otherwise, one can exhaust 
the ouput-queue resources, thereby generating the equivalent of HOLB 
(the input which SHOULD be forwarded CAN'T be forwarded because the 
unforwardable stuff is holding all the resources).

--
dean