Subject: [Sip] Followup: Pool on Update of outbound (retitled thread)

From: Dean Willis <[email-masked]>
Date: Thu, 15 Feb 2007 18:08:14 -0600

On Jan 8, 2007, at 6:22 AM, Christer Holmberg ((JO/LMF)) wrote:

>>
>> the mailing list needs to be the authority that determines
>> consensus, not the meeting that is attended only by those who
>> can afford it.
>
> Well, then we don't need any hums in the future, do we? :)

Of course we do. I find them very amusing and occasionally informative.

> Seriously, I do agree, but I (and I am sure others too) have received
> comments saying that "there was a concensus in this-or-that IETF
> meeting", without the issue really even being discussed on the mailing
> list. In some cases things have been discussed on the list, and have
> even got some support, but then being turned down at the meeting.
>
> So, does that mean that all decissions made at meetings should be  
> agreed
> also on the list after that?

That's why we report it as "a consensus in the meeting" rather than  
"a consensus". My default assumption is that strong consensus in a  
meeting is likely to represent rough list consensus. When there is  
doubt (raised by a participant, or on a hunch of a Chair), we need to  
ask the list.

That's why I polled. And I'm still digesting the results of that  
poll. I feel something like an anaconda that accidentally ate a full- 
grown water buffalo instead of a small pig -- that is, it's hard to  
digest the results, and I'm not sure what to do about the horns.

My personal belief is that this keepalive question is comingled with  
the UDP and large packet issue. If we fix the congestion-explosion  
problem of SIP large messages (it's not a reliability thing, it is a  
Breaks The Internet thing) by effectively deprecating UDP, then we  
don't really need most of STUN. If that's the direction, or might  
become the direction, then we probably shouldn't require STUN for  
TCP. But if we're going to keep a dual-protocol model forever (as  
Marc has argued for extending to where we can use UDP to kick-start  
TCP), then we might as well use STUN in both cases.

Some people (Frank? Juha? Me??) clearly believe that outbound is  
where we can draw the dividing line between a dual-protocol past and  
a TCP future.

Some (Cullen? Sean?) believe that we can't draw a dividing line using  
Outbound, but that we'll eventually cross that line.

Others (Marc) believe we cannot even approach such a transition at  
this time and that we need to heavily revise outbound to account for  
the perceived limitations of both TCP and UDP.

So, what do you people believe?

1) Do you believe that UDP transport of large messages will aggravate  
the congestion impact of SIP on the Internet (I personally do, just  
so you know my bias).

2) Will UDP fade away from SIP relatively soon?

3) If UDP will fade away, do we need to burden TCP-only  
implementations with a more complex keepalive protocol designed  
originally for UDP?

4) If UDP will fade away, do we need to account for UDP at all in  
outbound?

5) If UDP will NOT fade away relatively soon, and TCP will not scale  
relatively soon, then do you believe that we need a transition  
mechanism so that we can register and keepalive using UDP, then bring  
up short-lived TCP connections for large messages as Marc's draft  
proposes?

6) If you agree with #1 but think UDP will not fade away and don't  
see the need for #5, then I either want to know what sort of  
alternative you envision, because we're going to need one.

--
Dean

_______________________________________________
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: "Frank W. Miller" <[email-masked]>
Date: Thu, 15 Feb 2007 17:30:26 -0700

Inline...

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 5:08 PM
To: Christer Holmberg ((JO/LMF))
Cc: Cullen Jennings; SIP; Juha Heinanen; Rohan Mahy
Subject: [Sip] Followup: Pool on Update of outbound (retitled thread)

FM: My belief is that UDP cannot be deprecated in -outbound.  However, I
do believe that it is well past time to begin a SIP 3.0 version which
would be what you proposed earlier and that at that time we should
deprecate UDP for transport.

FM: I think this issue will go away once we drop UDP.  Its not clear to
me that the percentage of traffic on the Internet that is SIP even
warrants time thinking about this issue but like I said, it will never
come up again once we go to TCP.

FM: It will only fade quickly if its deprecated.  There is so much
implementation out there that makes use of UDP that will not go away
unless its forced to go away and deprecation will force that.

FM: No.

FM: We need to account for UDP in outbound because I don't think we can
deprecate UDP in outbound.  I'm just not sure that any of the solutions
that are in outbound are going to be universal enough to solve the
problem.  Where does that leave us?  I guess I think that outbound
should basically sketch potential solutions to the problem for UDP,
publish it then quickly deprecate the whole thing by doing 3.0 with TCP
only.

FM: Lets try to get UDP to fade quickly...

FM: If it were up to me (which thankfully its not), I would publish
outbound essentially unchanged as a BCP, the immediately begin work on
3.0.  I think 3.0 should scour 3261 under the assumption that we are TCP
only as its basic design tenet.

FM

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Feb 2007 18:56:10 -0600

The question is not "do we deprecate UDP in outbound". 

The question is do we define procedures for UDP and TCP in outbound. Or
just TCP.

You could still do UDP, but it may not work with outbound (if we choose
not
to support it).

There is no need to wait for a SIP 3.0 for that.

> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 16:30
> To: 'Dean Willis'; 'Christer Holmberg ((JO/LMF))'
> Cc: 'Cullen Jennings'; 'SIP'; 'Juha Heinanen'; 'Rohan Mahy'
> Subject: RE: [Sip] Followup: Pool on Update of outbound 
> (retitled thread)
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Feb 2007 19:01:37 -0600

Dean,

Why doesn't the device just detect if it's behind a NAT, using STUN or
whatever.

If it determines that it is behind a NAT, then it uses TCP and outbound.

The device is free to use UDP when not behind a NAT. 

PS: missing from your whole analysis is the fact that if you want to use
a secure
transport, then TLS/TCP or TLS/SCTP it is. Considering that we should
encourage
secure implementations, I find this obsession with optimizing our design
for the
non-secure transport rather bizarre.

> Sent: Thursday, February 15, 2007 16:08
> consensus, 
> >> not the meeting that is attended only by those who can afford it.
> >
> > agreed also on the list after that?
> 
> 
> That's why we report it as "a consensus in the meeting" 
> rather than "a consensus". My default assumption is that 
> strong consensus in a meeting is likely to represent rough 
> list consensus. When there is doubt (raised by a participant, 
> or on a hunch of a Chair), we need to ask the list.
> 
> That's why I polled. And I'm still digesting the results of 
> that poll. I feel something like an anaconda that 
> accidentally ate a full- grown water buffalo instead of a 
> small pig -- that is, it's hard to digest the results, and 
> I'm not sure what to do about the horns.
> 
> My personal belief is that this keepalive question is 
> comingled with the UDP and large packet issue. If we fix the 
> congestion-explosion problem of SIP large messages (it's not 
> a reliability thing, it is a Breaks The Internet thing) by 
> effectively deprecating UDP, then we don't really need most 
> of STUN. If that's the direction, or might become the 
> direction, then we probably shouldn't require STUN for TCP. 
> But if we're going to keep a dual-protocol model forever (as 
> Marc has argued for extending to where we can use UDP to 
> kick-start TCP), then we might as well use STUN in both cases.
> 
> Some people (Frank? Juha? Me??) clearly believe that outbound 
> is where we can draw the dividing line between a 
> dual-protocol past and a TCP future.
> 
> Some (Cullen? Sean?) believe that we can't draw a dividing 
> line using Outbound, but that we'll eventually cross that line.
> 
> Others (Marc) believe we cannot even approach such a 
> transition at this time and that we need to heavily revise 
> outbound to account for the perceived limitations of both TCP and UDP.
> 
> 1) Do you believe that UDP transport of large messages will 
> aggravate the congestion impact of SIP on the Internet (I 
> personally do, just so you know my bias).
> 
> implementations with a more complex keepalive protocol 
> designed originally for UDP?
> 
> 4) If UDP will fade away, do we need to account for UDP at 
> all in outbound?
> 
> 5) If UDP will NOT fade away relatively soon, and TCP will 
> not scale relatively soon, then do you believe that we need a 
> transition mechanism so that we can register and keepalive 
> using UDP, then bring up short-lived TCP connections for 
> large messages as Marc's draft proposes?
> 
> 6) If you agree with #1 but think UDP will not fade away and 
> don't see the need for #5, then I either want to know what 
> sort of alternative you envision, because we're going to need one.
> 
> --
> Dean
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Feb 2007 17:06:44 -0800

> non-secure transport rather bizarre.

We closed this last time by pointing out there is a draft and working  
implementations that do SIP over DTLS. The security issues is not at  
all coupled with the UDP/TCP issue.

Good to see we are going to get to repeat all this conversation.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Feb 2007 20:51:39 -0500

> You could still do UDP, but it may not work with outbound (if we choose

I agree with Francois here.

Providing outbound for TCP, and not for UDP, might be the incentive that 
some need to move to TCP.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 16 Feb 2007 11:12:38 +0200

> The device is free to use UDP when not behind a NAT. 

The problem is, as pointed out several times here, that you can't ever
*reliably* detect being behind a middlebox that breaks UDP. NATs are
only one type of such a box, firewalls generally are much worse because
you can't detect them simply by making a STUN binding request.

That said, this is a problem that only affects the UDP-only
implementations. The TCP-only implementations have a provable just-works
scheme to get around these problems.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Fri, 16 Feb 2007 11:24:38 +0200

ext Dean Willis wrote:
> the congestion impact of SIP on the Internet (I personally do, just so
> you know my bias).

Yes.

> 2) Will UDP fade away from SIP relatively soon?

Yes.

> 3) If UDP will fade away, do we need to burden TCP-only implementations
> with a more complex keepalive protocol designed originally for UDP?

Definitely not.

> 4) If UDP will fade away, do we need to account for UDP at all in outbound?

No, but I'm fine with text that Rohan proposed for outbound many moons
ago, basically saying that you can insist on using UDP, but all bets are
off as to whether or not it will actually work in the Internet.

> relatively soon, then do you believe that we need a transition mechanism
> so that we can register and keepalive using UDP, then bring up
> short-lived TCP connections for large messages as Marc's draft proposes?

Iff I thought those assumptions were actually reasonable (which I don't)
I'd probably say yes. But since I don't, I don't.

> 6) If you agree with #1 but think UDP will not fade away and don't see
> the need for #5, then I either want to know what sort of alternative you
> envision, because we're going to need one.

See answer for #4.

Cheers,
Aki

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 16 Feb 2007 01:46:33 -0800

Inline.

Dean Willis wrote:

[...]

>> My personal belief is that this keepalive question is comingled
>> with the
> UDP and large packet issue. If we fix the congestion-explosion

Yes

> 2) Will UDP fade away from SIP relatively soon?

No

> implementations with a more complex keepalive protocol designed

UDP will not fade away, but TCP-only implementations should use CRLF.
UDP+TCP implementations (there is no such thing as a SIP UDP-only
implementation) should support STUN and CRLF for TCP.

> 4) If UDP will fade away, do we need to account for UDP at all in

UDP will not fade away.

> up short-lived TCP connections for large messages as Marc's draft

Yes

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [ RFC1855-compliant space for rent]
Work: [email-masked]            [                                 ]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 16 Feb 2007 11:20:56 +0100

>(there is no such thing as a SIP UDP-only implementation)

What information do you base that statement upon?

Regards,

Christer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 16 Feb 2007 02:34:14 -0800

> What information do you base that statement upon?

RFC3261 Section 18  "All SIP elements MUST implement UDP and TCP."

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 16 Feb 2007 11:49:08 +0100

>RFC3261 Section 18  "All SIP elements MUST implement UDP and TCP."

I thought you talked about IMPLEMENTATIONS - not what the RFC says :)

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 16 Feb 2007 11:13:32 -0600

For what it's worth, here's my opinion. I think it's the only workable
solution/compromise. And we are almost there.
 
1 - Change the mechanism for TCP to be CRLF. Leave STUN for UDP as is.

Section 14 already has everthing required on the merits of TCP versus
UDP, and which are mandatory to implement and all that.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Feb 2007 10:14:22 -0800

On Feb 16, 2007, at 1:12 AM, Aki Niemi wrote:

> . The TCP-only implementations have a provable just-works

I've seen FWs that kill TCP connection after 10 minutes.

---

From: "Eric Cooper" <[email-masked]>
Date: Fri, 16 Feb 2007 13:23:39 -0500

Robert Spark's excellent report from SIP-it 19 indicated that 82% of implementations supported TCP.

At SIP-it 18, the number was 73%.

Best Regards,

Eric.
----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: "Marc Petit-Huguenin" <[email-masked]>; "Dean Willis" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "SIP" <[email-masked]>; "Juha Heinanen" <[email-masked]>; "Rohan Mahy" <[email-masked]>
Sent: Friday, February 16, 2007 5:20 AM
Subject: RE: [Sip] Followup: Pool on Update of outbound (retitled thread)

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Feb 2007 19:16:55 -0600

> The device is free to use UDP when not behind a NAT. 

Mostly works for me, but there are stateful firewall cases that won't be 
detected by STUN or whatever that would benefit from using outbound.

So my guidance is that if you support outbound and you're a UA 
registering with a proxy, USE OUTBOUND.

> non-secure transport rather bizarre.

DTLS. It has TLS security properties, but about the same large-datagram 
story as UDP.

--

Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Feb 2007 19:19:33 -0600

Cullen Jennings wrote:
> 
> On Feb 15, 2007, at 4:08 PM, Dean Willis wrote:
>> the need for #5, then I either want to know what sort of alternative 
>> you envision, because we're going to need one.
>>
>> -- 
>> Dean
> 
> Is that an email sent with your chair hat on ?

Yes, and I can't spell "Poll".

I want to know what people believe so I can get a feel for consensus.

I thought we were closing on one, and now I think it's slipping away, 
and I suspect there are good reasons it is slipping away.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Feb 2007 19:23:50 -0600

> RFC3261 Section 18  "All SIP elements MUST implement UDP and TCP."

You, sir, are an optimist. I admire that quality.

Unfortunately, I believe my current sponsor has shipped several million 
incomplete implementations of SIP.

--
Dean

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 19 Feb 2007 06:56:57 +0100

Hi,

When people indicate whether they believe/don't believe UDP will fade
away, I think it would be very important - especially if we in the most
extreme case are going to throw away UDP from SIP completely - that
people indicate WHY they think so.

At the UDP-will-not-fade-away camp I have seen one reply where "MARKET
SITUATION" is mentioned, and Dean indicated that his sponsor has shipped
large number of non-TCP implementations. Important input, I think.

For those who DO think that UDP will go away - what is that belief based
on? Market/deployment situation, theoretical problems that may occur, or
simply wishful thinking? :)

Someone also mentioned that, by defining SIP 3.0 and removing UDP,
people will be "forced" to switch from UDP to TCP. I don't think it
works exactly like that...

Regards,

Christer

> Sent: 17. helmikuuta 2007 3:20
> To: Cullen Jennings
> Cc: Christer Holmberg (JO/LMF); Juha Heinanen; SIP; Rohan Mahy
> Subject: Re: Followup: Pool on Update of outbound (retitled thread)
> 
> Cullen Jennings wrote:
> > 
> not scale 
> I thought we were closing on one, and now I think it's 
> slipping away, and I suspect there are good reasons it is 
> slipping away.
> 
> --
> Dean
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Feb 2007 12:50:34 -0800

I think Sean got to the heart of the problem very nicely.

On Feb 19, 2007, at 8:12 AM, Sean Olson wrote:

> If you changed the standard to remove UDP entirely, would UDP  
> implementations go away? No.
> If you changed the standard to remove TCP entirely, would TCP  
> implementations go away? No.
> Are there technical problems with UDP? Yes
> Are there technical problems with TCP? Yes
> Are there implementations that are UDP only? Yes
> Are there implementations that are TCP only? Yes
> Are there implementations that do both? Yes
>
> Odd discussion ... the market will always be somewhat independent  
> of standards if for no other reason than that implementations  
> generally lag standards and standards don't solve all possible  
> problems for all possible situations.
>
>
> From: Christer Holmberg (JO/LMF)  
> [mailto:[email-masked]]
> Sent: Sunday, February 18, 2007 9:57 PM
> To: Dean Willis; Cullen Jennings
> Cc: SIP; Rohan Mahy; Juha Heinanen
> Subject: [Sip] RE: Followup: Pool on Update of outbound (retitled  
> thread)
>
>
> Hi,
>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 20 Feb 2007 09:23:02 +0100

I don't think it is the fact that his sponsor has shipped large numbers
of terminals is the issue. The very fact that outbound uses option-tags
with a Require header means that a terminal that has not been upgraded
is not going to work in outbound - it will default to not using it. To
use outbound, existing terminals have to be upgraded.

I do accept that the cost of maintaining the future market may be
impacted, but that is not the same thing.

Keith 

> Sent: 19 February 2007 05:57
> Subject: [Sip] RE: Followup: Pool on Update of outbound 
> (retitled thread)
> 
> 
> Hi,
> 
> When people indicate whether they believe/don't believe UDP 
> will fade away, I think it would be very important - 
> especially if we in the most extreme case are going to throw 
> away UDP from SIP completely - that people indicate WHY they think so.
> 
> At the UDP-will-not-fade-away camp I have seen one reply 
> where "MARKET SITUATION" is mentioned, and Dean indicated 
> that his sponsor has shipped large number of non-TCP 
> implementations. Important input, I think.
> 
> For those who DO think that UDP will go away - what is that 
> belief based on? Market/deployment situation, theoretical 
> problems that may occur, or simply wishful thinking? :)
> 
> Someone also mentioned that, by defining SIP 3.0 and removing 
> UDP, people will be "forced" to switch from UDP to TCP. I 
> don't think it works exactly like that...
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> slipping away,

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 20 Feb 2007 08:09:41 -0800 (PST)

Both of you are on Mars.  This thread is about outbound.  The number of
implementations that will implement outbound using SIP over DTLS or over
SIP over TLS/SCTP is miniscule.  Anybody who implemented SIP over either
transport would have no problem doing SIP over TLS/TCP and by extension
SIP over TCP.

This issue is about burdening future TCP (and TLS over TCP)
implementations that do outbound with STUN keepalives or not.

thanks,
-rohan

---

From: Sean Olson <[email-masked]>
Date: Mon, 19 Feb 2007 08:12:40 -0800

If you changed the standard to remove UDP entirely, would UDP implementations go away? No.
If you changed the standard to remove TCP entirely, would TCP implementations go away? No.
Are there technical problems with UDP? Yes
Are there technical problems with TCP? Yes
Are there implementations that are UDP only? Yes
Are there implementations that are TCP only? Yes
Are there implementations that do both? Yes

Odd discussion ... the market will always be somewhat independent of standards if for no other reason than that implementations generally lag standards and standards don't solve all possible problems for all possible situations.

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
Sent: Sunday, February 18, 2007 9:57 PM
To: Dean Willis; Cullen Jennings
Cc: SIP; Rohan Mahy; Juha Heinanen
Subject: [Sip] RE: Followup: Pool on Update of outbound (retitled thread)

Hi,

Regards,

Christer

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 21 Feb 2007 15:11:06 -0700

Let me describe my opinion a little differently.  The reason that there
are implementations that use both UDP and TCP is because the standard
allows for it.  Indeed, one of the selling points of SIP early on was
that it was transport independent, i.e. you could pass SIP over any
transport you liked.

UDP was arguably the "first" transport.  What I mean is, most of the
initial work wrt transport was done based on it but always with the idea
that it was not exclusive.  TCP was given less coverage initially but
has become more important recently primarily (from what I've observed)
because it behaves "better" with NATs.  There have always been cursory
discussions about using something like SCTP but as has already been
noted, this transport is a tiny percentage of the overall usage out
there.

So, my point is this, I think that the need for transport independence
is really the heart of the issue here.  I think that a single transport
is fine and that TCP makes the most sense as that single transport.
Here are my reasons:

1) a single transport will improve interoperability
2) TCP as the single transport will traverse NATs more predictably that
UDP (and presumably SCTP although I'm not an expert in SCTP)
3) TCP as the single transport has the potential to simplify the SIP
protocol quite a bit, e.g. all the timer stuff is unnecessary
4) there are few (if any) deployment situations where UDP would work but
TCP would not

So, that said, a comment about the "standard" as a concept.  While I
agree with you that the market will use both for some period of time,
remember that the use of both is there now because the standard allowed
for it.  The standard defines what the implementations need to do.  If
the standard deprecates multiple transports, then the implementations
will follow, they have to otherwise they won't interoperate.

FM

-----Original Message-----
From: Sean Olson [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 9:13 AM
To: Christer Holmberg (JO/LMF); Dean Willis; Cullen Jennings
Cc: SIP; Rohan Mahy; Juha Heinanen
Subject: RE: [Sip] RE: Followup: Pool on Update of outbound (retitled
thread)

Odd discussion ... the market will always be somewhat independent of
standards if for no other reason than that implementations generally lag
standards and standards don't solve all possible problems for all
possible situations.

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
Sent: Sunday, February 18, 2007 9:57 PM
To: Dean Willis; Cullen Jennings
Cc: SIP; Rohan Mahy; Juha Heinanen
Subject: [Sip] RE: Followup: Pool on Update of outbound (retitled
thread)

Hi,

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Feb 2007 16:23:21 -0600

I'm staying mostly out of this conversation for now, but this point  
is potentially misleading and I want to make sure someone points it  
out quickly:

> protocol quite a bit, e.g. all the timer stuff is unnecessary

There is _some_ UDP specific timer behavior that you could remove if  
we somehow removed  all possibility of
non-reliable transports from the protocol (*cough*DTLS*cough*).

Not all timer behavior would go away. NITs  (and ACKs) would still  
time out. Proxies would still retain Timer C.
(If altering these behaviors are in the scope of this thread, you're  
_way_ outside the bounds of talking about
  fixing a transport congestion issue).

RjS

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 21 Feb 2007 15:30:35 -0700

Acknowledged, message transmissions only.
 
"All" is too strong.

FM

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Wednesday, February 21, 2007 3:23 PM
To: Frank W. Miller
Cc: 'Cullen Jennings'; 'Rohan Mahy'; 'SIP'; 'Sean Olson'; 'Christer
Holmberg (JO/LMF)'; 'Juha Heinanen'; 'Dean Willis'
Subject: Re: [Sip] RE: Followup: Pool on Update of outbound (retitled
thread)
 
I'm staying mostly out of this conversation for now, but this point is
potentially misleading and I want to make sure someone points it out
quickly:

 
There is _some_ UDP specific timer behavior that you could remove if we
somehow removed  all possibility of
non-reliable transports from the protocol (*cough*DTLS*cough*).
 
Not all timer behavior would go away. NITs  (and ACKs) would still time
out. Proxies would still retain Timer C.
(If altering these behaviors are in the scope of this thread, you're
_way_ outside the bounds of talking about
 fixing a transport congestion issue).
 
RjS

---

From: "William Mandra" <[email-masked]>
Date: Thu, 22 Feb 2007 12:04:37 -0500

For what it's worth, I think that in the context of the  Outbound draft
UDP should depreciated moving forward. A connection oriented protocol is
clearly the best choice for handling situations like NAT, and removing
the requirement for UDP in outbound would allow for a much simpler
keepalive mechanism. UDP will most likely not go away anytime soon for a
large portion of SIP implementations, and that's fine. In the context of
SIP/3.0 UDP should definitely continue to be supported. One of the
greatest strengths of SIP IS the fact that the implementation is
transport independent. Besides, does anyone on this list really think
that obsoleting UDP in v3 will have any effect on the actual number of
UDP only implementations?? The choice should be left to the designers of
individual implementations as to which transport(s) to support/not
support. I feel that it's more important in v3 to keep the specification
as open as possible and let the market decide which transport(s) best
suit their need, then in outbound draw a line and drop support for UDP.
1) Do you believe that UDP transport of large messages will aggravate
the congestion impact of SIP on the Internet (I personally do, just so
you know my bias).

Yes.

No.

Even though UDP most likely won't fade away from SIP anytime soon
doesn't mean that UDP must be supported in the context of outbound.

Same answer as #3 really... even though UDP won't fade away from SIP for
some time we should only use connection oriented transports for
outbound.

Nope... remove UDP from outbound all together, and while we're at it
remove the requirement for STUN with TCP and use either TCP keepalives,
CRLFs, or even whitespace for keep-alive.

Same as #5, connection based transports using either TCP keepalives,
CRLFs, or whitespace.

William Mandra
M-Networks

> Sent: Thursday, February 15, 2007 7:08 PM

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 22 Feb 2007 13:11:26 -0500

I think that William has done an excellent job of summarizing the
reality of the situation and what we should do about it.  

+1

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Feb 2007 11:31:22 -0800

On Feb 21, 2007, at 2:11 PM, Frank W. Miller wrote:

> TCP was given less coverage initially but
> because it behaves "better" with NATs.

Just as a bit of point of which works better .... if you and I are  
both behind NATs and we want to have SIP flow between us without  
using a relay outside our NATs, SIP over UDP works in a much higher  
percentage of NATs that TCP. This is a big topic for the P2PSIP  
group. But I think this actually does illustrate your point in some  
ways - different transports have different characteristics and SIP  
allows deployments to choose the transport that meets their needs.

Cullen <with my individual hat on>

---

From: Aki Niemi <[email-masked]>
Date: Tue, 27 Feb 2007 10:58:48 +0200

ext Cullen Jennings wrote:
> Just as a bit of point of which works better .... if you and I are both
> behind NATs and we want to have SIP flow between us without using a
> relay outside our NATs, SIP over UDP works in a much higher percentage
> of NATs that TCP. 

How you would be able to establish such a UDP flow without some
rendezvous point in the public Internet is also very interesting indeed.

> This is a big topic for the P2PSIP group. But I think
> this actually does illustrate your point in some ways - different
> transports have different characteristics and SIP allows deployments to
> choose the transport that meets their needs.

What you are basically saying is that since UDP works better in this P2P
scenario, application protocols should steer away from using TCP and
instead use UDP and then build the TCP state machine into the
application protocol itself. Why is it so hard to admit that this is
just a bad idea? Isn't it a clear layer violation as well?

Perhaps this is something that should really be solved for all protocols
and not specifically for SIP. This would actually be a good case for the
generality over efficiency principle.

Cheers,
Aki

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 27 Feb 2007 06:45:19 -0800

> rendezvous point in the public Internet is also very interesting indeed.

A rendezvous point must be used to find the destination, but after this
a direct "connection" can be used.

Here's an example:

 UA    NAT    Proxy          Proxy    NAT    UA
 |      :       |              |       :      |
 | INVITE       |              |       :      |
 |------------->| INVITE       |       :      |
 |      :       |------------->| INVITE:      |
 |      :       |              |------------->|
 |      :       |              |       :200 I |
 |      :       |        200 I |<-------------|
 |      : 200 I |<-------------|       :      |
 |<-------------|              |       :      |
 | ACK  :       |              |       :      |
 |------------------------------------------->|
 .      .       .              .       .      .
 .      .       .              .       .      .
 |      :       |              |       :  BYE |
 |<-------------------------------------------|
 | 200 B:       |              |       :      |
 |------------------------------------------->|
 |      :       |              |       :      |

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Feb 2007 08:20:03 -0800

On Feb 27, 2007, at 12:58 AM, Aki Niemi wrote:

>> both

agreed -  there would be something outside the NATs, but it would be  
involved in helping initiate the connection and would not need to be  
involved after the connection was formed

> generality over efficiency principle.

Aki, I did not mean to say that at all.  What I was saying is that  
the blanket claim that TCP works better through NATs and thus we  
should all use TCP is not 100% true. Some time TCP works better  
through NATs some times it does not.

I think that using TCP is a good idea in the SIP case - and, for me,  
the one strongest argument for why it is a good idea to use TCP is  
that: it is an efficiently and reliably way to transport large chunks  
of data - and SIP message are getting large. Many of the other  
arguments that get brought up I don't find as compelling.  
Specifically thought I feel their is some truth to all the following,  
for me they seem to have two sides or not be all that compelling.

1) SIP over TCP works better through nats - sometimes, sometimes not

2) SIP over TCP is easier to implement - they both have issues and  
they are a drop in the bucket of the overall complexity and work of  
doing a sip device

3) SIP over UDP causes congestion collapse - it does have an  
exponential backoff and the elephant under the rug is not the SIP but  
the fixed rate media

4) SIP over TCP is more scalable - in theory this is true, in  
practice as of today it is clearly not true given what is available  
for deployers to use. Again, I expect this to change over time but I  
think we are not there yet.

5) SIP over TCP is more reliable - various people have various high  
reliability schemes some work better with one protocol or the other -  
as the SIP wg defines ways to do high reliability, this may become  
less of an issue

As I said, I don't find the 1-5 really all that compelling on the UDP/ 
TCP debate one way or the other.  I'm a fan of moving towards TCP but  
not until it actually practical and I want us to move for the right  
reasons and not just the grass is greener on the other side. At the  
last few IETF, I've mumbled that if people are serious about this,  
writing a draft wold be the thing to do.

Cullen <with my individual hat pulled well down over my eyes>

PS - I do wonder at times about the the implications for mobile  
networks of encouraging large (like 10k) and very large  (like 100k)  
SIP messages.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Feb 2007 12:35:59 -0600

> As I said, I don't find the 1-5 really all that compelling on the  
> UDP/TCP debate one way or the other.  I'm a fan of moving towards  
> TCP but not until it actually practical and I want us to move for  
> the right reasons and not just the grass is greener on the other  
> side. At the last few IETF, I've mumbled that if people are serious  
> about this, writing a draft wold be the thing to do.
>

This touches a concern I have that's been growing throughout this  
thread.

There seems to be some subset of the discussion that is shaped more  
or less like
"If we can forbid SIP over UDP, all these bad things go away and the  
world is a much better place"
where it would be more appropriate to say
"If we can forbid SIP over UDP, these problems go away, and we'll  
have to focus more on these other problems now".

Deprecating SIP over UDP is not a magic-bullet/low-hanging-fruit/duh- 
why-didn't-we-do-this-years-ago proposition.
If it were, we _would_ have done it already (actually, the  
implementers would have done it for us and we'd be playing
catchup).

That said, I'll stand up next to Cullen here. I'm a fan of moving  
away from the current UDP state machines. I think there
_are_ the right reasons and we need to really understand them before  
pulling any rugs out from under anything.
I'm a fan of moving towards TCP because it's the most sensical option  
available to us.

Any transition we facilitate will have to be gradual if it's going to  
be meaningful.

RjS

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Feb 2007 18:31:42 -0600

I'd like to close on the few remaining issues in the To-Do list of
draft-ietf-sip-sips-01, as 
described in Annex B.

Most of the issues in Annex B are related to how to treat "derived
sessions" where there is a
missmatch between the URI scheme used by the different sessions.

For example, say a session started with SIPS, and then a REFER is sent
using a Refer-to URI that
points to a sip sheme. A similar issue could occur with third party call
control.

I am reluctant to write ultra precise procedures attempting to cover all
prossible problems that 
could happen on this issue, because it just seems that it would be too
complicated and arcane
to explain.

Rather, I would propose that I write some general guidelines on the
principle of not downgrading
security by allowing a derived session to effectively downgrade from
SIPS to SIP. And then, I'd add
an example or two of common cases.

For example, a REFER in a session using SIPS should not point to a
Refer-To that is SIP. The UAS 
that receives such a request should either
1) Warn the user about the downgrade and as for persmission to accept it
(similar to text alreay 
   in RFC 3515)
2) Reject it, probably with 403 "Forbidden".

Do people agree with this approach?
Suggestions?

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Feb 2007 18:51:20 -0600

> Do people agree with this approach?

HTTP certainly allows an HTTPS web page to redirect to or reference  
an HTTP page. There are lots of legitimate use cases.

But is is conventional for the browser to warn the user.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Feb 2007 20:09:19 -0500

Francois,

I agree as long as you get the wording right, which I think you are on 
track to do.

The fundamental thing is that a session to a UA never be downgraded 
*from what the user of the UA thought it to be* without the express 
permission of that user (directly or via configured policy.) Session 
here is a bit loose, since we are talking about replacing one dialog 
with another while thinking of it as a single session.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Feb 2007 09:54:06 -0600

inline

> Do people agree with this approach?

Yes, I think the general approach is the correct one.
The example is good, but as you're making it concrete, keep in mind
applications like directory services. (I might want my call to directory
assistance to be secured, but when the connect me to the party I'm
interested in, I would probably be willing to downgrade, especially
if they didn't offer secure communication - having me explicitly give
permission (by staying on the line after a verbal warning perhaps)
is reasonable to me.)

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Feb 2007 10:08:15 -0600

Ok, makes sense.

I think it will be consistent with some of the wording in the security section of RFC 3515.

----
François AUDET, Nortel Networks
mailto:[email-masked]

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Wed 28-Feb-07 7:54 AM
To: Audet, Francois (SC100:3055)
Cc: SIP
Subject: Re: [Sip] draft-ietfsip-sips Open Issues: Derived Sessions
 
inline