Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)]

From: William Marshall <[email-masked]>
Date: Fri, 7 Nov 2003 14:37:47 -0500 (EST)

Dean wrote:
> 
> Three possibilities suggest themselves, and I'd like to get a sense of
> consensus from the group on the direction (or other suggestions, if
> there are any).
> 
> 1) Leave the UDP stuff in place, but convince people not to use it by
> doing a "UDP Considered Harmful for SIP" BCP,  (which Scott seems to be
> suggesting). 
> 
> 2) Leave the UDP stuff in place, but give people tools to keep it from
> being used (which this draft suggests).
> 
> 3) Rev the spec to 3.0 and rip UDP out by the toenails.
> 
> Any other ideas? What is the right thing to do here?

I think there are really two cases here: case #1 between the UA
and its first proxy (where there is very little signaling traffic),
and case #2 between proxies (where there is lots more traffic).  

In case #1: one major problem is the impact TCP has on post-dial 
delay.  While it certainly can be fixed by a custom TCP stack in
the UA, this doesn't generally seem to be happening.  Lacking this, 
UDP is left as the preferred solution here.  Can such modified
parameters for TCP be suggested in a BCP?

In case #2: one problem is the impact TCP has due to head-of-line 
blocking.  This can be fixed with SCTP.  A BCP recommending this
would be good.

So it seems the best solution is a variation of #1, "UDP
Considered Harmful between SIP Proxies".

Another idea, not that I expect much traction.
If a protocol is to "ripped out by its toenails", how about TCP? 
It seems to be stuck in the middle, not perfect for either case.

Bill Marshall
[email-masked]

_______________________________________________
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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 7 Nov 2003 15:27:34 -0600

Bill said:
> I think there are really two cases here: case #1 between the 
> UA and its first proxy (where there is very little signaling 
> traffic), and case #2 between proxies (where there is lots 
> more traffic).  
> 
> delay.  While it certainly can be fixed by a custom TCP stack 
> in the UA, this doesn't generally seem to be happening.  
> Lacking this, 
> UDP is left as the preferred solution here.  Can such 
> modified parameters for TCP be suggested in a BCP?

Isn't this pretty much resolved by connection-reuse and a persistent TCP
connection between UA and proxy? This seems to be even sweeter if TLS is
also used.

> blocking.  This can be fixed with SCTP.  A BCP recommending 
> this would be good.

Good point. Would it be adequate to put this discussion into the SIP-SCTP
doc,

http://www.softarmor.com/wgdb/docs/draft-ietf-sip-sctp-03.txt

> It seems to be stuck in the middle, not perfect for either case.

There's also DCCP to consider.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 16:55:15 -0500

> http://www.softarmor.com/wgdb/docs/draft-ietf-sip-sctp-03.txt

Obligatory discussion reminder: From previous discussions, sometimes 
people assume that SCTP fixes head-of-line blocking if there is a slower 
downstream system for one session. It does not. There seem to be 
actually very few places in SIP-style systems where SCTP head-of-line 
blocking avoidance matters.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Nov 2003 15:56:56 -0600

> connection between UA and proxy? This seems to be even sweeter if TLS is

Problem is that the spec is vague on reusing TCP connections.
Rohan has an I-D on connection resue and I had presented one
at the Atlanta IETF that extended that paradigm to longer lived
connections (i.e. beyond the dialog).  Let me see -- the I-D is
still in the archives: 
http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-00.txt

If TCP becomes the dominant transport, the specification should
probably provide more direction on connection reuse and connection
longevity (especially with TLS in the picture).

Cheers,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216