Subject: RE: call protocol requirements questions

From: "Eric Burger" <[email-masked]>
Date: Thu, 2 May 2002 14:25:40 -0400

My $0.02

On Behalf Of Reinaldo Penno:
> This is my current list of call protocol requirements questions. Any
opinions?

I have the same opinion on the following questions:
> *Should it be reliable?
>  Would the transport layer provide this service?
> *Should it be congestion aware?
>  Would the transport layer provide this service?
> *Should it support keepalives?
>  Would the transport layer provide this service (SCTP, for instance)?

The protocol needs to be reliable.  That may include needing keep alive
packets.

The IAB will look rather poorly on any protocol that may adversely impact
the Internet.  A protocol that is not congestion aware would be a prime
candidate for rejection.

That said, I don't think the requirements document should state the
solution.  Clearly, TCP addresses all of the requirements.  However, there
may be other factors that makes TCP less than ideal.  Rather than put us in
a box today, we should just state the requirements, and on the next pass say
either "the protocol provides congestion control using the facilities of the
transport layer" or "the protocol provides congestion control using
protocol-specific facilities."

> *Should the protocol reuse current encryption methods? We assume yes.
Is it even possible to say no?

> *What about Failover requirements?

Hmm.  There was a lot of work done for MGCP and Megaco to build-in failover.
Two years later, it's still not complete.  I would offer that we say the
requirement for the protocol is that it allows for high availability
solutions.  For that matter, we could call out the Reliable Server Pooling
work.

> *Should it support capability negotiation?
>  For instance you just tell the intermediary that there are some callout
>  server available and it figures out by itself which
>  services each one provides, extensions, etc.

Discovery is infinitely better than configuration.

> *Should it be NAT friendly?
> *Should it work through firewalls?
>  Maybe in some situations the intermediary is also a middlebox.

If possible, but is it a requirement?

> *Should it be application agnostic?

How would it be application-specific?