Subject: RE: [Sip] draft-ietf-sip-outbound

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 27 Mar 2006 19:43:46 -0600

The biggest objection for PING was " To achieve comparable performance,
it doesn't look into the Proxy-Require tags ". This was looked by
purists as SIP like protocol. 

I saw on the outbound slides for the presentation on IETF site " With
PING it is infeasible to analyze all situations and check that no harm
is done. " What situations for sample were analyzed and it was not found
working. Can we have those findings posted on the list. I remember
seeing some emails before the meeting that people were not following the
complete thread and there was complete disconnect in performance aspects
itself.

I am listing the summary of the email exchanges earlier below 

1. With the modified proxies (PING Support), both approaches equally
work fine. PING doesn't have support for Require. The sole purpose of
PING is KEEP ALIVE, nothing else. Use OPTIONS for anything else with
Require. Purists disagree but there alternate solution has binary stuff
itself.

2. With MAX-FORWARDS trick, it should work with old proxies. This trick
forces old proxies not to look into the message details. It is needed
for *OLD PROXIES*.

3. The other objection was for Authrization. For the old proxies, Client
can resubmit the request with creditenials. 

Do we need authrization for KEEP ALIVE traffic ? STUN also has it. 

If you need PING to be authorized, Compare it with MESSAGE-INTEGRITY
option of STUN ?

This is trade off, what we want from new proxies between Speed and
Authrization . 

It is agreed that old proxies will not be able to process that fast, but
this hickup is with every new feature working with old stuff. E.g. when
you add a new option tag and put in Require header in a Request, it
requires extra trip all together with the proxies who don't support new
extension and you rollback to old stuff. 

4. Overload situation handling both are equally likely. SIP has 503
mechanism with some caveats. But there is nothing in STUN. Here PING has
slide benefit of reuse of SIP overload mechanism easily. We need to
address STUN overload separately in BEHAVE.

5. stun-keepalive flag advantage can be used for PING too with similar
ping-keepalive flag. 

Thx
Samir

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Monday, March 27, 2006 12:14 AM
To: [email-masked]; Drage, Keith (Keith)
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-outbound

Hi,

I was not at the face-to-face meeting, but from the mail discussion I
haven't seen a sign of consensus.

I think we should get the pros and cons of each solution documented, and
go from there. Maybe that study was done and discussed at the
face-to-face meeting, but then I would ask Keith (or someone else) to
share that study with the rest of us, so we can see what the facts the
consensus was made based on.

I am not saying that PING would be the best solution, but I do agree
with Frank that one solution does not necessarily preclude others.

Regards,

Christer

-----Original Message-----
From: Frank W. Miller [mailto:[email-masked]]
Sent: 25. maaliskuuta 2006 4:37
To: Drage, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Sip] draft-ietf-sip-outbound

On Sat, 2006-03-25 at 00:51 +0000, Drage, Keith (Keith) wrote:
> (as chair)
> 
> As a result of the face-to-face meeting held at IETF #65, we agreed in
the room on the keepalive mechanism:
> 
> -	OS TCP KeepAlive should be used if the client supports it.
> -	Need something more because OS TCP KeepAlive is not supported in
every client OS.
> -	Consensus to use STUN for UDP
> -	Consensus to use STUN for TCP, with use of OS TCP keep alive
above.

> 2)	Working group: Any dissent to the agreements listed above or do
we have rough consensus to proceed according to the agreements made in
the meeting

I have dissent on the use of STUN exclusively for keepalive.  I believe
that a SIP based mechanism such as the PING draft I proposed is a better
solution.  The essence of my objection is that I think it is a mistake
to have both STUN and SIP residing on the same port.  I think this makes
little sense for three reasons: 1) its architecturally in conflict with
the way most other protocols are defined, i.e. each protocol generally
lives on its own port, 2) it unnecessarily complicates implementations
when there is a very simple way to do it within SIP, and most
importantly 3) it is going to make it very difficult to use STUN for the
same task with other protocols that will need keepalives.  Also, I don't
believe that the performance issues that have been put forth are
substantive enough to cause the architectural violations that result
from using STUN this way.

If the group is dead set on using STUN this way, the SIP way should at
least be acknowledged by 1) including a ;keepalive=ping tag for the URI
in the outbound draft and 2) allowing the PING draft to become an ietf
draft.  These actions place very little additional burden on
implementors and will allow the "market" to decide which is the right
one to be used operationally.

Dissent registered.

FM

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip