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

From: Dean Willis <[email-masked]>
Date: Fri, 8 Dec 2006 20:12:05 -0600

Previously we had recorded consensus to use STUN for keepalive with  
both TCP and UDP. This was not a perfect consensus (there were some  
dissenters). There has been ongoing discussion notably instigated by  
the current editor of the Outbound draft, that some people feel may  
have resulted in a change of the consensus on this draft's technical  
direction.

So I'd like to ask people who care and think they understand the  
differences to answer the following questions, on-list and on-the  
record.

Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS  
over TCP flow (retain STUN for UDP flows).

Yes (accept the proposal and use CRLF for TCP) or No (reject the  
proposal and keep STUN for TCP)

Proposal 2: Make outbound registrations over UDP flows optional for UAs.

Yes (Accept the proposal) or No (Reject the proposal).

Proposal 3: Include (in Outbound) the statement that its is  
RECOMMENDED that the outbound-proxy-set is configured to result in  
registrations over TCP or TLS whenever the UA can't accept incoming  
TCP flows. Further, include text that explain that for historical  
purposes a lot of deployments still only use UDP, but that we expect/ 
hope those deployments to eventually migrate to TCP when doing outbound.

Yes (Accept the proposal and add the text) or No (Reject the proposal  
and keep the text as-is).

--
Dean Willis (wearing his chair sombrero)

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 9 Dec 2006 12:01:25 +0100

Yes on all accounts

For (3) (TCP/TLS) I think we will need to say more to support the transition 
path. Currently many UAs dont support TLS, does that mean the outbound set 
should have both SIP and SIPS URIs, and the UA gets to pick?

Jeroen van Bemmel

---

From: <[email-masked]>
Date: Mon, 11 Dec 2006 10:07:21 +0200

Hi,

Strong yes to all those three proposals. Please see the
details of my reasons below, I believe they are important
for the your consideration.

In IETF#65 meeting I was one of those who voted for STUN
as keepalive mechanism over TCP. I did that due to consistency
reason: as STUN was selected as a keepalive mechanism instead
of SIP PING for UDP, it appeared to me that using STUN over TCP
as well would be the most straightforward way to go. However I
have changed my opinion due to the following pieces of normative
text which have been added to Outbound draft AFTER the Dallas hum:

1. Usage of UDP flows now appear as a bad idea in general,
   thus my original "consistency reason" has lost its value.
   UA could just set up TCP flows with CRLF keepalives and
   NEVER use STUN for keepalives related to Outbound:

   Use of outbound with UDP flows typically prevents messages larger
   than 1300 bytes from being delivered using TCP as described in
   Section 18.1.1 RFC 3261.  Use of outbound in conjunction with UDP
   flows in environments where requests are expected to be larger than
   this size is therefore NOT RECOMMENDED.

2. Mechanisms to for the UA to validate if the proxy supports 
   STUN or not appear more complex than hoped. Using OPTIONS for
   the check also consumes an extra round-trip. No such validation
   is needed for CRLF keepalives, which are totally RFC3261 compatible:

   Because sending and receiving binary STUN data on the same ports used
   for SIP is a significant and non-backwards compatible change to RFC
   3261, this section requires a number of checks before sending STUN
   messages to a SIP node.  If a SIP node sends STUN requests (for
   example due to misconfiguration) despite these warnings, the node
   could be blacklisted for UDP traffic, or cause its TCP server to
   loose framing over its connection.  For each target node (as
   determined by IP address, address family, and port number), the
   sender needs to determine if that destination is validated to support
   STUN, that it does not support STUN, or that it needs to be
   validated.

   A SIP node MUST NOT send STUN requests over a flow unless it has an
   explicit indication that the target next hop SIP server claims to
   support STUN.  For example, automatic or manual configuration of an
   outbound-proxy-set which contains the keepalive=stun parameter is
   considered sufficient explicit indication.  Note that UACs MUST NOT
   use an ambiguous configuration option such as "Work through NATs?" or
   "Do Keepalives?" to imply next hop STUN support.  A SIP node MAY also
   probe the next hop using a SIP OPTIONS request to check for support
   of the 'sip-stun' option tag in a Supported header field.

3. If the UA does not support TCP keepalive and the proxy appears not
   to support STUN, then no keepalive over TCP is possible ! If UA could
   simply send CRLF keepalives this would NOT be a problem:

   Futhermore, even with explicit indication of next hop STUN support, a
   SIP node needs to validate support for STUN the first time it sends
   traffic to a specific unvalidated target destination.  If an explicit
   probe indicates support for the 'sip-stun' option-tag, that
   destination is validated for STUN support. If an explicit probe does
   not indicate support for the 'sip-stun' option-tag, the target
   destination does not support STUN request, and the UAC MUST NOT send
   further STUN requests to this destination.  A SIP node MAY send one
   STUN request and its retransmissions to an unvalidated destination.
   If a STUN request ever succeeds to a destination, that destination is
   thereafter validated for STUN support.  If this initial STUN request
   does not result in a STUN response, the SIP node MUST NOT send
   additional STUN requests over this flow, unless and until a next-hop
   probe later validates the destination.  In addition, the SIP node
   SHOULD remember unvalidated destination nodes that have been used
   within one hour and SHOULD NOT send additional STUN messages to any
   of these destinations.  Note that until STUN support has been
   verified, an initial STUN failure over UDP is not considered a flow
   failure.  For UDP flows, an unvalidated flow can still be reused for
   SIP traffic, however for unvalidated TCP or TLS over TCP flows, the
   connection over which STUN requests were sent MUST be closed.

4. Interaction of SIP, STUN and SigComp over TCP clearly wastes
   bandwidth, exactly on cases where SigComp would otherwise be
   useful to save bandwidth. Instead of sending a couple of bytes
   (CRLF keepalive) each keepalive would consist of more than 30 bytes
   (13 bytes of SigComp shim header plus 20 bytes of STUN header):

   For TCP-based flows, SigComp requires that all messages are processed
   by the SigComp compressor to facilitate framing.  For these
   transports, STUN messages are sent encapsulated in the SigComp "well-
   known shim header" as described in Section 11 of [I-D.ietf-rohc-
   sigcomp-impl-guide].

For an UA that would support Outbound only over TCP using
CRLF keepalives, all that complicated processing together
with waste of round-trips and bandwidth would be easily avoided.

>both TCP and UDP. 

In my understanding that concensus was reached by hums in
IETF#65 meeting in Dallas. My observation from the meeting was
that the discussion was focusing to a selection between STUN
and SIP PING as a global keepalive mechanism, which raised a
hectic email rally before the meeting. CRLF was touched but
the debate was really about the choice between STUN and PING.
There were two votes in the meeting, the first one for UDP
keepalive mechanism and the second for TCP. My feeling was that
the meeting participants focused their thoughts very much on
the STUN vs. PING issue so that STUN vs. CRLF was not
considered too carefully before the votes. And as demonstrated
above, the decision made in Dallas brought a number of
complications to Outbound in a way which could not be
anticipated yet in that meeting.

Regards,

Erkki 

>-----Original Message-----
>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 09.December.2006 04:12
>To: SIP IETF
>Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and 
>UDP usage in draft-ietf-sip-outbound
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 11 Dec 2006 09:29:52 +0100

Hi,

There are a few issues I'd like to clarify on proposal 3.

First, I think the "default" recommendation should only cover TCP. The
text can say that, if the terminal supports TLS, the recommendation also
covers TLS. However, in some environments other security mechanisms may
be used, so I don't think clients in such environments should even be
recommended to implement TLS, nor should the whatever-outbound-proxy-set
configuration-mechanism is used in those environments be recommended to
return TLS registrations in such environements.

Second, as I said before, I don't think we shall talk about UDP and its
"history". UDP is a valid transport for SIP. IF someone really wants
this history text I propose we separate it into proposal 4.

Third, since it is only recommended to return TCP information, I guess
it means we will NOT mandate (eventhough we would, if propsoal 3 is
accepted, recommend it) a UA to establish TCP registrations? If so, I
think we could clarify that (either as part of option 2 or 3). 

Regards,

Christer

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 9. joulukuuta 2006 4:12
> To: SIP IETF
> Previously we had recorded consensus to use STUN for 
> keepalive with both TCP and UDP. This was not a perfect 
> consensus (there were some dissenters). There has been 
> ongoing discussion notably instigated by the current editor 
> of the Outbound draft, that some people feel may have 
> resulted in a change of the consensus on this draft's 
> technical direction.
> 
> So I'd like to ask people who care and think they understand 
> the differences to answer the following questions, on-list 
> and on-the record.
> 
> 
> Proposal 1: Make CRLF the only keepalive mechanism for TCP 
> and TLS over TCP flow (retain STUN for UDP flows).
> 
> Yes (accept the proposal and use CRLF for TCP) or No (reject 
> the proposal and keep STUN for TCP)
> 
> 
> RECOMMENDED that the outbound-proxy-set is configured to 
> result in registrations over TCP or TLS whenever the UA can't 
> accept incoming TCP flows. Further, include text that explain 
> that for historical purposes a lot of deployments still only 
> use UDP, but that we expect/ hope those deployments to 
> eventually migrate to TCP when doing outbound.
> 
> Yes (Accept the proposal and add the text) or No (Reject the 
> proposal and keep the text as-is).
> 
> 
> --
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 11 Dec 2006 09:29:52 +0100

Hi,

Regards,

Christer

---

From: "Aki Niemi" <[email-masked]>
Date: Mon, 11 Dec 2006 10:49:30 +0200

Yes, yes, and yes.

Cheers,
Aki 

>Sent: 09 December, 2006 04:12
>To: SIP IETF
>Previously we had recorded consensus to use STUN for keepalive 
>with both TCP and UDP. This was not a perfect consensus (there 
>were some dissenters). There has been ongoing discussion 
>notably instigated by the current editor of the Outbound 
>draft, that some people feel may have resulted in a change of 
>the consensus on this draft's technical direction.
>
>the differences to answer the following questions, on-list and 
>on-the record.
>
>
>Proposal 1: Make CRLF the only keepalive mechanism for TCP and 
>TLS over TCP flow (retain STUN for UDP flows).
>

---

From: <[email-masked]>
Date: Mon, 11 Dec 2006 11:00:43 +0200

Hi,

Yes to all proposals, especially the first one.

Markus

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 11 Dec 2006 11:18:52 +0100

Dean Willis wrote:
> Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over 
> TCP flow (retain STUN for UDP flows).
> 

YES.

> Yes (Accept the proposal) or No (Reject the proposal).

YES.

> 
> Proposal 3: Include (in Outbound) the statement that its is RECOMMENDED 
> that the outbound-proxy-set is configured to result in registrations 
> over TCP or TLS whenever the UA can't accept incoming TCP flows. 
> Further, include text that explain that for historical purposes a lot of 
> deployments still only use UDP, but that we expect/hope those 
> deployments to eventually migrate to TCP when doing outbound.
> 

YES.

/alfred

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 11 Dec 2006 13:21:27 +0200

Yes to all.

Dean Willis wrote:
> Previously we had recorded consensus to use STUN for keepalive with both 
> TCP and UDP. This was not a perfect consensus (there were some 
> dissenters). There has been ongoing discussion notably instigated by the 
> current editor of the Outbound draft, that some people feel may have 
> resulted in a change of the consensus on this draft's technical direction.
> 
> differences to answer the following questions, on-list and on-the record.
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 11 Dec 2006 14:53:54 +0100

> proposal and keep STUN for TCP)

yes

> Yes (Accept the proposal) or No (Reject the proposal).

yes

> purposes a lot of deployments still only use UDP, but that we 
> expect/hope those deployments to eventually migrate to TCP when doing 
> outbound.
>

yes

Hisham

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 11 Dec 2006 15:50:32 +0100

Hi Erkki,

When you talk about OPTIONS, extra roundtrips etc, you forget that the
edge proxy can insert the keep-alive parameter e.g. in the Path header
(or Service-Route, depending on what happens to Jonathan's route
construct draft) of the REGISTER to indicate its support of STUN.

Regards,

Christer 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 11. joulukuuta 2006 10:07
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] Poll: Proposal relating to keepalive, 
> TCP,and UDP usage in draft-ietf-sip-outbound
> 
> 
> Hi,
> 
> details of my reasons below, I believe they are important for 
> the your consideration.
> 
> 
> In IETF#65 meeting I was one of those who voted for STUN as 
> keepalive mechanism over TCP. I did that due to consistency
> of SIP PING for UDP, it appeared to me that using STUN over 
> TCP as well would be the most straightforward way to go. 
> However I have changed my opinion due to the following pieces 
> of normative text which have been added to Outbound draft 
> AFTER the Dallas hum:
> 
> IETF#65 meeting in Dallas. My observation from the meeting 
> was that the discussion was focusing to a selection between 
> STUN and SIP PING as a global keepalive mechanism, which 
> raised a hectic email rally before the meeting. CRLF was 
> touched but the debate was really about the choice between 
> STUN and PING.
> keepalive mechanism and the second for TCP. My feeling was 
> that the meeting participants focused their thoughts very 
> much on the STUN vs. PING issue so that STUN vs. CRLF was not 
> considered too carefully before the votes. And as 
> demonstrated above, the decision made in Dallas brought a 
> number of complications to Outbound in a way which could not 
> be anticipated yet in that meeting.
> 
> Regards,
> 
> Erkki 
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 11 Dec 2006 11:39:16 -0600

Yes to all.

> Sent: Friday, December 08, 2006 18:12
> To: SIP IETF
> Subject: [Sip] Poll: Proposal relating to keepalive, TCP, and

---

From: Byron Campen <[email-masked]>
Date: Mon, 11 Dec 2006 12:31:40 -0600

Yes on all three.

Best regards,
Byron Campen

> dissenters). There has been ongoing discussion notably instigated  
> by the current editor of the Outbound draft, that some people feel  
> may have resulted in a change of the consensus on this draft's  
> technical direction.
>
> expect/hope those deployments to eventually migrate to TCP when  
> doing outbound.
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 11 Dec 2006 13:30:44 -0800

> proposal and keep STUN for TCP)

Yes

> Yes (Accept the proposal) or No (Reject the proposal).

No

> and keep the text as-is).

No

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

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 12 Dec 2006 09:37:30 +0100

Dean Willis wrote:
...

Yes

> Proposal 2: Make outbound registrations over UDP flows optional for UAs.

Yes, and I also want it optional for edge proxies/registrars.

Yes

/Fredrik

---

From: <[email-masked]>
Date: Wed, 13 Dec 2006 08:23:48 +0200

Hi,

It seems to me that the I-D Preventing Fragmentation for
Client Initiated Connections in the Session Initiation Protocol (SIP)
written by Marc Petit-Huguenin demonstrates very well the resons 
why UDP support for Outbound UAs should be made optional. Trying 
to really solve the problems with UDP together with Outbound would 
make the total solution more and more complex. 

>> Yes (Accept the proposal) or No (Reject the proposal).

Based on another email from Marc I understood that the reason
to his No is the compatibility to RFC 3261 which mandates UDP.
I would like to know if there any other, more technical reasons 
(rather than the old WG decision within RFC 3261) to mandate UDP 
with Outbound ? This far I have not heard any convincing one.

Regards,

Erkki

>From: ext Marc Petit-Huguenin [mailto:[email-masked]] 
>Sent: 11.December.2006 23:31
>To: Dean Willis
>Cc: SIP IETF
>Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, 
>and UDP usagein draft-ietf-sip-outbound
>
>Dean Willis wrote:
>keepalive with both
>RECOMMENDED

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 16 Dec 2006 12:33:49 -0800

Practically speaking given where we are today, I would be a fan of a  
solution that meant the following goals:

1) allowed deployments that wanted to use TCP to use TCP

2) allowed deployments that wanted to use UDP to use only UDP with  
the known limitations that the UA would not be able to send large  
requests

3) allowed deployments that wanted to use both UDP and TCP to do so  
and not have the size limitations by using switchover

(note it would be easy to  meet the above goals using any type of  
keep alive so they do no impact if we use CRLF or something else)

Now I know there are people on the list that only care about one of  
these three goals but I know there are some people that want each  
one. I think that if we had some agreement that we were trying to  
meet these goals, then it would be easier for Rohan and I to help  
make progress on a proposal that everyone found agreeable. Perhaps  
Rohan's proposal meets these. I understand Rohan is making the  
argument that 2 is not needed because 3261 does not allow 2 - some  
people disagree with this regardless it is is clear that the bulk of  
deployments today are in category 2 for a variety of good reasons.

I just don't want to hold up outbound with figuring out the problems  
of TCP vs. UDP. Or figuring out how to do high reliability in SIP  
proxy farms. Or figuring out how to exactly build very scaleable  
proxy farms. Or figuring out how to deal with some security problems  
with changing IPs on UAs. All of these things are separable from  
outbound and though work is needed on them, I think we can finish  
this work without solving all o f them. I'd rather not spend endless  
time discussing if outbound should only work for IPv6 to help  
encourage people to move to v6 but instead try and find something  
that we could all live with and meant the needs of at least a bunch  
of deployments.

So if we can agree on above sort of goals, I think it will help me  
understand how to come up with some proposal that take into account   
what people are saying on this poll.

more inline...

> proposal and keep STUN for TCP)

I think we have heard from the people that think STUN is a good idea  
why they think STUN is a good idea. I think we previously came to the  
idea that the double CRLF was better than the CRLF so I would rather  
compare to double CRLF in the poll.

> Yes (Accept the proposal) or No (Reject the proposal).

I don't understand the question. The problems around this seem to be  
around difference between use and implement and this questions does  
not help me figure out what to put in the draft. I think I am also  
confused on how this differs from what we have in the draft today.  
Anyway, color me confused.

> expect/hope those deployments to eventually migrate to TCP when  

I think this needs some discussion before you take a poll on it.  
Perhaps people who have said yes to this can propose how a UA behind  
a firewall will be able to tell if can accept incoming TCP flows? How  
would the system doing the setting of the outbound-proxy-set know?

> proposal and keep the text as-is).

I think to get some facts on the table it would also be nice to  
understand:

What percentage of commercially available proxies today support high  
reliability with over 100k connections?

What percentage of commercially available proxies do switch over from  
UDP to TCP on large requests?

Do we have the standards in place to build UAs that work with high  
reliability TCP systems on a large scale.

Cullen <with my outbound editor hat on>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Dec 2006 11:53:00 -0600

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Saturday, December 16, 2006 12:34
> To: SIP
> Subject: [Sip] Question about Poll: Proposal relating to 
> keepalive, TCP, and UDP usage in draft-ietf-sip-outbound

[ .... ]

> 2) allowed deployments that wanted to use UDP to use only UDP 
> with the known limitations that the UA would not be able to 
> send large requests

Hi Cullen, I don't believe this is the core problem.

The problem with UDP is more that the UA will not be able to RECEIVE
large requests over UDP.

You could always build your UA to no send large requests and avoid the
fragmentation problem, but you can not force other people's products to
not use large requests.

Many PSTN gateways and Softswitches always send large INVITEs for
example,
and they will always fragment. And I might add that many very popular
NAT/routers don't support UDP fragmentation.

The consequence of this is that point 2 really doesn't exist in real
life 
except in closed environments where you control the other UAs as well.

A UA has to have an opened TCP connection "just in case" the other side
sends
a large request, which is quite likely.

So, what you are really saying is that one may want to support UDP
for closed environments where fragmentation is known not to be possible.
This
could be for example an Enterprise Network where you control all the
equipment
that is allowed. I do not have a problem with having words to that
effect in
the text, and words explaining the problem with fragmentation and
incoming 
requests.

(That being said, I believe that in practice, it means that using
outbound
for UDP will just prove to be essentially useless: too complicated, and
too likely
to fail).

> 3) allowed deployments that wanted to use both UDP and TCP to 
> do so and not have the size limitations by using switchover

What does this really mean? You mean a UA will open two connections, one
for UDP and
another for TCP?

Yes, that would be the consequence of the previous point. I fail to see
why on earth
anybody would do this instead of just using a single TCP connection.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Dec 2006 10:53:04 -0800

> The problem with UDP is more that the UA will not be able to RECEIVE

Ooops - my bad, you are right - I should have put I was thinking of  
this as someone trying to send to the UA that registered but realized  
I phrased this all wrong

> fragmentation problem, but you can not force other people's  

Well, it's seems very reasonable for any network (even one that only  
uses TCP) to have a policy on maximum request (or response) size and  
reject requests larger than this.

> NAT/routers don't support UDP fragmentation.

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.

> except in closed environments where you control the other UAs as well.

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.

> a large request, which is quite likely.

I think this is only true when the policy allows messages larger than  
what can be done over UDP. I'm not arguing that 2 is a better way to  
deploy than 1 or 3, just that there are a lot of people that do 2 and  
that I think more work is needed to make 1 or 3 feasible so that this  
draft should not take on trying to eliminate deployments like 2

> the text, and words explaining the problem with fragmentation and

Uh, no - I was saying that outbound over UDP is usable in cases where  
the policy is to reject messages that are too large for UDP. I agree  
that limits the functionality of the communications with the UA that  
registered over this UDP only network but that was that deployments  
choice.

Note what I am talking about here is all about deployments using TCP  
or UDP. I don't mind about if a UA has to implement both.

> anybody would do this instead of just using a single TCP connection.

I think the folks that favor these approach would use a scheme where  
the UDP connection was long lived and the TCP connection was short  
lived for the large messages. The advantages of this would be to get  
the scaleability and reliability schemes that are easier with UDP yet  
still be able to do large messages. I'm not saying that I think these  
schemes are a  good idea or not -- but my feeling is that we can  
finish outbound and leave it open such that three of these are  
possible and future drafts can suggest which ones are best and when  
they should be used.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Dec 2006 16:04:12 -0600

> > life except in closed environments where you control the 
> other UAs as 
> > well.
> 
> 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.

Well, Outbound is not deployed yet, neither for TCP nor for UDP.

What I'm trying to say, is that I fail to see a case where
outbound-UDP-only
would work on the global internet (at least with our current wording in
RFC 3261).

You would ALWAYS need to open an outbound TCP connection "just-in-case".

Unless, well, unless we start making "assumptions" like:

- Switching to TCP will never happen, because:
  - Messages will never be too big for the path MTU
  - If they are, it is "ok" to fragment UDP (change from 3261)
  - If UDP does fragment, it is assumed that it will work
    - If there is a NAT, it will be good enough to support UDP
fragmentation

Again,

I'm ok with having outbound support STUN-over-UDP, as long as we are
honest about
the implications regarding fragmentation. This could be as simple as
explaining that
if you don't keep a TCP channel opened, request that are bigger than MTU
and would
observe the rules of RFC 3261/18.1.1 would not be able to be received.

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 19 Dec 2006 08:40:40 +0100

Francois Audet wrote:
...
> observe the rules of RFC 3261/18.1.1 would not be able to be received. 

If we have a user agent that has one TCP and one UDP flow open to each 
proxy in the outbound proxy set, and these happen to be edge proxies - 
what happens when a large request is being sent towards the UA?

The authoritative proxy looks up all the bindings in the location 
database, and sends it to one of the edge proxys (edge-proxy1) with

   Route: <sip:[email-masked];ob>

If flow-xyz was a TCP flow, that would just work - the request would 
reach the UA. However, if it is a UDP flow, it won't work for this 
particular request. The flow is fine, so a '430 Flow Failed' is not 
applicable.

In the lack of a proposed idea about how this should work technically, I 
don't think it is meaningful to discuss this variant of Outbound 
(TCP+UDP) any further, since we would all be discussing different 
things. I know this problem can be solved, but it won't come for free 
and I always want to know the price before considering whether to buy 
something. I hope the same applies to the SIP WG.

/Fredrik

---

From: Aki Niemi <[email-masked]>
Date: Tue, 19 Dec 2006 10:41:06 +0200

Cullen,

> and not have the size limitations by using switchover

There's a draft out that proposes how to handle 3), which I personally
find incredibly complex. To accept such complexity, I think we'd need to
have some pretty convincing reasons for it. So far, it seems, the most
convincing I've heard are "because RFC3261 says so" and "because we
don't implement TCP".

There are plenty of people on this list who've said that the best way to
deal with 2) and 3) is to *not* deal with them. I think the proposal on
the table meets 2) in that it allows for deployments to be UDP-only, but
also instructs people that this will likely only work in a tightly
controlled environment, not in the Internet.

> deployments today are in category 2 for a variety of good reasons.

People keep bringing up this point about existing deployments. Clearly,
these existing deployments must be working through NAT just dandy, since
otherwise they wouldn't exist. 

Then what are these deployments expecting the SIP WG to deliver? A new
keepalive mechanism, so that they need to upgrade all of their
equipment, after which they will work exactly the same way as before,
but with added complexity?

Somehow I don't believe that people would go through all that trouble of
implementing STUN and SIP+STUN muxing for no other benefit than being
able to add one more RFC to their product sheets.

> this work without solving all o f them. 

Even if we made outbound TCP-only, people would be free to use UDP in
their deployments, just like they are at the moment.

> I'd rather not spend endless  

I want to point out you're the first person to mention IPv6 in this
context. Let me also point out that drawing any parallels between
discussion of using TCP with SIP to using SIP over IPv6-only is really
uncalled for. There is ample existance proof that apps work well using
TCP, and that TCP is well supported by practically all networking gear
and OSs out there. It's in heavy use and has been for 15 years in the
web. In other words, nothing in the Internet needs to change in order to
use SIP over TCP. This is not the IPv6 vs. IPv4 religious war.

We also have data to back up the claim that TCP scales as well as UDP
with SIP. I have yet to hear any description of concrete problems with
using TCP as transport, and in fact, it strikes me as odd that you're
attempting to make this discussion into something it's not.

<snip>

> would the system doing the setting of the outbound-proxy-set know?

I said yes, because I can live with this especially if it pleases the
UDP-only crowd.

The short answer here is, they won't ever just know. And because they
won't ever know, they will be better off by simply using a persistent
TCP connection to the outbound proxy. It's actually the UDP-only crowd's
concern to figure out when and where they can use UDP-only.

> reliability TCP systems on a large scale.

You seem to suggest we have not; that high reliability is not possible
with TCP. Can you be more specific? What are the concrete problems?

Cheers,
Aki

---

From: <[email-masked]>
Date: Wed, 20 Dec 2006 10:18:06 +0200

Hi Cullen,

>that are working over UDP.

If so, then how would those endpoints get any benefit from Outbound ?
What would be the value added for those deployments if those endpoints 
would be changed as Outbound UDP compliant endpoints ? Multiple 
registration support and new types of keepalive messages i.e. some
added reliability ?

But if those endpoints and proxies anyway have to be either upgraded 
or replaced for Outbound, then why couldn't that upgrade cover TCP
support as well ? What is the ultimate benefit for using UDP instead
of TCP for those deployments ?

>or UDP. I don't mind about if a UA has to implement both.

Please remember that the proposal that you do not agree with was

> Proposal 2: Make outbound registrations over UDP flows optional for 

Outbound over UDP would still be possible and probably supported by
those UA vendors who get significant gain for it. But some UAs 
targetting to other deployments could just opt to support TCP.
What is wrong with that ?

If it is the deployments choice to limit the functionality of the
communications with the UA registered, why could it not be possible
for the specific closed deployments to administratively (or technically)
limit the deployed UAs to be such that implement UDP ? Why would you
mandate ALL the implemented UAs to support UDP for Outbound ? Those
deployments could just tell the users not to aqcuire any UAs which
only support Outbound with TCP, if the proxies (or operator policy)
does not support TCP (or does not support persistent TCP connections).

>> You mean a UA will open two connections, one
>> for UDP and another for TCP? I fail to see why on earth
>still be able to do large messages. 

Please remember the Outbound draft does make such a scheme possible !
If the UA does NOT have a long lived persistent TCP connection
available, there is no way for the proxy to get the UA to open
such connection or for the proxy itself open such a TCP connection
towards the UA via the NAT when a large message arrives destined
to the UA. So if the UA does not keep the TCP connection open
all the time, it has to live with the limitation of not being
able to receive SIP requests bigger than MTU if the NAT discards
fragmented UDP packets.

P.S. Actually there is such a mechanism for that specified in Marc 
Petit-Huguenin's I-D "Preventing Fragmentation for Client Initiated
Connections in the Session Initiation Protocol (SIP)" - but that
is not within the baseline Outbound spec and there is no normative
binding between those specs either.

Regards,

Erkki

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 20 Dec 2006 19:18:21 +0200

> registration support and new types of keepalive messages i.e. some

nothing, because outbound draft does not mandate registering with
multiple registrars.

 > of TCP for those deployments ?

again nothing.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Sun, 24 Dec 2006 17:53:44 -0600

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

--

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 25 Dec 2006 11:38:39 +0200

> route-construction stuff, fix the early-media stuff. and call it SIP

good idea, but you forgot to add SIPS to the rip out list.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Dec 2006 09:40:17 -0600

> good idea, but you forgot to add SIPS to the rip out list.

Nah, I'd just make that end-to-end using Vijay's sipsec: draft.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 30 Dec 2006 16:47:36 -0800

It took me some time to parse through this but sounds like you and I  
are in 100% agreement on what an acceptable solution would look like.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 30 Dec 2006 16:50:00 -0800

On Dec 24, 2006, at 3:53 PM, Dean Willis wrote:

>
> 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?

While you are working on this, I think we should publish outbound? It  
solves a useful goal now and probably works towards the right  
direction of what you would propose as a replace for SIP 2.0.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 30 Dec 2006 16:51:25 -0800

> observe the rules of RFC 3261/18.1.1 would not be able to be received.

Yes 100% agree - we should explain the bad implications of not having  
a TCP channel open.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 30 Dec 2006 17:00:52 -0800

If the people who have been expressing strong opinions on the details  
of this proposal could comment on if they agree with these high level  
goals or not, it would be really helpful for trying to get this draft  
to move forward.

On Dec 16, 2006, at 12:33 PM, Cullen Jennings wrote:

> Practically speaking given where we are today, I would be a fan of  
> a solution that meant the following goals:
>

---

From: Adam Roach <[email-masked]>
Date: Sat, 30 Dec 2006 19:06:09 -0600

I agree 100% with #1 and #2. I find #3 to be of dubious value, although 
I see no harm in a solution that has that property as well (and you seem 
to get it for free if you satisfy #1 and #2).

/a

---

From: Ben Campbell <[email-masked]>
Date: Sat, 30 Dec 2006 19:41:29 -0600

I concur with Adam, with the caveat that any unforseen complexities  
that might be introduced by the phrase "not have the size limitations  
by using switchover" not block the work. That is, if 3 is free, or  
cheap, then great--but I would not want to significantly delay 1 and  
2 in order to get 3.

On Dec 30, 2006, at 7:06 PM, Adam Roach wrote:

> I agree 100% with #1 and #2. I find #3 to be of dubious value,  
> although I see no harm in a solution that has that property as well  
> (and you seem to get it for free if you satisfy #1 and #2).
>
> /a
>
>
>
> Cullen Jennings wrote:
>>
>> If the people who have been expressing strong opinions on the  
>> details of this proposal could comment on if they agree with these  
>> high level goals or not, it would be really helpful for trying to  
>> get this draft to move forward.
>>
>>> Practically speaking given where we are today, I would be a fan  
>>> of a solution that meant the following goals:
>>>
>>> with the known limitations that the UA would not be able to send  
>>> large requests
>>>
>>> 3) allowed deployments that wanted to use both UDP and TCP to do  
>>> so and not have the size limitations by using switchover
>>