On 1 Apr 2001 at 16:40 -0700, Michael W. Condry apparently wrote:
Do you think th?is applys to a streaming callout server in an OPES
environment
It's a different situation. OPES wants to transfer actual user plane
data to the callout server. Midcom is strictly for controlling the flow
of data through a different box (function). Different requirements.
...Scott
At 02:38 PM 4/1/2001 -0500, you wrote:
On 30 Mar 2001 at 15:18 -0600, Andrew Molitor apparently wrote:
What are you expecting to carry in this protocol that you would want
message streaming? I think of it as a small-message control protocol.
I am thinking of cases in which a SIP proxy wants to control
a middlebox that is many many milliseconds away. If the middlebox is
N milliseconds away, and you want to do NAT and firewalling, you are
optimistically limited to 1000 / (8 * N) calls per second in the
absence of streaming
(4 messages at 2*N millseconds round trip = 8*N milliseconds/call)
which is really low for N bigger than about 4 or 5.
If the control protocol is simple and UDP-based, then you won't have to
wait for acknowledgements either. I like just saying that you want to
execute many control transactions per second at a distance.
...Scott
_______________________________________________
midcom mailing list
midcom(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/midcom
Michael W. Condry
Director, Network Edge Technology