Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 12:42:52 -0600

Dean,

Deployments don't need to support the Very Important Stuff you mention
below to see problems with UDP fragmentation across NATs. Just support
an event package with some honkin' XML sizes like presence, you'll see
it pretty quickly then.

I think the big problem in the UDP vs. TCP debate is that end customers
do not perceive the choice in transport protocol as being something that
provides them with significant value. Because of that, they don't push
their vendors to support it (as evidenced by the large amount of UDP
equipment running around out there) and the system engineering
requirements for TCP are viewed to be significantly different from UDP.

The reason I am pointing this out is because we're trying to fix the
problem by forcing people's hand's in the standard, which I believe is
ultimately going to fail. People will put in whatever they need to
continue to avoid the cost of developing proper TCP support until the
market demands TCP be supported (meaning that they can no longer avoid
the cost because they won't be able to deploy any equipment without it).

IMHO-- we should be flexible in this regard. Make sure that the UDP
behavior is at least minimally specified in the standard (warts and all)
and then work outside of standards with customers so that they fully
appreciate (and properly value) what they're getting with TCP that
they're not getting with UDP. At that point I think the whole debate
will resolve itself because the number of implementations wanting to use
UDP will drop.

Also, people should keep in mind that there are a panoply of access
network types out there. Some of them behave better with UDP than they
do with TCP because of the way the access network itself operates. If
you are thinking only in a CAT-5/6 world, there are other issues out
there that people may be up against that pushes them to use UDP. If I
have an access network that favors UDP in performance, and I know there
are no NATs between the client and the outbound proxy that have
fragmentation issues, it doesn't make sense to use TCP.

Regards,
Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Sunday, December 24, 2006 5:54 PM
> To: Cullen Jennings
> Cc: SIP; Audet, Francois (SC100:3055)
> Subject: Re: [Sip] Question about Poll: Proposal relating to 
> keepalive, TCP, and UDP usage in draft-ietf-sip-outbound
> 
> Cullen Jennings wrote:
> 
> > Hmm - I wish we had better specifics here - I will point out there  
> > are millions of endpoints on well known residential endpoints that  
> > are working through NATs and connected to PSTN gw and softwswiches  
> > that are working over UDP.
> ...
> > Could you point me at a non enterprise deployment that is not in  
> > point 2? I suspect there are some but the bulk seem to be form 2.
> 
> The problem is that none of those deployments are (yet) using 
> the boatload of features like identity, e2m, complex 
> route-header cookies, and other Very Important Stuff that we 
> think might be likely to happen. 
> But when that stuff starts to happen, UDP fragmentation will 
> start to occur. We don't yet know how much will break as a 
> result. But my guess is "a lot".
> 
> How about we rip out UDP, fix the Outbound stuff, fix the 
> route-construction stuff, fix the early-media stuff. and call 
> it SIP 3.0?
> 
> --
> 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
> 

_______________________________________________
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: [email-masked] (Juha Heinanen)
Date: Wed, 3 Jan 2007 20:49:12 +0200

> will resolve itself because the number of implementations wanting to use

i would think that the drop will be faster if there is no support for
UDP in outbound.

-- juha

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2007 15:06:56 -0600

As I said, there are networks where TCP is less efficient than UDP and
there are no NAT complications to be concerned about.

I don't think outbound is so fundamental to the operation of SIP as to
force people to change out their transport protocol to get the benefits.
There are other ways that people have been solving this problem without
the benefit of a standard. I doubt that dropping support for UDP is
likely to get them to move away from these mechanisms faster than if
they had support for outbound with UDP.

Regards,
Brian

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Wednesday, January 03, 2007 12:49 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; Cullen Jennings; SIP; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] Question about Poll: Proposal relating to 
>  > IMHO-- we should be flexible in this regard. Make sure 
> that the UDP  > behavior is at least minimally specified in 
> the standard (warts and all)  > and then work outside of 
> standards with customers so that they fully  > appreciate 
> (and properly value) what they're getting with TCP that  > 
> they're not getting with UDP. At that point I think the whole 
> debate  > will resolve itself because the number of 
> implementations wanting to use  > UDP will drop.
> 
> i would think that the drop will be faster if there is no 
> support for UDP in outbound.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 4 Jan 2007 07:27:07 +0200

> force people to change out their transport protocol to get the

i fully agree.  outbound doesn't give anything over what we have today.

 > they had support for outbound with UDP.

the reason to drop outbound support from udp is there are problems with
outbound and udp as has been described on this list.

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 Jan 2007 14:40:13 -0800

> i would think that the drop will be faster if there is no support for

I don't. The problem is not that UAs don't support TCP. The problems  
is that proxies don't support TCP on a large scale. Now we have had  
some posts that it is possible to build proxies with lots of TCP  
connections but if people want to encourage the move to TCP, I think  
the best thing they could do is help people understand how to build  
large scale TCP proxies.

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 5 Jan 2007 08:13:36 +0200

Cullen Jennings writes:

 > I don't. The problem is not that UAs don't support TCP. 

how can you from cisco say that the problem is not that UAs don't
support TCP, when UAs from cisco and its affiliates don't support TCP?

 > The problems is that proxies don't support TCP on a large scale. 

which popular proxies don't support TCP in large scale?  give me some
names.  if there are some, i'm sure their vendors must fix them, because
otherwise they would be out of business.

-- juha

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 10:38:18 +0200

Hi Brian,

Brian Stucker wrote:
>As I said, there are networks where TCP is less efficient than 
>UDP and there are no NAT complications to be concerned about.
>

Can you elaborate what kind of networks these typically are? Do you mean
that the networks are configured to prioritize UDP in some DiffServ'ish
manner, or some more fundamental issues with retransmissions etc. 

People often refer to TCP's inefficiency in the wireless access due to
non-congestion related packet loss. This can be an issue when
transfering large amounts of data. However, it is not relevant in case
of SIP/TCP where relatively short messages are sent back and forth. 

Markus

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 5 Jan 2007 13:29:27 +0100

> support for UDP in outbound.

That may also affect the deployment speed of outbound, and people will
continue to use whatever mechanisms they are currently using.

I pretty much agree with Brian. The market will decide what transport is
most suitable. By supporting both UDP and TCP outbound provides a
mechanism that works both today and tomorrow (when the SIP messages
become too big for UDP, and people realize they must switch to TCP in
order to get something to work).

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 5 Jan 2007 14:36:37 +0200

> continue to use whatever mechanisms they are currently using.

what is wrong with that as long existing mechanism work and don't
require any standardization?  is there some ietf religion here?

regarding tcp, outbound should not specify one single mandatory
mechanism for keepalives.  for example, if SIP UA support tcp
keepalives, it should be allowed to use them without sending any
application level data (stun or crlf).

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 5 Jan 2007 13:57:33 +0100

Hi, 

>>That may also affect the deployment speed of outbound, and people will
continue to use whatever mechanisms they are 
>>currently using.
require any standardization?  
>is there some ietf religion here?

Probably :)

But, the reason I like outbound is because I think it's a TECHNICALLY
good solution, and more flexible than many of the existing mechanisms.

>regarding tcp, outbound should not specify one single mandatory
mechanism for keepalives.  for example, if SIP UA 
>support tcp keepalives, it should be allowed to use them without
sending any application level data (stun or crlf).

Yes.

Regards,

Christer

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 05 Jan 2007 14:29:00 +0100

>otherwise they would be out of business.

Well, based on sipit observations it appears much easier to compile a short
list of those that do TCP in large scale. Solely based on what I'm aware
of sole presence of TCP is okay, 50k TCP connections is very good, 200k
is fantastic (and to some extent uncertain) and more than that is sci-fi.

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 5 Jan 2007 15:34:13 -0800

> support TCP, when UAs from cisco and its affiliates don't support TCP?

Cisco has many UAs that support TCP though you are right that not  
100% of them do.  Trust, me there are lots of things I wish Cisco SIP  
stuff did that it does not yet do but that is partially the time lag  
between standards and implementations and a little bit the nature of  
some of the specifications IETF writes do not seem to be particularly  
wanted by customers. (Insert S/MIME joke here :-)

> otherwise they would be out of business.

I has asked many times for a commercially available proxy that did  
over 100k TCP connections and high reliability (I include open source  
stuff as commercially available since a customer can use it). I have  
yet to receive a reply to that request. People have said it is  
possible to build them, and I believe those people, I'm just pointing  
out that if someone doing a vonage like service today does not seem  
to have many choices about if they are going to use UDP or not. Over  
time, I'm suspect that will change and I think it is critical that  
outbound does provide a TCP solution but I think it is also important  
that it provide a UDP solution for the people that want to use that  
today.

When you connect a counterpath or snom softphone behind a NAT to SER  
over TCP and incoming calls work, that is because they doing some of  
what outbound specifies. Something that strictly followed the  
existing RFC would try and form a new TCP connection and fail. I  
think it is important to get this finished and out there so more  
things can follow it and work too. I don't think there are long  
existing mechanisms that work and are optimal. Several proprietary  
solutions have been done and non optimal things like registering  
every 15 seconds have been done but clearly a standards based  
approach with a more optimal solution seems like a good idea.

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 6 Jan 2007 10:36:38 +0200

> approach with a more optimal solution seems like a good idea.

you simply write a one paragraph best practise rfc that says that in
case of tcp, it is good idea to use between ua and proxy a persistent
tcp connection that is refreshed every X minutes using crnl or tcp
keepalive.

-- juha

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 6 Jan 2007 11:59:19 +0100

> tcp connection that is refreshed every X minutes using crnl or tcp

Not sure that an UA that cannot receive initial SIP requests would be
very useful.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 6 Jan 2007 20:05:04 +0200

> Not sure that an UA that cannot receive initial SIP requests would be

are you saying that UA implementors are so brain damaged that they
cannot figure out to initiate a tcp connection without being told so by
ietf?

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Jan 2007 10:45:24 -0800

> cannot figure out to initiate a tcp connection without being told  

A large percentage of the TCP implementations observed at SIPIT  
formed a new TCP connection for every transaction and take down the  
connection at the end of the transaction - some, I kid you not,  
closed the TCP connection after sending the request but before  
receiving the response.

Now in fairness, most of these were, ah, implementations that had  
lots of other parts that needed improvement and not implementations  
that had been to lots of sipits and seen lots of testing but it did  
open my eye. The people that have these implementations always point  
out that they seem to be following the spec.  I don't think the specs  
have to be an full implementers guide so I'm not sure that this  
little story has much bearing on what we should be doing in the specs  
other than realize that people do implement some things that seem a  
little wacky at times. No matter what we say in the RFCs, there will  
always be people who manage not to understand them but it would be  
nice if the bulk of the people understood what they needed to do.

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 6 Jan 2007 21:21:11 +0200

Cullen Jennings writes:

 > No matter what we say in the RFCs, there will  

i agree that many implementors don't care about rfcs.  just an example
from this very week:

we noticed that a popular sip phone vendor didn't implement g726 as
specified in rfc3551.  the vendor did two mistakes: payload type was 2
and media packing was wrong.  

when i complained about it, vendor replied that they don't care about
the rfc, but rather follow cisco, who also has wrong implementation of
g726.  comforting was they would consider fixing their implementation if
i would order 20,000 phones from them.

coming back to tcp, if implementors don't think before they start
coding, ietf can produce a best practise document saying that it is a
good idea to initiate tcp connections and keep them open.  it is a pure
implementation issue, not a protocol one.

-- juha

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 6 Jan 2007 12:43:41 -0700

I suppose this question would be more appropriate for the sip-implementors
list, but, as someone who's about to add TCP to their implementation...

I was going to keep the connection alive during the course of a dialog for
sessions and subscriptions and for transactions for other things.  Do any of
you have any comment on your practical experiences with how best to maintain
the life of TCP connections?

Thanks,
FM

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Saturday, January 06, 2007 11:45 AM
To: Juha Heinanen
Cc: SIP; Marc Petit-Huguenin; Francois Audet; Brian Stucker; Dean Willis
Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive,
TCP,and UDP usage in draft-ietf-sip-outbound

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 6 Jan 2007 22:09:07 +0200

Frank W. Miller writes:

 > Do any of

sending crnl every ten minutes or so works fine.  if your tcp stack has
tcp keepalive support, you could try to use that although i don't have
practical experience about it.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 7 Jan 2007 15:31:05 +0100

Hi,

Since this issue is not outbound specific, I propose we start a separate
thread for it.

I believe I have also seen (and not only at SIPit) clients that
establish TCP connections per transaction.

But, even if you would establish the connection when the dialog is
established, and keep it open during the dialog, you still have the
question: are there cases/scenarios where the establishment of the TCP
connection takes too much time? Would the TCP connection have to be
established already prior to the establishment of the dialog?

If so, would it be useful to maintain the TCP connection during the
whole registration - also in non-outbound cases?

Regards,

Christer

> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: 6. tammikuuta 2007 21:44
> To: 'Cullen Jennings'; 'Juha Heinanen'
> Cc: 'SIP'; 'Marc Petit-Huguenin'; 'Francois Audet'; 'Dean 
> Willis'; 'Brian Stucker'
> keepalive, TCP,and UDP usage in draft-ietf-sip-outbound
> 
> 
> I suppose this question would be more appropriate for the 
> sip-implementors list, but, as someone who's about to add TCP 
> to their implementation...
> 
> I was going to keep the connection alive during the course of 
> a dialog for sessions and subscriptions and for transactions 
> for other things.  Do any of you have any comment on your 
> practical experiences with how best to maintain the life of 
> TCP connections?
> 
> Thanks,
> FM
> 
> 
> keepalive, TCP,and UDP usage in draft-ietf-sip-outbound
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 7 Jan 2007 23:42:42 +0800

Hi, Christer,

I had pinged Cullen for more details about the SIPit "TCP connections per 
transaction" experience, but since you followed up onlist, I will, too...

(1) Re: "the establishment of the TCP connection takes too much time" - the 
TCP handshake is three-way, so you're adding one RTT to the establishment of 
a dialog. How many RTTs are already required for DNS, etc. for a typical 
INVITE in your environment?

(2) More generally - the alternatives would be opening a new TCP connection 
per (a) message, (b) transaction, (c) dialog, or (d) registration, right?

I had observed to Cullen that SIP is normatively dependent on HTTP/1.1, and 
HTTP spent a LONG time coming up with a coherent transport story, even for 
the restricted case where NAT and FW traversal tended to be initiated 
unidirectionally (that story turned out to be, roughly, the clients leave 
connections open, up to some limited number of connections, and servers 
leave the connections open as long as it seems reasonable to do so - and a 
server might choose to close connections immediately). It's not surprising 
that we are seeing some server implementations use the same strategy for 
SIP. Apps programmers tend to ignore transport considerations until they 
recognize a problem.

Whatever the final guidance on connection lifetime turns out to be, SIP over 
TCP is likely to work better if we write it down fairly soon ... and I don't 
think more than an Informational document is needed.

Thanks,

Spencer

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

Hi,

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 7 Jan 2007 17:13:43 +0100

Hi, 

>I had pinged Cullen for more details about the SIPit "TCP 
>connections per transaction" experience, but since you 
>followed up onlist, I will, too...
> 
>(1) Re: "the establishment of the TCP connection takes too 
>much time" - the TCP handshake is three-way, so you're adding 
>one RTT to the establishment of a dialog. How many RTTs are 
>already required for DNS, etc. for a typical INVITE in your 
>environment?

If you can use the TCP connection to send the INVITE, there is no need
for DNS when sending the INVITE.
 
>(2) More generally - the alternatives would be opening a new 
>TCP connection per (a) message, (b) transaction, (c) dialog, 
>or (d) registration, right?

Yes.

>I had observed to Cullen that SIP is normatively dependent on 
>HTTP/1.1, and HTTP spent a LONG time coming up with a 
>coherent transport story, even for the restricted case where 
>NAT and FW traversal tended to be initiated unidirectionally 
>(that story turned out to be, roughly, the clients leave 
>connections open, up to some limited number of connections, 
>and servers leave the connections open as long as it seems 
>reasonable to do so - and a server might choose to close 
>connections immediately). It's not surprising that we are 
>seeing some server implementations use the same strategy for 
>SIP.

The difference is that SIP is often used for real-time type of
applications (a good old "phone call" is probably the best example :).
You don't mind if you have to wait a few seconds for your webpage to
open, but you do mind if it takes a long time to reach the remote party
when making a phone call (maybe there could even be regulatory
issues...).

Regards,

Christer

>Apps programmers tend to ignore transport considerations until they
recognize a problem.
> 
>Whatever the final guidance on connection lifetime turns out to be, SIP
over TCP is likely to work better if we write it 
>down fairly soon ... and I don't think more than an Informational
document is needed.

> Since this issue is not outbound specific, I propose we start 
> a separate thread for it.
> 
> I believe I have also seen (and not only at SIPit) clients 
> that establish TCP connections per transaction.
> 
> But, even if you would establish the connection when the 
> dialog is established, and keep it open during the dialog, 
> you still have the
> question: are there cases/scenarios where the establishment 
> of the TCP connection takes too much time? Would the TCP 
> connection have to be established already prior to the 
> establishment of the dialog?
> 
> If so, would it be useful to maintain the TCP connection 
> during the whole registration - also in non-outbound cases?
> 
> Regards,
> 
> Christer 
> 
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Jan 2007 00:34:15 +0800

Hi, Christer,

Sorry I wasn't clearer (beyond jet-lag, to a place I call "jet-stupid"). I 
wasn't thinking about the number of RTTs just from the UA's perspective, I 
was thinking about the total amount of stop-and-wait delays that happen 
while the INVITE is being processed.

There is an optimization path that says "this action takes so long that I 
want to shave every millisecond, no matter what problems that causes", but 
if we're talking about a rather slow action anyway, will anyone actually 
notice the milliseconds we save? Maybe yes, maybe not, but since 
optimizations have a cost, we need to understand the benefit associated with 
that cost.

And looking further down in your response, I wasn't clearer on another 
topic - I agree that the strategy you've seen at SIPits is questionable, I'm 
just saying that the people who used that strategy may be reusing it from 
another environment where it made more sense, without thinking about how SIP 
and HTTP/1.1 differ in their transport needs. I agree with your comment that 
this can be a problem because users think "real-time" means "real-soon".

Thanks,

Spencer

----- Original Message ----- 

Hi,

Yes.

Regards,

Christer

recognize a problem.
document is needed.

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 07 Jan 2007 17:18:28 +0100

At 16:42 07/01/2007, Spencer Dawkins wrote:
>Hi, Christer,
>
>I had pinged Cullen for more details about the SIPit "TCP connections per transaction" experience, but since you followed up onlist, I will, too...
>
>(1) Re: "the establishment of the TCP connection takes too much time" - the TCP handshake is three-way, so you're adding one RTT to the establishment of a dialog. How many RTTs are already required for DNS, etc. for a typical INVITE in your environment?

I dont think it really matters so much, because what I would call a reasonable
vanilla SIP implementation establishes TCP connection during registration. 
Sending/receiving an INVITE doesn't add up.

>(2) More generally - the alternatives would be opening a new TCP connection per (a) message, (b) transaction, (c) dialog, or (d) registration, right?

Yes, that's possible implementors' choices.
I think that if there is no bulk traffic then keeping number of connections equal to one
for as long as possible eliminates extra TCP setup times and confusion with multiple
connections (which one is associated with which contact...).

Possibly those who use SIP for bulk transport such as SIMPLE may be keen to have
parallel TCP connections to minimize blocking.

>I had observed to Cullen that SIP is normatively dependent on HTTP/1.1, and HTTP spent a LONG time coming up with a coherent transport story, even for the restricted case where NAT and FW traversal tended to be initiated unidirectionally (that story turned out to be, roughly, the clients leave connections open, up to some limited number of connections, and servers leave the connections open as long as it seems reasonable to do so - and a server might choose to close connections immediately). It's not surprising that we are seeing some server implementations use the same strategy for SIP. 

I'm not sure how good the HTTP parralle works sind we need inbound traffic too and connections
closed at proxy's discretion prohibit that. We do it too in SER when we run out of TCP connections.
Which leads to reasonable clients reregistering themselves to stay reachable and the problem shifts
to other clients. I think having reasonable client recommendations (behave?) which would
keep number of connections low (to avoid ambiguities and overloaded servers) is a safe thing
to do.

-jiri

>Apps programmers tend to ignore transport considerations until they recognize a problem.
>
>Whatever the final guidance on connection lifetime turns out to be, SIP over TCP is likely to work better if we write it down fairly soon ... and I don't think more than an Informational document is needed.
>
>Thanks,
>
>Spencer
>

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 07 Jan 2007 17:06:54 +0100

Keep it as long as you can until you don't shut the client down
(i.e., unregister).

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 07 Jan 2007 17:04:42 +0100

>implementation issue, not a protocol one.

which appears to me to be a behave application guidance bcp candidate.

give the client the responsibility for establishing transport connection,
keeping it alive (and reestablish session state if connection is gone), 
be symmetric.

-jiri

---

From: Michael Thomas <[email-masked]>
Date: Sun, 07 Jan 2007 08:54:46 -0800

From my perspective, any place you have a discussion about 
transport/TCP/UDP,
you should actually have a discussion about (D)TLS as if were always 
enabled.
That is the medium to even short term goal, IMO, so framing the overheads as
"just" the 3-way TCP handshake really misses the boat on how you strategize
for exchanges that are actually 10x more expensive (or more, fsvo 
"expensive").

       Mike

Spencer Dawkins wrote:
> Hi, Christer,
>
> I had pinged Cullen for more details about the SIPit "TCP connections 
> per transaction" experience, but since you followed up onlist, I will, 
> too...
>
> (1) Re: "the establishment of the TCP connection takes too much time" 
> - the TCP handshake is three-way, so you're adding one RTT to the 
> establishment of a dialog. How many RTTs are already required for DNS, 
> etc. for a typical INVITE in your environment?
>
> (2) More generally - the alternatives would be opening a new TCP 
> connection per (a) message, (b) transaction, (c) dialog, or (d) 
> registration, right?
>
> HTTP/1.1, and HTTP spent a LONG time coming up with a coherent 
> transport story, even for the restricted case where NAT and FW 
> traversal tended to be initiated unidirectionally (that story turned 
> out to be, roughly, the clients leave connections open, up to some 
> limited number of connections, and servers leave the connections open 
> as long as it seems reasonable to do so - and a server might choose to 
> close connections immediately). It's not surprising that we are seeing 
> some server implementations use the same strategy for SIP. Apps 
> programmers tend to ignore transport considerations until they 
> recognize a problem.
>
> Whatever the final guidance on connection lifetime turns out to be, 
> SIP over TCP is likely to work better if we write it down fairly soon 
> ... and I don't think more than an Informational document is needed.
>
> Thanks,
>
> Spencer
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Jan 2007 01:02:25 +0800

Hi, Michael,

> for exchanges that are actually 10x more expensive (or more, fsvo 

Agree, and thanks for the followup.

Spencer

p.s. Just for general background, I got sucked into the void of TCP vs UDP 
for wireless devices in the late 1990s, when the Wireless Application 
Protocol (WAP) people were totally freaked out about the way TCP seemed to 
work on GPRS links, etc. This was one of the hottest topics when the PILC 
TSV working group started up. They did a lot of work on WAP-specific 
alternatives to TCP, but when they did WAP 2.0, they ended up with a 
recommendation for "wireless profiled TCP" anyway - and the "wireless 
profile" from several years ago is now pretty much mainstream TCP. They were 
solving a different problem, so I'm not saying this will happen for SIP, I'm 
just saying that trying to shave milliseconds without looking at the entire 
picture - as Michael pointed out - "misses the boat".

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 7 Jan 2007 21:36:22 +0100

Hi,

So, then we need to identify the cost of having a "permanent" (alive
during the whole registration) TCP connection. We DO use it for
outbound, so...

Regards,

Christer  

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 7. tammikuuta 2007 18:34
> To: SIP
> Subject: Re: TCP connection establishment [was: RE: [Sip] 
> QuestionaboutPoll:Proposal relating to keepalive, TCP,and UDP 
> usage in draft-ietf-sip-outbound]
> 
> Hi, Christer,
> 
> Sorry I wasn't clearer (beyond jet-lag, to a place I call 
> "jet-stupid"). I wasn't thinking about the number of RTTs 
> just from the UA's perspective, I was thinking about the 
> total amount of stop-and-wait delays that happen while the 
> INVITE is being processed.
> 
> There is an optimization path that says "this action takes so 
> long that I want to shave every millisecond, no matter what 
> problems that causes", but if we're talking about a rather 
> slow action anyway, will anyone actually notice the 
> milliseconds we save? Maybe yes, maybe not, but since 
> optimizations have a cost, we need to understand the benefit 
> associated with that cost.
> 
> And looking further down in your response, I wasn't clearer 
> on another topic - I agree that the strategy you've seen at 
> SIPits is questionable, I'm just saying that the people who 
> used that strategy may be reusing it from another environment 
> where it made more sense, without thinking about how SIP and 
> HTTP/1.1 differ in their transport needs. I agree with your 
> comment that this can be a problem because users think 
> "real-time" means "real-soon".
> 
> Thanks,
> 
> Spencer
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Jan 2007 13:57:26 -0800

> whole registration - also in non-outbound cases?

Nothing to do with outbound but my 2 cents on this is a UA should try  
to keep the TCP connection open as long as the registration (that  
means forever in most cases or until the UA reboots or shutdown).  
Proxies should try and keep TCP connections open until they run out  
of resources then have some algorithm to determine which connections  
to kill to clear up resources.

I suspect most people will give you about the same answer.

Cullen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 07 Jan 2007 16:44:46 -0600

Christer Holmberg (JO/LMF) wrote:
> Since this issue is not outbound specific, I propose we start a
> separate thread for it.
> 
> establish TCP connections per transaction. [...]
> 

> ... and I don't think more than an Informational document is needed.

There is already a document that discusses TCP connection
maintenance (i.e., reuse) orthogonal to the outbound case.
The document is connect-reuse-07,
http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt,
although lately, it always seems to be hanging under the sword
of Damoclese.

The document itself is ready, has been implemented, and does
talk about the distilled wisdom in client and server TCP socket
management (see S8).  It is an aggregation from the original
work some of us did as a loose design team in TCP connection
guidelines([1], which has since expired and portions subsumed in
connect-reuse), and Rohan's connection alias draft, before outbound
came into the picture.

Please read it, and if this does not satisfy your requirements,
I would be more than glad to start a dialog to accommodate
them to an agreed consensus.  Given the regularity with which TCP
connection reuse gets asked on the list, it would be a shame
to jettison the current work on it.

[1] Vijay K. Gurbani, Chris Boulton, Rajnish Jain, and Cullen
Jennings,  "Guidelines for implementors using connection-oriented
transports in the Session Initiation Protocol (SIP)," IETF
Internet-Draft, February 2005, expired.  Available at
<http://croczilla.com/zap/rfcs/draft-gurbani-sipping-connection-guidelines-01.txt>

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Jan 2007 14:50:06 -0800

> when making a phone call (maybe there could even be regulatory

Irrelevant side comment but ... oddly, I am perfectly willing to wait  
2 seconds for a phone post dial delay but waiting even one second for  
my web page drives me insane.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 08:40:52 +0100

Hi, 

>Nothing to do with outbound but my 2 cents on this is a UA 
>should try to keep the TCP connection open as long as the 
>registration (that means forever in most cases or until the 
>UA reboots or shutdown).  
>Proxies should try and keep TCP connections open until they 
>run out of resources then have some algorithm to determine 
>which connections to kill to clear up resources.
> 

Yes, people may say that it is how things SHOULD work. But, from what I
hear from peoples SIPit experience etc some people seem to do things in
a different way. And, at the end what is implemented and deployed is
what really matters :)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 09:31:26 +0100

>2 seconds for a phone post dial delay but waiting even one 
>second for my web page drives me insane.

Most people on this list probably care more about the protocol itself
than the delays. But, the majority of people think the other way around,
I would assume :)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 09:50:16 +0100

Hi Vijay,

It's a good document, and I don't think the main issue is that we would
have to design something new. I think it's more about how people have
understood the specs and implemented things.

However, the draft does not talk about re-using registration TCP
connections. No, it may not forbid it either, but maybe it would be good
to add some text and/or example flows about that case also into chapter
4, together with the INVITE ones? Maybe also some text in chapter 8,
talking about keeping the connection alive during the whole registration
(and not only say that the connection should not be disconnected
together with the dialog) would be useful.

Regards,

Christer

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 8. tammikuuta 2007 0:45
> To: Christer Holmberg (JO/LMF); [email-masked]
> Cc: SIP
> Question about Poll: Proposal relating to keepalive, TCP, and 
> UDP usage in draft-ietf-sip-outbound]
> 
> although lately, it always seems to be hanging under the 
> sword of Damoclese.
> 
> talk about the distilled wisdom in client and server TCP 
> socket management (see S8).  It is an aggregation from the 
> original work some of us did as a loose design team in TCP 
> connection guidelines([1], which has since expired and 
> portions subsumed in connect-reuse), and Rohan's connection 
> alias draft, before outbound came into the picture.
> 
> Please read it, and if this does not satisfy your 
> requirements, I would be more than glad to start a dialog to 
> accommodate them to an agreed consensus.  Given the 
> regularity with which TCP connection reuse gets asked on the 
> list, it would be a shame to jettison the current work on it.
> 
> Jennings,  "Guidelines for implementors using 
> connection-oriented transports in the Session Initiation 
> Protocol (SIP)," IETF Internet-Draft, February 2005, expired. 
>  Available at

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 10:36:03 -0500

> connect-reuse), and Rohan's connection alias draft, before outbound

It hasn't always been clear in this thread what kinds of usage 
connection reuse that is assumed. I get the impression that some of the 
people talking in this thread think that sip-outbound is needless 
complexity and that connection reuse is enough, even in the presence of 
NATs.

The doc referenced above is quite clear that TCP connections can only be 
reused for *requests* by the end that established the connection - if 
requests are to flow in both directions then there must be a separate 
connection established in each direction. This is needed to prevent 
hijacking by bad guys. When a NAT is involved it won't be possible to 
establish a connection in the reverse direction.

For typical deployments it seems unlikely that connection-reuse will be 
sufficient.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 10:39:48 -0500

> together with the dialog) would be useful.

Are you suggesting that a *registration connection* can be used 
bidirectionally?

One of Rohan's versions of connection reuse attempted to piggyback on 
registration to authenticate the connection for use in the opposite 
direction. IIRC that what found to have a number of security holes and 
so was given up, in favor of using outbound for that.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 19:34:28 +0100

Hi Paul, 

>>It's a good document, and I don't think the main issue is that we 
>>would have to design something new. I think it's more about how people

>>have understood the specs and implemented things.
>> 
>>connections. No, it may not forbid it either, but maybe it would be 
>>good to add some text and/or example flows about that case also into 
>>chapter 4, together with the INVITE ones? Maybe also some text in 
>>chapter 8, talking about keeping the connection alive 
>>during the whole registration (and not only say that the connection
should not be 
>>disconnected together with the dialog) would be useful.
> 
bidirectionally?

That is one of the options presented earlier in the thread, yes.

That is how outbound works, and my understanding of Vijay's commant was
that connection-reuse can be used for that non-outbound cases.

If not, I missunderstood Vijay, or he missunderstood me :)

>One of Rohan's versions of connection reuse attempted to 
>piggyback on registration to authenticate the connection for 
>use in the opposite direction. IIRC that what found to have a 
>number of security holes and so was given up, in favor of 
>using outbound for that.

So, you are saying that connection-reuse can only be used to reuse
dialog initiated TCP connections, and that registration initiaded
connections are only used for registartion purpose?

Regards,

Christer

> >> Subject: Re: TCP connection establishment [was: RE: [Sip] Question 
> >> about Poll: Proposal relating to keepalive, TCP, and UDP usage in 
> >> draft-ietf-sip-outbound]
> >>
> during the 
> maintenance 
> >> (i.e., reuse) orthogonal to the outbound case.
> >> although lately, it always seems to be hanging under the sword of 
> >> Damoclese.
> >>
> >> The document itself is ready, has been implemented, and does talk 
> >> about the distilled wisdom in client and server TCP socket 
> management 
> >> (see S8).  It is an aggregation from the original work 
> some of us did 
> >> as a loose design team in TCP connection guidelines([1], which has 
> >> since expired and portions subsumed in connect-reuse), and Rohan's 
> >> connection alias draft, before outbound came into the picture.
> >>
> >> Please read it, and if this does not satisfy your requirements, I 
> >> would be more than glad to start a dialog to accommodate 
> them to an 
> >> agreed consensus.  Given the regularity with which TCP connection 
> >> reuse gets asked on the list, it would be a shame to jettison the 
> >> current work on it.
> >>
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 19:39:51 +0100

Hi, 

> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.tx
> > t, although lately, it always seems to be hanging under the 
> sword of 
> > Damoclese.
> > 
> > (see S8).  It is an aggregation from the original work some 
> of us did 
>It hasn't always been clear in this thread what kinds of 
>usage connection reuse that is assumed. I get the impression 
>that some of the people talking in this thread think that 
>sip-outbound is needless complexity and that connection reuse 
>is enough, even in the presence of NATs.

Well, if you use connection-reuse with TCP keepalive you will solve the
NAT issue, won't you (assuming the connection is bidirectional)? But,
you will not have the multiflow feature that outbound provides.

>The doc referenced above is quite clear that TCP connections 
>can only be reused for *requests* by the end that established 
>the connection - if requests are to flow in both directions 
>then there must be a separate connection established in each 
>direction.

I am not sure I understand. Isn't the re-use per direction
(unidirectional usage of a connection) already specified in RFC3261? The
connection-reuse drafts, as far as I understand (I'm sure Vijay can give
more details :) defines the bidirectional usage of a connection.

Regards,

Christer

 This is needed to prevent hijacking by bad guys. 
> When a NAT is involved it won't be possible to establish a 
> connection in the reverse direction.
> 
> For typical deployments it seems unlikely that 
> connection-reuse will be sufficient.
> 
> 	Paul
> 
> > would be more than glad to start a dialog to accommodate them to an

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 16:06:06 -0500

> If not, I missunderstood Vijay, or he missunderstood me :)

AFAIK the connection can be established any time and used for any 
requests send in the direction that the connection was established. It 
doesn't matter whether the first request is REGISTER, INVITE, or 
something else.

> connections are only used for registartion purpose?

No, I'm not saying anything about dialogs. I am saying that once you 
have established the connection in one direction you believe you know 
who you have connected to, and so can continue to use that for other 
requests to the same direction. But a server that accepts an incoming 
TCP connection cannot ascertain the source of that connection and so 
can't use it to originate requests in the opposite direction.

The situation is different for TLS. That is why the connection reuse 
draft specifies how/when a TLS connection can be used in the reverse 
direction.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 16:07:45 -0500

> you will not have the multiflow feature that outbound provides.

No you don't because the connection can't be used for requests in the 
reverse direction.

> more details :) defines the bidirectional usage of a connection.

I'm sure Vijay will chime in here, but it seems clear to me that it does 
not.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 8 Jan 2007 23:00:30 +0100

Hi Paul,

You are right. The connection-reuse bidirectionaltity is for TLS only. 

Vijay did only talk about TCP in his mail, though. Was that a misstake,
or did I missunderstand?

So, that means that you can re-use the registration connection
unidirectionally (and, in the end the INVITE sent from the client is the
critical one, as far a post dial delay is concerned) already using
RFC3261. So, again, it's not about defining/using new extensions - it's
about how to implement core SIP in a most effective way.

But, I still think the registraion clarifications I mentioned earlier
would be good for the connect-reuse draft.

Regards,

Christer 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 8. tammikuuta 2007 23:08
> To: Christer Holmberg (JO/LMF)
> Cc: Vijay K. Gurbani; [email-masked]; SIP
> >> connection reuse that is assumed. I get the impression 
> that some of 
> >> the people talking in this thread think that sip-outbound 
> is needless 
> >> complexity and that connection reuse is enough, even in 
> the presence 
> >> of NATs.
> > 
> > Well, if you use connection-reuse with TCP keepalive you will solve 
> > the NAT issue, won't you (assuming the connection is 
> bidirectional)? 
> > But, you will not have the multiflow feature that outbound provides.
> 
> No you don't because the connection can't be used for 
> requests in the reverse direction.
> 
> >> The doc referenced above is quite clear that TCP 
> connections can only 
> >> be reused for *requests* by the end that established the 
> connection - 
> >> if requests are to flow in both directions then there must be a 
> >> separate connection established in each direction.
> > 
> > (unidirectional usage of a connection) already specified in 
> RFC3261? 
> > The connection-reuse drafts, as far as I understand (I'm sure Vijay 
> > can give more details :) defines the bidirectional usage of 
> a connection.
> 
> I'm sure Vijay will chime in here, but it seems clear to me 
> that it does not.
> 
> 	Paul
> 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> <http://croczilla.com/zap/rfcs/draft-gurbani-sipping-connection-guide
> >> l
> >>> ines-01.txt>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> - vijay
> > 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Jan 2007 16:20:17 -0600

Paul Kyzivat wrote:
christer> I am not sure I understand. Isn't the re-use per direction
christer> (unidirectional usage of a connection) already specified in
christer> RFC3261? The connection-reuse drafts, as far as I understand
christer> (I'm sure Vijay can give more details :) defines the
christer> bidirectional usage of a connection.
> I'm sure Vijay will chime in here, but it seems clear to me that it does 

Sorry for the delayed response; yes, let me chime in here.

Connection-reuse defines the bidirectional usage of a connection
for the TLS transport only, not the TCP transport.  For TCP, it
is a connection-in-each direction because of the security
properties associated with the TCP transport when used in SIP
(so, you should not open up a TCP connection for REGISTER and
expect to receive requests in the backwards direction over it.)

Connect-reuse is NOT a replacement for outbound.  Outbound
addresses non-transitive trust in the form of NATs that
connect-reuse does not.  Outbound also addresses keeping
multiple flows open, which connect-reuse does not.

Basically, connect-reuse provides guidance to implementors
that fills in the blanks of what is left unsaid in rfc3261 --
whether a connection is open per transaction, per dialog,
or per whatever; connection lifetimes; mutual authentication
when using X.509 certificates; connection reuse across
virtual SIP servers; etc.  *That* is its value, IMHO.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Jan 2007 16:41:02 -0600

Christer: Our emails crossed.

Christer Holmberg (JO/LMF) wrote:
> So, again, it's not about defining/using new extensions - it's

Bingo!  That is what I said in my last email, namely

> would be good for the connect-reuse draft.

I'd be more than happy to work with you on clarifying any aspects
in the connect-reuse draft.  Your registrations clarifications from
a previous email were:

   However, the draft does not talk about re-using registration TCP
   connections. No, it may not forbid it either, but maybe it would be
   good to add some text and/or example flows about that case also
   into chapter 4, together with the INVITE ones? Maybe also some
   text in chapter 8, talking about keeping the connection alive
   during the whole registration (and not only say that the
   connection should not be disconnected together with the dialog)
   would be useful.

Based on this, it is clear that we cannot use the same TCP connection
which we used to register to receive incoming requests.  But,
the draft can and does provide guidance on when to reclaim the
connection (i.e., definitely not after the dialog is over.)

Is there anything else that I may have missed?

Thanks,

- vijay

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 9 Jan 2007 06:59:11 +0100

Hi Vijay, 

>I'd be more than happy to work with you on clarifying any 
>aspects in the connect-reuse draft.  Your registrations 
>clarifications from a previous email were:
> 
>Based on this, it is clear that we cannot use the same TCP 
>connection which we used to register to receive incoming 
>requests.  But, the draft can and does provide guidance on 
>when to reclaim the connection (i.e., definitely not after 
>the dialog is over.)
> 

In the text you copied from my previous mail, what if you replace TCP
with TLS?

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 9 Jan 2007 09:44:32 +0100

Hi Vijay, 

>Connection-reuse defines the bidirectional usage of a 
>connection for the TLS transport only, not the TCP transport. 
>For TCP, it is a connection-in-each direction because of the 
>security properties associated with the TCP transport when 
>used in SIP (so, you should not open up a TCP connection for 
>REGISTER and expect to receive requests in the backwards 
>direction over it.)
> 

I admit I haven't read version -07 of the draft in detail, but does it
talk about how to maintain the TCP connection, e.g. using TCP keepalive
or something similar? I can only find a statement saying that the
connection shall be open "for as long as the resources on the host
operating system allow it to".

>whether a connection is open per transaction, per dialog, or 
>per whatever; connection lifetimes; mutual authentication 

I agree. And, and that is what my proposal to add text/examples about
the registration connection was mainly about. It doesn't matter that the
connection is unidirectional.

Regards,

Christer

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 09 Jan 2007 08:55:49 -0600

Christer Holmberg (JO/LMF) wrote:
vkg>Is there anything else that I may have missed?
> In the text you copied from my previous mail, what if you replace TCP

Then, that would be fine; i.e., the connection established
during registration could be reused for requests coming into the
UA.  I can add this specific behavior for TLS in a new revision.

In another email in the same thread you wrote:

vkg> Connect-reuse is NOT a replacement for outbound.  Outbound
vkg> addresses non-transitive trust in the form of NATs that
vkg> connect-reuse does not.  Outbound also addresses keeping
vkg>multiple flows open, which connect-reuse does not.
> operating system allow it to".

Connect-reuse does not talk about the keepalive aspect at all.
Since it does not assume NAT presence, there is no reason that the
connection should be torn down, unless of course one of the hosts
crashes, or actively tears the connection down to reclaim resources.

vkg>Basically, connect-reuse provides guidance to implementors
vkg>that fills in the blanks of what is left unsaid in rfc3261 --
vkg>whether a connection is open per transaction, per dialog, or
vkg>per whatever; connection lifetimes; mutual authentication
vkg>when using X.509 certificates; connection reuse across
vkg>virtual SIP servers; etc.  *That* is its value, IMHO.
> connection is unidirectional.

OK; I will add the registration case for TLS transports.  That
should not be a problem.  Anything else?

Thanks,

- vijay

---

From: <[email-masked]>
Date: Tue, 9 Jan 2007 17:43:28 +0200

Hi,

On  05 January 2007, Jiri Kuthan wrote: 
>Well, based on sipit observations it appears much easier to 
>compile a short list of those that do TCP in large scale. 
>Solely based on what I'm aware of sole presence of TCP is 
>okay, 50k TCP connections is very good, 200k is fantastic (and 
>to some extent uncertain) and more than that is sci-fi.

these sound about right. But I'd say this is mostly due to lack 
of demand, rather than fundamental technical limitations of scaling 
TCP in SIP servers. Once we have more SIP clients with "persistent 
TCP" (i.e. TCP connections are kept alive as long as registration is 
active), or "full sip-outbound" support, there is some motivation to
improve
the TCP support in servers. And there are already quite a few of these
clients on the market. Of course, in today's access networks filled 
with stateful-firewalls-and-nats, without either "persistant TCP" or 
sip-outbound, TCP is only of limited use on the client-proxy hop (as 
the proxy won't have much success in initiating TCP connections towards
the clients).

I was involved in writing a paper concerning TCP scalability
in SIP servers (about to be published at ICN'07 [1], titled
"Scalability of TCP servers, handling persistent connections"),
and the results we got were mostly positive. We were able to hit 
100k simultanenous registrations with TCP with commodity PC hw 
and sw combo. All in all, scalability of TCP, although with some 
per-connection overhead, was nearly identical to UDP (both limited by
available CPU&memory, with linear growth of resource usage). And
further, 
the keepalive traffic had very little performance impact in terms of CPU

and memory bandwidth&usage (even if the heaviest possible method, i.e. 
full REGISTERs, was used for keepalives).

[1] http://www.iaria.org/conferences2007/ICN07.html

-- 
[email-masked] (Kai Vehmanen), Nokia Research Center

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 09 Jan 2007 19:41:30 +0100

At 16:43 09/01/2007, [email-masked] wrote:
>TCP in SIP servers. 

I would say both. At least for us, drilling OS kernel and dealing
with memory consumption was a laborous exercises. Nevertheless,
the demand as driven by existing implementations which are mostly
UDP-based has been indeed rather sporadic as of now.

>Once we have more SIP clients with "persistent 

indeed.

>the keepalive traffic had very little performance impact in terms of CPU

Was that impact on the overall performance (including database access,
processing user profile, etc.) or just stack throughput?

Thanks!

-jiri

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 9 Jan 2007 21:22:25 +0100

Hi, 

>during registration could be reused for requests coming into 
>the UA.

...and naturally for requests going out from the UA also.

>I can add this specific behavior for TLS in a new revision.

Good. And, again, maybe an example flow in chapter 4 would be good too.
 
>vkg>addresses non-transitive trust in the form of NATs that  
>vkg>connect-reuse does not.  Outbound also addresses keeping multiple 
>vkg>flows open, which connect-reuse does not.
> 
>I admit I haven't read version -07 of the draft in detail, 
>but does it talk about how to maintain the TCP connection, e.g. using
TCP 
>keepalive or something similar? I can only find a statement saying 
>that the connection shall be open "for as long as the resources on the 
>host operating system allow it to".
> 
>Since it does not assume NAT presence, there is no reason 
>that the connection should be torn down, unless of course one 
>of the hosts crashes, or actively tears the connection down 
>to reclaim resources.

Ok. I don't know TCP well enough. I was thinking about cases where the
connection is unused for long periods of time.

Also, IF the connection, for whatever reasons, goes down I think it
would be good to suggest that it shall be re-established. In the
registration connection case, would a re-REGISTER have to be sent also?

>vkg>Basically, connect-reuse provides guidance to implementors that 
>vkg>fills in the blanks of what is left unsaid in rfc3261 -- 
>whether a 
>vkg>connection is open per transaction, per dialog, or per whatever; 
>vkg>connection lifetimes; mutual authentication when using X.509 
>vkg>certificates; connection reuse across virtual SIP servers; etc.  
>vkg>*That* is its value, IMHO.
>> 
>>the registration connection was mainly about. It doesn't matter that 
>>the connection is unidirectional.
> 
>OK; I will add the registration case for TLS transports.  
>That should not be a problem.  Anything else?

I will look at the whole document more in detail later. For now I was
mostly focusing on the parts affecting this discussion, so... :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jan 2007 17:18:43 -0500

> registration connection case, would a re-REGISTER have to be sent also?

I'm not sure if you are discussing the TCP case or the TLS case here.

For the TCP case, where separate connections are used for each 
direction, there is no reason to reestablish a connection when it goes 
down, until it is needed for the same direction.

For TLS, the reason to do so would be if the connection can't be 
established in the other direction. But that is the outbound case. Since 
we aren't talking about that case here, and instead assume that a 
connection *can* be established in either direction, again there is no 
real reason to reestablish a connection at the time one goes down.

Early reestablishment of connections is instead likely to prevent the 
servers from dropping connections when they get too many.

	Paul

	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 10 Jan 2007 00:17:58 +0100

>connection is unused for long periods of time.

thats no problem, it can "sleep" as long as it stays alive.

>registration connection case, would a re-REGISTER have to be sent also?

I think this is more a behave agenda item than sip(ping). In any case,
an app which wishes to stay reachable should reconnect and re-REGISTER
too because the contacts valid for previous TCP connections have changed.

-jiri

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 10 Jan 2007 07:58:58 +0100

Hi, 

>>>I admit I haven't read version -07 of the draft in detail, but does 
>>>it talk about how to maintain the TCP connection, e.g. using
>>>TCP keepalive or something similar? I can only find a statement
saying 
>>>that the connection shall be open "for as long as the resources on 
>>>the host operating system allow it to".
>>>

>For the TCP case, where separate connections are used for 
>each direction, there is no reason to reestablish a 
>connection when it goes down, until it is needed for the same 
>direction.
> 
>For TLS, the reason to do so would be if the connection can't 
>be established in the other direction. But that is the 
>outbound case. Since we aren't talking about that case here, 
>and instead assume that a connection *can* be established in 
>either direction, again there is no real reason to 
>reestablish a connection at the time one goes down.
> 
>Early reestablishment of connections is instead likely to 
>prevent the servers from dropping connections when they get too many.

The idea behind reestablishing the connections is to avoid the post dial
delay of establishing the connection when an INVITE is to be sent.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 10 Jan 2007 12:00:39 +0100

>I think this is more a behave agenda item than sip(ping). In 
>any case, an app which wishes to stay reachable should 
>reconnect and re-REGISTER too because the contacts valid for 
>previous TCP connections have changed.

Correct.

The reason I think it's a sip(ping) issue is, again, due to the post
dial delay. Ie it has nothing to do with whether there is a NAT or not
in the network.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jan 2007 11:02:45 -0500

> delay of establishing the connection when an INVITE is to be sent.

For a UAC, there is typically a lot of extra time between the initiation 
and the completion of dialing, which can mask a lot of network delay. It 
has been suggested that ICE begin during this time. Establishing a TCP 
connection could also happen during this time.

But in any case the issue is largely irrelevant I think, because the use 
of TCP in this way only works if there are no NATs or FWs between the 
UAC and the proxy, which is likely not to be the case, or at least not 
known to be the case. Connection reuse is more relevant to connections 
between servers, with outbound being used for phones.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Jan 2007 11:46:25 -0600

Paul Kyzivat wrote:
> But in any case the issue is largely irrelevant I think, because the
> use of TCP in this way only works if there are no NATs or FWs between
> the UAC and the proxy, which is likely not to be the case, or at
> least not known to be the case.

This I do not understand -- maybe I am missing something.  It
is true that in many deployments, especially inter-domain
deployments, NATs and FWs will dominate, and thus outbound is the
only solution here.

However, it is also true that a lot of communication traffic
between a UAC and proxy will be intra-domain.  In such cases,
connect-reuse can help because all the communicating endpoints
are behind the same enterprise NAT.  Hence the assumption in
connect-reuse of transitive connectivity.

Outbound is the most general and the most expansive solution
since it includes multiple flows and keepalives, and Other
Nice Things (TM).

Connect-reuse simply attempts to fill in some of the blanks
of rfc3261.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Jan 2007 11:46:25 -0600

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Jan 2007 11:45:58 -0600

Christer Holmberg (JO/LMF) wrote:
vkg>Connect-reuse does not talk about the keepalive aspect at all.
vkg>Since it does not assume NAT presence, there is no reason
vkg>that the connection should be torn down, unless of course one
vkg>of the hosts crashes, or actively tears the connection down
vkg>to reclaim resources.
> connection is unused for long periods of time.

Certain shells (tcsh) and some versions of telnet may have an
inactivity timer that causes the session to be closed on the
absence of I/O for a certain time period.  However, this method of
timing out TCP connections is application specific and
presumably will not be used for SIP.

Assuming the application itself does not close the TCP session,
the session should stay up.  Look at ssh, for instance.
On Linux FC5, the ssh server sends out a keepalive probe
every 2 hours by default.  Assuming that the endpoints do not loose
TCP state through a crash or a connection termination, or that
your shell does not close the connection, the TCP session is kept
alive even if a router reboots in between that 2 hour window.

> registration connection case, would a re-REGISTER have to be sent also?

Probably; won't hurt except updating the registration.  The advantage
would be reducing delay in the session setup requests.

vkg>OK; I will add the registration case for TLS transports.
vkg>That should not be a problem.  Anything else?
> mostly focusing on the parts affecting this discussion, so... :)

OK; if you do get a chance, I'd appreciate a more detailed read-
through.

Thanks,

- vijay

_____im 4.43) id 1H4hWZ-0007fz-Kf
	for [email-masked]; Wed, 10 Jan 2007 12:46:07 -0500
Date: Wed, 10 Jan 2007 11:45:58 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: "Christer Holmberg (JO/LMF)" <[email-masked]>
Subject: Re: TCP connection establishment [was: RE: [Sip] Question about Poll:
	Proposal relating to keepalive, TCP,
	and UDP usage in draft-ietf-sip-outbound]
Cc: SIP LIST <[email-masked]>

Christer Holmberg (JO/LMF) wrote:
vkg>Connect-reuse does not talk about the keepalive aspect at all.
vkg>Since it does not assume NAT presence, there is no reason
vkg>that the connection should be torn down, unless of course one
vkg>of the hosts crashes, or actively tears the connection down
vkg>to reclaim resources.
> connection is unused for long periods of time.

Certain shells (tcsh) and some versions of telnet may have an
inactivity timer that causes the session to be closed on the
absence of I/O for a certain time period.  However, this method of
timing out TCP connections is application specific and
presumably will not be used for SIP.

Assuming the application itself does not close the TCP session,
the session should stay up.  Look at ssh, for instance.
On Linux FC5, the ssh server sends out a keepalive probe
every 2 hours by default.  Assuming that the endpoints do not loose
TCP state through a crash or a connection termination, or that
your shell does not close the connection, the TCP session is kept
alive even if a router reboots in between that 2 hour window.

> registration connection case, would a re-REGISTER have to be sent also?

Probably; won't hurt except updating the registration.  The advantage
would be reducing delay in the session setup requests.

vkg>OK; I will add the registration case for TLS transports.
vkg>That should not be a problem.  Anything else?
> mostly focusing on the parts affecting this discussion, so... :)

OK; if you do get a chance, I'd appreciate a more detailed read-
through.

Thanks,

- vijay

__________________________________________

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 11 Jan 2007 11:26:49 +0100

Hi, 

>>>direction, there is no reason to reestablish a connection when it 
>>>goes down, until it is needed for the same direction.
>>>
>>>established in the other direction. But that is the outbound case. 
>>>Since we aren't talking about that case here, and instead assume that

>>>a connection *can* be established in either direction, again there is

>>>no real reason to reestablish a connection at the time one goes down.
>>>

>>The idea behind reestablishing the connections is to avoid the post 
>>dial delay of establishing the connection when an INVITE is to be
sent.
> 
>For a UAC, there is typically a lot of extra time between the 
>initiation and the completion of dialing, which can mask a 
>lot of network delay. It has been suggested that ICE begin 
>during this time. Establishing a TCP connection could also 
>happen during this time.

You could have some speed-dial button which basically sends the INVITE
as soon as you press that button.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 11 Jan 2007 11:29:53 +0100

Hi,

Exactly, and that is what I have been talking about :)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 11 Jan 2007 12:00:44 +0100

Hi, 

>>The idea behind reestablishing the connections is to avoid the post
dial delay of establishing the connection when an INVITE is 
>>to be sent.
>But in any case the issue is largely irrelevant I think, 
>because the use of TCP in this way only works if there are no 
>NATs or FWs between the UAC and the proxy,

For TCP that is true, yes. 

But, for TLS, where you have a bidirectional connection, connection
reuse should work fine also with NATs or FWs. This of course assumes
that the UA keep the connection open all the time (and re-establishes it
when it for whatever reason fails), in order to allow inbound requests
to reach the UA.

So, in this case, if you can live without the multiflow feature outbound
provides I think connection reuse would work perfectly.

Regards,

Christer

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 13:37:42 +0200

Hello all,

On 09 Jan 2007,  Jiri Kuthan wrote:

>>these sound about right. But I'd say this is mostly due to lack of 
>>demand, rather than fundamental technical limitations of scaling TCP
in 
>>SIP servers.
>
>I would say both. At least for us, drilling OS kernel and 
>dealing with memory consumption was a laborous exercises. 

yes, it's definitely not a trivial task either. On the bright side, SIP
server implementors are not alone with this -- more and more
applications
have similar requirements - AJAX-style web services, email (especially 
the push variants), TLS-VPNs, etc, etc... all require more or less
persistent
TCP connections, and lots and lots of them. To implement the server end
for these services on a massive scale, one will face similar problems
than in scaling SIP servers which solely use TCP as the client-oproxy
transport.

And hey, having hundreds of thousands of clients sending keepalives
and some real traffic to a small set of UDP ports is not exactly 
a trivial problem either... solvable, but not trivial.

>>were mostly positive. We were able to hit 100k simultanenous 
>>registrations with TCP with commodity PC hw and sw combo. All in all, 
>>scalability of TCP, although with some per-connection overhead, was 
>>nearly identical to UDP (both limited by available CPU&memory, with 
>>linear growth of resource usage). And further, the keepalive traffic 
>>had very little performance impact in terms of CPU
>
>Was that impact on the overall performance (including database 
>access, processing user profile, etc.) or just stack throughput?

The tests were done with a dummy registrar database (the REGISTERs
were processed normally, updating the in-memory db, but not stored 
to a persistent database). This made sense, as we wanted to benchmark 
TCP-vs-UDP specifically, and the cost of database access is same 
for both.

---

From: Aki Niemi <[email-masked]>
Date: Thu, 11 Jan 2007 13:47:11 +0200

> connection could also happen during this time.

I think this is less and less the case. I expect most calls to be
initiated via a buddylist or phonebook type application, or even via
linked phone numbers in an email message. In those cases, there is no
delay between initiation and completion of the "dialing" since it's a
single action.

Personally, I can't remember the last time I actually dialed to make a
phone call -- even a CS one.

Cheers,
Aki

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 11 Jan 2007 12:49:22 +0100

>>initiation and the completion of dialing, which can mask a lot of 
>>network delay. It has been suggested that ICE begin during 
>>this time. 
>>Establishing a TCP connection could also happen during this time.
> 
>I think this is less and less the case. I expect most calls 
>to be initiated via a buddylist or phonebook type 
>application, or even via linked phone numbers in an email 
>message. In those cases, there is no delay between initiation 
>and completion of the "dialing" since it's a single action.

I agree.

>Personally, I can't remember the last time I actually dialed 
>to make a phone call -- even a CS one.

That's because finns never make any phone calls - we only send SMS :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2007 09:07:16 -0500

> provides I think connection reuse would work perfectly.

I thought this particular thread was about TCP, not TLS. The issues are 
quite different for the two. I think I agree that simply maintaining a 
TLS connection might be an alternative to outbound in some cases.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2007 09:05:10 -0500

> as soon as you press that button.

Yes, that is possible. This starts to get into the detailed design of 
the user interface of the device. In many, but not all, cases there is 
some UI clue that you are about to do something, which could be used by 
the device as a hint to start some of the housekeeping operations. For 
instance opening the phone.

Whether that will get better or worse as devices and UIs evolve is TBD.

As long as there is some work that needs to be hidden there will be an 
incentive to construct the UI so as to hide it. Keeping a connection all 
the time is an alternative if the costs of doing so are acceptable.

	Paul

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 17:28:49 +0200

Hi,

I agree with Aki. We are fooling ourselves if we think that the
potential delay problems with ICE or TCP connection setups etc. can be
cured with this kind of tricks. In general delays may not be an issue,
but in wireless access they can be. 

Markus 

>From: ext Aki Niemi [mailto:[email-masked]] 
>Sent: 11 January, 2007 13:47
>To: ext Paul Kyzivat
>Cc: SIP; Christer Holmberg (JO/LMF)
>Question aboutPoll: Proposal relating to keepalive, TCP, and 
>UDP usage indraft-ietf-sip-outbound]
>
>I think this is less and less the case. I expect most calls to 
>be initiated via a buddylist or phonebook type application, or 
>even via linked phone numbers in an email message. In those 
>cases, there is no delay between initiation and completion of 
>the "dialing" since it's a single action.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2007 12:38:51 -0500

I'm not objecting to establishing connections early, especially if doing 
so is needed to establish connectivity in the reverse direction. But 
when the connection is not required to establish connectivity in the 
reverse direction, and a connection has been dropped by the far end, 
then insisting on reestablishing it directly can be counterproductive to 
a server that has more connections than it can handle. So, if you have 
had your connection dropped, and you don't need it right now, I still 
think it would be best to wait until you do need it before attempting to 
reestablish it.

	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 11 Jan 2007 18:47:54 +0100

That's true but is that the mainstream case? I'm under impression that mostly
clients register to be able to get SIP traffic back. Server overload has to
be then handled on server side. Clients unreachable because overloaded
server are same unpleasent as clients unreachable because of disconnected TCP
connections.

-jiri

At 18:38 11/01/2007, Paul Kyzivat wrote:
>I'm not objecting to establishing connections early, especially if doing so is needed to establish connectivity in the reverse direction. But when the connection is not required to establish connectivity in the reverse direction, and a connection has been dropped by the far end, then insisting on reestablishing it directly can be counterproductive to a server that has more connections than it can handle. So, if you have had your connection dropped, and you don't need it right now, I still think it would be best to wait until you do need it before attempting to reestablish it.
>
>        Paul
>
>>>From: ext Aki Niemi [mailto:[email-masked]] Sent: 11 January, 2007 13:47
>>>To: ext Paul Kyzivat
>>>Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound]
>>>
>>>>For a UAC, there is typically a lot of extra time between the initiation and the completion of dialing, which can mask a lot of network delay. It has been suggested that ICE begin during 
>>>this time. 
>>>I think this is less and less the case. I expect most calls to be initiated via a buddylist or phonebook type application, or even via linked phone numbers in an email message. In those cases, there is no delay between initiation and completion of the "dialing" since it's a single action.
>>>
>>>Personally, I can't remember the last time I actually dialed to make a phone call -- even a CS one.
>>>
>>>Cheers,
>>>Aki
>>>
>>>
>>>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: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jan 2007 14:02:42 -0500

> server are same unpleasent as clients unreachable because of disconnected TCP

If the server cannot establish a connection to the client, but the 
client can establish a TLS connection with mutual authentication, then 
that could qualify the client as *needing* a connection. I'm talking 
about other cases. In particular, if we are talking about TCP rather 
than TLS, then the client establishing a TCP connection doesn't 
establish a reverse path, unless outbound is used.

You can register with a server in order to receive outbound calls 
without maintaining a connection, as long as the server can establish a 
connection when it is needed.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 12 Jan 2007 08:09:06 +0100

Hi,

>I'm not objecting to establishing connections early, 
>especially if doing so is needed to establish connectivity in 
>the reverse direction. 

I think we all agree on that.

>But when the connection is not 
>required to establish connectivity in the reverse direction, 
>and a connection has been dropped by the far end, then 
>insisting on reestablishing it directly can be 
>counterproductive to a server that has more connections than 
>it can handle. So, if you have had your connection dropped, 
>and you don't need it right now, I still think it would be 
>best to wait until you do need it before attempting to reestablish it.

We don't need to mandate the connection to be re-established. But, I
think it would be good to document it as an option, and say what the
advantages of doing so would be.

Regards,

Christer

> >> aboutPoll: Proposal relating to keepalive, TCP, and UDP usage 
> >> indraft-ietf-sip-outbound]
> >>
> >> Personally, I can't remember the last time I actually 
> dialed to make 
> >> a phone call -- even a CS one.
> >>
> >> Cheers,
> >> Aki
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jan 2007 13:05:47 -0500

> advantages of doing so would be.

What should a server do that has more connections than it can manage? 
Presumably it must disconnect some of them, or refuse new ones. The 
advantage of disconnecting old ones is that it can choose those that 
have not been used for a long time. When rejecting new ones, there is no 
good way to distinguish those that are being established because they 
are needed right now for a call, and those that are being established 
"just in case". Things will be worse for those that really need a 
connection if those that don't attempt to make a connection anyway after 
having been rejected.

So, I think it would in fact be better to mandate that an attempt to 
reestablish a connection *not* be attempted immediately after a 
disconnect if it is not needed at that time.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 12 Jan 2007 12:58:45 -0600

Paul Kyzivat wrote:
> have not been used for a long time.

That is one strategy that can be used, yes.

> When rejecting new ones, there is no good way to distinguish those
> that are being established because they are needed right now for a
> call, and those that are being established "just in case". Things
> will be worse for those that really need a connection if those that
> don't attempt to make a connection anyway after having been rejected.

And here is where judicial use of policies comes into the picture.
Presumably, an implementation can save a certain number of sockets
for calls that are identified as emergency in nature -- those
having the SOS URI, for instance.  These calls will always get
through, no matter what.

An implementation can have a high watermark for simultaneous
TCP connections.  This high watermark will exclude the reserved
set, which allows SOS type of calls to come in.  We have had some
success using this technique.

> disconnect if it is not needed at that time.

We could always normatively specify it with a SHOULD
strength (and explain why).  Then your concern would be allayed,
and if an implementation still wanted to do pre-emptively open
a connection, it would have presumably weighed in the pros and
cons and decided accordingly.

Thanks.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jan 2007 16:34:15 -0500

Vijay,

I'm not trying to distinguish between those making emergency calls, and 
those making regular calls. I'm trying to distinguish between those 
establishing a connection because they want to make a call *now* from 
those that are establishing a connection in order to minimize the call 
setup delay *later* if/when a call attempt is made.

Suppose a server can support 1000 connections, and devices connect as 
soon as turned on, and attempt to reconnect whenever their connection is 
dropped. Then when the device 1001 attempts to connect, the server will 
have to drop somebody - perhaps the one whose connection as been idle 
for the longest. But that device will immediately try to reconnect, 
forcing another device to be disconnected. This will continue 
indefinitely. Doesn't seem like a very good strategy.

Now, take a different approach: devices only connect when they *need* 
the connection (e.g. to make a call). Once connected, they stay 
connected until shut down or until the server disconnects them. There 
will be no problem at all until there are 1000 devices that have made a 
call. When another device needs to make a call it will attempt to 
connect, forcing one of the others - that hasn't used the connection 
recently - to be disconnected. That will cause no other actions until 
that device needs to send another message. There won't be a significant 
problem until there are 1000 devices with active calls. Even then, given 
that signaling usually happens at the beginning and end of calls, with a 
long period in between with no signaling, a lot more than 1000 devices 
can probably be supported with little difficulty.

Of course outbound does breakdown as soon as the number of devices 
exceeds the number of supported simultaneous connections. That might be 
a significant discriminator for deployment choices.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 13 Jan 2007 14:38:20 +0100

Hi, 

>>>I'm not objecting to establishing connections early, especially if 
>>>doing so is needed to establish connectivity in the reverse 
>>>direction.
>> 
>>>required to establish connectivity in the reverse direction, and a 
>>>connection has been dropped by the far end, then insisting on 
>>>reestablishing it directly can be counterproductive to a 
>>>server that has more connections than it can handle. So, if you have
had your 
>>>connection dropped, and you don't need it right now, I still think it

>>>would be best to wait until you do need it before attempting to 
>>>reestablish it.
>> 
>>think it would be good to document it as an option, and say 
>>what the advantages of doing so would be.
> 

Whatever it would do in the bi-directional connection case, when the
connection needs to be re-established in order for the client to receive
inbound requests...

>Presumably it must disconnect some of them, or refuse new 
>ones. The advantage of disconnecting old ones is that it can 
>choose those that have not been used for a long time. When 
>rejecting new ones, there is no good way to distinguish those 
>that are being established because they are needed right now 
>for a call, and those that are being established "just in 
>case".
>
>Things will be worse for those that really need a 
>connection if those that don't attempt to make a connection 
>anyway after having been rejected.
> 
>So, I think it would in fact be better to mandate that an 
>attempt to reestablish a connection *not* be attempted 
>immediately after a disconnect if it is not needed at that time.

I don't agree on that. We can describe the pros and cons of each option,
but we should allow both. An operator may have designed his network in a
way that each proxy can support enough number of connections, and in
that case terminals should not be forbidden to have re-estblish those
connections.

Regards,

Christer

---

From: "Kai Vehmanen" <[email-masked]>
Date: Mon, 15 Jan 2007 20:48:31 +0200

Hello,

On 11 Jan 2007, Paul Kyzivat wrote:
>If the server cannot establish a connection to the client, but 
>the client can establish a TLS connection with mutual 
>authentication, then that could qualify the client as 
>*needing* a connection. I'm talking about other cases. In 
>particular, if we are talking about TCP rather than TLS, then 
>the client establishing a TCP connection doesn't establish a 
>reverse path, unless outbound is used.

well, it's worth noting that in many real-life deployments the
TCP registration does establish a reverse path (even though
no IETF documents specify this yet -- waiting for sip-outbound).
Just look at iptel.org SER for example ("tcp_alias" settings, 
other implementations use "persistent TCP", etc, etc).

These ain't pretty, that's for sure, but allow to use TCP as the
transport with some of the already existing clients.

>You can register with a server in order to receive outbound 
>calls without maintaining a connection, as long as the server 
>can establish a connection when it is needed.

But how can a client possibly know which is the case? With
NATs on path, this is still doable, but with stateful firewalls, neither
the client nor the server can possibly know whether TCP 
connections can be established towards the client. Deciding-by-trial is way 
too slow as the FWs can drop packets silently, and the default 
timeouts are long. So except in cases where the access network 
characteristics are known, client will have to assume that _it_, the client,

is the party responsible for initiating connections.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 15 Jan 2007 16:01:40 -0600

> indefinitely. Doesn't seem like a very good strategy.

Paul: Yes, you are right.  I had forgotten about that insidious
side-effect.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 15 Jan 2007 16:03:11 -0600

> other implementations use "persistent TCP", etc, etc).

This leaves you open to the sort of attack described in
S9.3 of connect-reuse
(http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt).

Thanks,

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 16 Jan 2007 14:53:32 +0100

>is the party responsible for initiating connections.

Absolutely. In addition to the client-server-oriented NAT/firewall friendliness,
one can argue even more generally using e2e principiles or Murphy laws:
network can always fail somehow and the more robust approach for the client is
just to rely on itself.

-jiri

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 16 Jan 2007 07:25:49 -0800

> network can always fail somehow and the more robust approach for the 
> client is just to rely on itself

This is an excellent reformulation of the e2e principle. 

Besides failures, it applies even more to security. 
We can't risk our life to depend on unknown intermediaries.
This is the motivation for ZRTP among other.

Thanks, Henry

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 7:54 AM
To: Kai Vehmanen; 'ext Paul Kyzivat'
Cc: [email-masked]; Isomaki Markus (Nokia-SIR/Espoo); Niemi Aki
(Nokia-NRC/Helsinki); [email-masked]
Subject: [Sip] RE: TCP connection establishment

>is the party responsible for initiating connections.

Absolutely. In addition to the client-server-oriented NAT/firewall
friendliness,
one can argue even more generally using e2e principiles or Murphy laws:
network can always fail somehow and the more robust approach for the
client is
just to rely on itself.

-jiri

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 10:47:55 -0500

Sean Olson wrote:
> Wow.... that's one option, but certainly not the only one. <sarcasm>This is where I like to introduce multiple servers</sarcasm>

Sean - I'm not sure exactly which point you are trying to make.

Certainly one option is to attempt to over configure the system so that 
there is enough capacity to accept every connection attempt. In certain 
closed environments that may be workable. But it is certainly not a 
solution for all environments.

Presumably every deployment will have *some* limit. This limit could be 
reached in normal operation if the operators don't have control over the 
number of clients attempting to connect. That limit can support more 
devices if they don't attempt to keep the connection up all the time 
than it can if they do.

The limit can also be reached as a result of devices that malfunction, 
or because of a DOS attack. The impact of that may also be worth some 
consideration.

	Paul

> Sent: Monday, January 15, 2007 2:02 PM
> To: Paul Kyzivat
> Cc: SIP LIST

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 11:01:47 -0500

comment at end.

> network can always fail somehow and the more robust approach for the client is

What point are you making? Vijay responded as I would have - the single 
TCP connection has major security concerns if used bidirectionally. You 
should only use TCP if you know you don't have NAT/FW issues, so that a 
separate TCP connection can be made in the other direction.

Otherwise, if you have your own cert you can use TLS and avoid the need 
for connection establishment in the reverse direction, or else you can 
use outbound.

Practically speaking, a UA will typically not have a cert, and will need 
to use outbound. Connection reuse, via TCP or TLS, will typically only 
be useful between proxies.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 11:14:15 -0500

Sean Olson wrote:
> My main point is that dropping prior connections to accept a new connection is one possible policy, but hopefully not a commonly implemented one. Every deployment will have some limit. Very few deployments have absolutely no idea what their expected use will be though. Proper provisioning based on intended usage and empirical evidence is a reasonable assumption. There are other queuing/blocking techniques that can help with overload situations. DoS attacks in particular should not be responded to by dropping existing connections in order to feed the attack.

I certainly agree in the DOS case. And I am not knowledgeable in this 
area, so will defer to somebody that is. But at some point one must 
either drop an existing connection or reject a connection request. It 
seems pretty unfair if you end up rejecting connection requests that 
might be important in order to preserve a connection that hasn't been 
used in hours, days, or more.

Unfortunately, what the connection request arrives there is generally no 
good way to tell how important it is. You might be able to decide based 
on what it does after you accept the connection. But that is too late.

As I say, I am no expert here, so I will be happy if somebody can 
specify how this can be handled reasonably if every prospective client 
continually attempts to connect.

	Paul

> Sent: Tuesday, January 16, 2007 7:48 AM
> To: Sean Olson
> Cc: Vijay K. Gurbani; SIP LIST

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 Jan 2007 11:45:22 -0500

This isn't like provisioning a telephone trunk group (circuit group, in 
European terminology), where you know each trunk will eventually be 
freed when the call is complete. In the present case, you either provide 
for every client to be connected or you need a disconnect policy. What I 
suggest is a policy of disconnecting after some period of non-use, 
rather than in response to incoming calls. That prevents "feeding a DOS 
attack".

Paul Kyzivat wrote:
> 
> 
> Sean Olson wrote:
>> My main point is that dropping prior connections to accept a new 
>> connection is one possible policy, but hopefully not a commonly 
>> implemented one. Every deployment will have some limit. Very few 
>> deployments have absolutely no idea what their expected use will be 
>> though. Proper provisioning based on intended usage and empirical 
>> evidence is a reasonable assumption. There are other queuing/blocking 
>> techniques that can help with overload situations. DoS attacks in 
>> particular should not be responded to by dropping existing connections 
>> in order to feed the attack.
> 
>>> Wow.... that's one option, but certainly not the only one. 
>>> <sarcasm>This is where I like to introduce multiple servers</sarcasm>
>>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Jan 2007 10:55:49 -0600

I've been watching this thread for a while, but wanted to respond to Paul's 
note...

> As I say, I am no expert here, so I will be happy if somebody can specify 
> how this can be handled reasonably if every prospective client continually 
> attempts to connect.
>
> Paul

Personalizing a bit, if Spencer says "I've got to set up my connections (and 
do TLS exchanges, but let's ignore that for now) before I need them, because 
I care about setup delays", and Paul says, "I need to close inactive 
connections, because I care about the cost of reserved resources", it's hard 
to see how we're going to both be happy at the same time. Without suffient 
resources, we're only discussing who gives up on their goal first, right?

I'm not sure that any of us are the kind of expert that can put ten pounds 
of flour in a five-pound flour sack, and that's the kind of expert we seem 
to be looking for...

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 13:17:13 -0500

> rather than in response to incoming calls. That prevents "feeding a DOS 

Yes, some kind of disconnect policy. The connecting party has to play 
nice in that policy as well. If the connecting party always immediately 
reconnects then the policy doesn't work.

	Paul

>>> particular should not be responded to by dropping existing 
>>> connections in order to feed the attack.
>>
>> Unfortunately, what the connection request arrives there is generally 
>> no good way to tell how important it is. You might be able to decide 
>> based on what it does after you accept the connection. But that is too 
>> late.
>>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 16 Jan 2007 13:14:38 -0600

Sean Olson wrote:
> implemented one. [...] DoS attacks in particular should not be 
> responded to by dropping existing connections in order to 
> feed the attack.

Hopefully, the SIP proxy will not be the only place where DoS attacks
are detected.  There are other places upstream of the proxy where
such attacks can be detected, including edge routers.  Indeed,
DoS detection systems such as D-WARD detect the attack before or
as the attack packets leave the network that the DoS agent resides
on.  Another system called NetBouncer can be positioned at the choke
points of the network and allows packets from only "legitimate"
clients.  Yet another system, Secure Overlay Service, uses an
overlay network; clients are authenticated to it before they
reach servers.  My point is that SIP proxy should not be the only
one burdened with detecting a DoS attack.

Having said that, dropping unused prior connections to accept a new
connection is a fairly effective policy if DoS mechanisms are
deployed elsewhere in the network.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 16:59:24 -0500

Vijay K. Gurbani wrote:
>> responded to by dropping existing connections in order to feed the 
>> attack.
> 

For connection reuse to work, I think there needs to be *some* way for 
the server to say "I'm disconnecting you, and I don't want you to 
reconnect for awhile unless you need to *use* the connection."

A simple way is for that to be the case by default, all the time. If you 
feel you need to maintain a connection you aren't using, outbound is a 
way to do that.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 16 Jan 2007 16:17:45 -0600

> reconnect for awhile unless you need to *use* the connection."

Hmm -- interesting.  An orderly TCP (or TLS) disconnection can
easily signify this intent.

An unorderly, or abrupt TCP (or TLS) disconnection that did not
result in the TCP (or TLS) shutdown handshake could conceivably
mean that the server or some middlebox somewhere crashed, and
the client may re-establish the connection with an alternate
server (if any), or wait a bit before retrying.

There are programmatical techniques that let an implementation
figure out whether or not a socket was closed in an orderly
fashion or abruptly.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jan 2007 17:34:44 -0500

> figure out whether or not a socket was closed in an orderly

Sounds good to me. Then there still has to be an understanding of what 
sort of circumstance justifies the establishment of a new connection. An 
obvious one is that you shouldn't reconnect until you need to send a SIP 
request. For instance and INVITE, or a REGISTER. This can still be 
abused by somebody who "needs" to send an OPTIONS message. So I think 
the notion of "need" needs to be sharpened. I think this is one of those 
things where it could be hard to define formally, but easy to 
distinguish real need from whim when you see it.

	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Jan 2007 16:38:29 -0600

Hi, Vijay,

Are we talking TCP RESET here, or something else?

Thanks,

Spencer, who thinks it would be just ducky if we could use ICMP for ANYTHING 
on today's Internet :-(

From: "Paul Kyzivat" <[email-masked]>
> request. For instance and INVITE, or a REGISTER. This can still be abused 
> by somebody who "needs" to send an OPTIONS message. So I think the notion 
> of "need" needs to be sharpened. I think this is one of those things where 
> it could be hard to define formally, but easy to distinguish real need 
> from whim when you see it.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Jan 2007 23:17:03 -0800

...
> Sounds good to me. Then there still has to be an 
> understanding of what sort of circumstance justifies the 
> establishment of a new connection. An obvious one is that 
> you shouldn't reconnect until you need to send a SIP 
> request.

That doesn't seem like a good optimization -- how would
you get an incoming call?

> For instance and INVITE, or a REGISTER. This can still be 
> the notion of "need" needs to be sharpened.

If the UA has already registered, and then the TCP connection
is broken, it's going to need to re-register right away 
anyway, especially if its host stack or its NAT gave it a
different ephemeral port than it had with its last 
registration.  

And even if it doesn't need to re-register, it needs to get 
a connection back up for incoming calls.

-d

> I think this is 
> one of those

---

From: Aki Niemi <[email-masked]>
Date: Wed, 17 Jan 2007 09:59:36 +0200

> (http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.txt).

Hold on; let's clearly distinguish between the UA-to-proxy connection
and connections between proxies. The latter clearly has this problem
with authentication, since mere connection establishment and sending
messages in no way means authority to receiving messages over that
connection.

The former case is different, since typically the first thing a UA sends
over the connection is a REGISTER, which gets challenged and
authenticated before the connection is "trusted".

So where is the problem?

Cheers,
Aki

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 17 Jan 2007 15:12:39 +0100

Paul Kyzivat wrote:
>>>> client can establish a TLS connection with mutual authentication, 
>>>> then that could qualify the client as *needing* a connection. I'm 
>>>> talking about other cases. In particular, if we are talking about 
>>>> TCP rather than TLS, then the client establishing a TCP connection 
>>>> doesn't establish a reverse path, unless outbound is used.
>>> Just look at iptel.org SER for example ("tcp_alias" settings, other 
>>> implementations use "persistent TCP", etc, etc).
>>>
>>>> without maintaining a connection, as long as the server can 
>>>> establish a connection when it is needed.
>>> the client nor the server can possibly know whether TCP connections 
>>> can be established towards the client. Deciding-by-trial is way too 
>>> slow as the FWs can drop packets silently, and the default timeouts 
>>> are long. So except in cases where the access network characteristics 
>>> are known, client will have to assume that _it_, the client,
>>>

As Aki said there is no problem in User Agent - Proxy scenario: 
Challenge the client, do not trust the Location and Via header 
(especially alias parameter) but only the trust the source socket. Use 
the source socket of the REGISTER as contact and you will be fine - no 
security issues.

That's how it is done currently.

> separate TCP connection can be made in the other direction.

There are firewalls which block all UDP traffic - thus you ahve to use 
TCP/TLS.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jan 2007 09:11:38 -0500

inline

> you get an incoming call?

Dan - everybody is getting this mixed up with outbound. Outbound has its 
own rules. This discussion came about relative to the connection reuse 
draft which is independent of outbound. Connection reuse has different 
rules for TCP and TLS. In the case of TCP, there is no way to verify the 
identity of the source of a connection, so it isn't used for requests in 
the reverse direction. Instead, a separate connection in the other 
direction is required for those. That of course means the technique can 
only be used when it is possible to establish connections in both 
directions. If that isn't possible, then TCP connection reuse isn't a 
sufficient answer, and either TLS or outbound is required.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jan 2007 09:20:04 -0500

inline

> authenticated before the connection is "trusted".

If the connection is direct from UA to registrar, then perhaps the 
registration is sufficient to authenticate the connection for reverse 
traffic. If the connection is from UA to proxy then the proxy has to 
make leaps of faith to trust the identity of the connection.

I don't recall all the details at the moment, but I know Rohan attempted 
to incorporate this kind of feature into connection reuse a long time 
ago. It was shot down. People went to a lot of trouble to develop 
outbound for this case.

AFAIK the current version of connection reuse is primarily of interest 
for proxy-proxy connections. People keep wanting to apply it to UAs, 
apparently as a poor-man's-outbound. There may be a *few* cases where 
that can work. But attempting to do so is likely to just get people 
confused. I think we would be better off clearly partitioning the 
applicability of these two things.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jan 2007 10:12:34 -0500

A further thought...

I think outbound is in some sense an enhancement to connection reuse, 
with different criteria for when connections should be established as 
well as different criteria for reuse. But while the criteria for 
establishing connections are different, this discussion has identified a 
need for a policy to deal with overload in outbound too - when there are 
more candidates wanting to connect than can be accommodated. It is a 
more serious issue in that case, since when somebody is prevented from 
connecting they also won't be able to receive calls.

A server that uses outbound should probably just refuse connections when 
it has maxed out the number it can support. The UAs that attempt to 
connect will just be out of luck, but then in this case *somebody* has 
to be out of luck.

A server that uses connection reuse without outbound should probably 
attempt to keep some headroom for new connections, by disconnecting some 
connections that haven't been used in a long time. That will allow those 
that need a connection to make one, as long as everybody plays nice and 
doesn't establish connections they don't need.

A server that supports both outbound and connection reuse, and has a 
mixture of peers using one or the other may have some difficulty 
providing equitable service to both types. I'm not sure I want to think 
about that right now.

	Paul

Paul Kyzivat wrote:
>>> Sounds good to me. Then there still has to be an understanding of 
>>> what sort of circumstance justifies the establishment of a new 
>>> connection. An obvious one is that you shouldn't reconnect until you 
>>> need to send a SIP request.
>>
>>> For instance and INVITE, or a REGISTER. This can still be abused by 
>>> somebody who "needs" to send an OPTIONS message. So I think the 
>>> notion of "need" needs to be sharpened.
>>
>> is broken, it's going to need to re-register right away anyway, 
>> especially if its host stack or its NAT gave it a
>> different ephemeral port than it had with its last registration. 
>> And even if it doesn't need to re-register, it needs to get a 
>> connection back up for incoming calls.
>>
>> -d
>>
>>> I think this is one of those things where it could be hard to define 
>>> formally, but easy to distinguish real need from whim when you see it.
>>>
>>>     Paul
>>>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 17 Jan 2007 08:40:03 -0800

> Dan - everybody is getting this mixed up with outbound. 

Not surprising given the subject.  My bad.  Sorry.

-d

> Outbound has its

---

From: Aki Niemi <[email-masked]>
Date: Thu, 18 Jan 2007 10:26:12 +0200

> make leaps of faith to trust the identity of the connection.

I can't see this being any different with UDP, where the proxy in
between can effectively be an open relay, and has to trust the flows it
relays. 

But I also can't see how this problem is any different for, say, HTTP
proxies. That's why many HTTP proxies are configured to do
proxy-authentication, limit the ports to which clients can CONNECT, etc.
Similar logic can be added to a SIP proxy to ascertain that they not
become a totally open relay. 

The rule of thumb in doing this is that you don't commit expensive
resources, or allow all possible actions to be taken until the
connection, or flow, is considered trusted.

<snip>

> applicability of these two things.

Yes, I agree. As I said in the past, we in practice have two very
different interfaces to a proxy: the client-to-server, and the
server-to-server. Outbound is for the former; conn-reuse for the latter.
Neither one has a problem with TCP, although the way one determines when
to trust a connection is very different for each.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jan 2007 09:08:40 -0500

> between can effectively be an open relay, and has to trust the flows it

In UDP, outbound requests from the registrar go to the registered 
contact address. It has to be resolved by the last proxy, and (in the 
absence of -outbound-) is independent of how the register was delivered.

If you try to reuse a tcp connection for requests in the reverse 
direction, then the destination is the source port for the tcp 
connection, which has no direct relationship to the registered contact. 
There are various exploits for this, that permit somebody to hijack 
requests.

For instance: suppose good UA GUA uses a proxy P and registers to 
registrar R, using AOR sip:gua@r.

Then an evil UA - EUA could collude with an evil server ES to hijack 
requests outbound from R and intended for GUA. It could establish a TCP 
connection to P, and then send a REGISTER To: sip:gua@r, but with a 
Route header that takes it to ES, and with a copy of the contact used by 
GUA. ES then colludes by accepting that registration. At this point, P 
will think that the TCP connection from EUA is a valid path to gua.

The details of this are all tied up in how you decide which requests can 
reuse the tcp connection. You can probably tighten things up to solve 
the above problem. If you work at it enough, I think you will end up 
with something like sip outbound. Rohan attempted, and was shot down. 
You can't just naively say that the connection can be reused for 
requests in the reverse direction.

> become a totally open relay. 

I don't know much about HTTP implementation, but afaik there is nothing 
like the reverser routing that we are talking about here. So I don't see 
the analogy.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 18 Jan 2007 22:02:42 +0200

Paul Kyzivat writes:

 > GUA. 

my proxy does not allow pre-loaded route headers unless there is only
one route header that points to the proxy/registrar itself.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jan 2007 16:51:33 -0500

> one route header that points to the proxy/registrar itself.

That is fine for you. And if you do that, and perhaps impose some other 
restrictions, then you can probably make the connection reuse in the 
reverse direction safe.

But for us to specify in an RFC how to do connection reuse in the 
reverse direction with TCP will require writing down a whole set of 
restrictions like that. I see that being done - in the outbound draft - 
but not otherwise. If somebody wants to specify yet another way then I 
guess they can do so.

Establishing a connection in one direction in order for it to be used in 
the other direction doesn't belong in the existing connection reuse 
draft because that doesn't do what is needed for it. In the absence of 
something that does, we must assume that independent connections will be 
established in each direction.

	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 19 Jan 2007 09:19:00 +0100

At 19:17 16/01/2007, Paul Kyzivat wrote:

>Tom-PT Taylor wrote:
>>This isn't like provisioning a telephone trunk group (circuit group, in European terminology), where you know each trunk will eventually be freed when the call is complete. In the present case, you either provide for every client to be connected or you need a disconnect policy. What I suggest is a policy of disconnecting after some period of non-use, rather than in response to incoming calls. That prevents "feeding a DOS attack".
>
>Yes, some kind of disconnect policy. The connecting party has to play nice in that policy as well. If the connecting party always immediately reconnects then the policy doesn't work.

Is this something we wish to debate in the IETF?

I mean if an implementation's maximum of TCP connections is insufficient to serve
given number of clients and given traffic, then a policy will not generate the
missing resources, overprovisioning with more boxes will. Reminds me of the old
QoS dilemma: QoS policies don't generate bandwidth, they do create unfairness
rules. Which in this particular case leads to less preferred clients being
disconnected and unreachable. Not sure if thats what we are striving for.

The tough case is DoS-driven overload, however the assumption of being better off
using a cooperative client respecting a policy doesnt help much either.

-jiri

>>>I certainly agree in the DOS case. And I am not knowledgeable in this area, so will defer to somebody that is. But at some point one must either drop an existing connection or reject a connection request. It seems pretty unfair if you end up rejecting connection requests that might be important in order to preserve a connection that hasn't been used in hours, days, or more.
>>>
>>>Unfortunately, what the connection request arrives there is generally no good way to tell how important it is. You might be able to decide based on what it does after you accept the connection. But that is too late.
>>>
>>>As I say, I am no expert here, so I will be happy if somebody can specify how this can be handled reasonably if every prospective client continually attempts to connect.
>>>
>>>    Paul
>>>

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 19 Jan 2007 16:24:03 +0100

At 15:08 18/01/2007, Paul Kyzivat wrote:

>>>If the connection is direct from UA to registrar, then perhaps the registration is sufficient to authenticate the connection for reverse traffic. If the connection is from UA to proxy then the proxy has to make leaps of faith to trust the identity of the connection.
>In UDP, outbound requests from the registrar go to the registered contact address. It has to be resolved by the last proxy, and (in the absence of -outbound-) is independent of how the register was delivered.

I'm worried that in interest of accomodating some overcomplicated scenarios we would be 
tempted to make the key mainstream cases difficult too. Running code (not SIP
specifically, BTW) works as follows for sake of being able to deal with NATs and 
firewalls:
- clients makes itself known. This registration request creates TCP or UDP bindings
  underway in NATs, firewalls, middleboxes, what-have-you
- when a message comes back (reply or subsequent requests), it travels symmetrically
  so that bindings underway allow the message to pass through.
- client keeps the "connection" alive periodically

This is implemented this way because it is known to work over NATs and firewalls
(mostly).

>If you try to reuse a tcp connection for requests in the reverse direction, then the destination is the source port for the tcp connection, which has no direct relationship to the registered contact. 

If an implementation is done this way, I would label it suboptimal because 
of its lowered capability to deal with NATs/firewalls.

I think a well behaving client implementation has direct relationship between
contact and transport source. That's very important to get over NATs/firewalls.
There are use-cases in which this doesn't hold but let's for now speak the UA 
maintstream case.

>There are various exploits for this, that permit somebody to hijack requests.
>
>For instance: suppose good UA GUA uses a proxy P and registers to registrar R, using AOR sip:gua@r.
>
>Then an evil UA - EUA could collude with an evil server ES to hijack requests outbound from R and intended for GUA. It could establish a TCP connection to P, and then send a REGISTER To: sip:gua@r, but with a Route header that takes it to ES, and with a copy of the contact used by GUA. ES then colludes by accepting that registration. At this point, P will think that the TCP connection from EUA is a valid path to gua.

I think that in this scenario the problem is blind trust (no authentication between elements,
unreasonable trust in preloaded Route header fields). I dont think we should consider
such unwise scenarios as a driver for whatever we may wish to do.

I think that we should test against "running code" scenarios. Such as that GUA authenticates with
R over P, R authenticates, and P only considers 200s from R as indication of success.

I mean with the protocol as is, the network design space is quite huge but I don't think that
we shall try to accomodate every allowable design, and we shall particularly avoid considering
suboptimal (even though valid, protocol-wise) network designs as driver for our work.

-jiri

>The details of this are all tied up in how you decide which requests can reuse the tcp connection. You can probably tighten things up to solve the above problem. If you work at it enough, I think you will end up with something like sip outbound. Rohan attempted, and was shot down. You can't just naively say that the connection can be reused for requests in the reverse direction.
>
>I don't know much about HTTP implementation, but afaik there is nothing like the reverser routing that we are talking about here. So I don't see the analogy.
>
>        Paul
>
>>>AFAIK the current version of connection reuse is primarily of interest for proxy-proxy connections. People keep wanting to apply it to UAs, apparently as a poor-man's-outbound. There may be a *few* cases where that can work. But attempting to do so is likely to just get people confused. I think we would be better off clearly partitioning the applicability of these two things.

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 19 Jan 2007 16:34:54 +0100

At 17:01 16/01/2007, Paul Kyzivat wrote:
>>>>If the server cannot establish a connection to the client, but the client can establish a TLS connection with mutual authentication, then that could qualify the client as *needing* a connection. I'm talking about other cases. In particular, if we are talking about TCP rather than TLS, then the client establishing a TCP connection doesn't establish a reverse path, unless outbound is used.
>>>Just look at iptel.org SER for example ("tcp_alias" settings, other implementations use "persistent TCP", etc, etc).
>>>
>>>>You can register with a server in order to receive outbound calls without maintaining a connection, as long as the server can establish a connection when it is needed.
>>>the client nor the server can possibly know whether TCP connections can be established towards the client. Deciding-by-trial is way too slow as the FWs can drop packets silently, and the default timeouts are long. So except in cases where the access network characteristics are known, client will have to assume that _it_, the client,
>>>
>What point are you making? 

I'm concurring with the point, it is client's responsibility to keep connections open,
over which incoming requests will be coming. (Which is logical also for the reason,
that if the client is behind a NAT, the server can't even open it, not speaking of
keeping it alive.)

>Vijay responded as I would have - the single TCP connection has major security concerns if used bidirectionally. You should only use TCP if you know you don't have NAT/FW issues, so that a separate TCP connection can be made in the other direction.

here the initial email from Vijay re: connection_reuse:
"For TCP, it is a connection-in-each direction because of the security
properties associated with the TCP transport when used in SIP
(so, you should not open up a TCP connection for REGISTER and
expect to receive requests in the backwards direction over it.)"

Isn't the security concern caused just by the fact that 'alias' is accepted
as part of unathenticated request?

-jiri

>Otherwise, if you have your own cert you can use TLS and avoid the need for connection establishment in the reverse direction, or else you can use outbound.
>
>Practically speaking, a UA will typically not have a cert, and will need to use outbound. Connection reuse, via TCP or TLS, will typically only be useful between proxies.
>
>        Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 19 Jan 2007 16:53:24 +0100

>is the party responsible for initiating connections.

Yes, that's how running code works :-)

It shall be noted that vast majority of other Internet applications is using
this model for clients behind NATs/firewalls to be able to receive incoming
traffic. The transport!=contact capability of SIP is IMO of problematic value
and shall only be used as exception.

-jiri

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 19 Jan 2007 16:07:24 -0600

> as part of unathenticated request?

Yes, and section 9.3 of connect-reuse indicates that HTTP Digest
may mitigate a subset of the problems of TCP connection reuse.  But
HTTP Digest cannot be used for proxy-proxy communications.

So what is the answer for reusing TCP connections between proxies
in the face of NATs and firewalls?  The canonical answer is
to use the same connection in the backwards direction because
the NATs will allow data packets through that connection.  But
sending a request through that connection open the proxy to
hijacking...

- vijay

---

From: Sean Olson <[email-masked]>
Date: Tue, 16 Jan 2007 07:52:22 -0800

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, January 16, 2007 7:48 AM
To: Sean Olson
Cc: Vijay K. Gurbani; SIP LIST
Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound]

        Paul

---

From: Sean Olson <[email-masked]>
Date: Tue, 16 Jan 2007 10:26:29 -0800

Even when provisioning trunk groups, you are not provisioning for every single subscriber to be in a call simultaneously. Provisioning needs to be done based on expected usage of course.  A disconnect policy to deal with overload and DoS is wise, but it needs to be more sophisticated than FIFO. And the client does need to participate or at least have a clear way of determining when the client is not playing nice.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, January 16, 2007 10:17 AM
To: Tom-PT Taylor
Cc: Sean Olson; SIP LIST
Subject: Re: TCP connection establishment [was: RE: [Sip] Question aboutPoll: Proposal relating to keepalive, TCP, and UDP usage indraft-ietf-sip-outbound]

        Paul