Subject: RE: [Sip] Re: issue with oubound and the used transport protocol

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 1 Dec 2006 06:59:05 +0100

Hi, 

In my case the UA DOES realize that the TCP connection has died, and
creates a new TCP connection.

So, since the UA already knows that a new TCP connection (and therefor a
new NAT binding) has to be created the XOR-MAPPED-ADDRESS is not needed.

My issue was whether the UA uses the XMA information for something else
than detecting that the binding has changed, but for outbound it seems
like it doesn't, so there is no outbound functionality "suffering" if
the UA doesn't get the XMA.

Regards,

Christer

> A NAT won't create a new TCP binding unless it sees a SYN.  
> If the NAT reboots, the client will detect that the 
> connection has died, and won't be able to send any traffic 
> (SIP or STUN) until it opens a new connection explicitly.  An 
> XOR-MAPPED-ADDRESS attribute over TCP is completely useless.
> 
> thanks,
> -rohan
> 
> On 11/30/06, Christer Holmberg (JO/LMF) 
> <[email-masked]> wrote:
> >
> > Hi,
> >
> > >I still need to test this, but I suspect that the STUN 
> response won't 
> > >even arrive over TCP when the NAT has rebooted and uses a 
> different 
> > >source port for forwarding it. The server then cannot 
> match it with 
> > >an existing 5-tuple socket connection and will probably send a RST
> >
> > Maybe I missunderstood, but won't the STUN request create a new 
> > binding, in case the NAT has rebooted?
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> > >
> > > Regards,
> > > Jeroen
> > >
> > > Christer Holmberg (JO/LMF) wrote:
> > > > Hi,
> > > >
> > > > A question for clarification:
> > > >
> > > > The STUN response provides the UA with certain useful 
> information 
> > > > (XOR-ADDRESS etc), which the UA can use to see whether 
> a NAT has 
> > > > rebooted etc. I assume that information is not needed when
> > > using TCP?
> > > >
> > > > Regards,
> > > >
> > > > Christer
> > > >
> > > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Francois Audet [mailto:[email-masked]]
> > > >> Sent: 30. marraskuuta 2006 19:45
> > > >> To: [email-masked]
> > > >> Cc: [email-masked]
> > > >> Subject: RE: [Sip] Re: issue with oubound and the used 
> transport 
> > > >> protocol
> > > >>
> > > >> Didn't we agree way back NOT to use PING, CRLF, etc., and use 
> > > >> STUN instead?
> > > >>
> > > >> Why is this debate being re-opened?
> > > >>
> > > >> Remember: I favored the non-STUN TCP approach. However, if
> > > we can't
> > > >> stick to a decision, we'll debate this forever. It already
> > > feels like
> > > >> it.
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Jeroen Van Bemmel [mailto:[email-masked]]
> > > >>> Sent: Thursday, November 30, 2006 08:02
> > > >>> To: Christer Holmberg (JO/LMF); Rohan Mahy; 
> > > >>> [email-masked] Cc: [email-masked]; [email-masked]
> > > >>> Subject: RE: [Sip] Re: issue with oubound and the 
> used transport 
> > > >>> protocol
> > > >>>
> > > >>> Having implemented STUN over TCP/TLS I can now say that
> > > it does add
> > > >>> significant complexity while providing little benefit 
> over CRLF
> > > >>>
> > > >>> STUN allows one to detect NAT reboot, but a CRLF will also
> > > >> trigger a
> > > >>> connection reset in such a case. STUN breaks framing in
> > > >> case the other
> > > >>> side does not support it. It uses significantly more
> > > bandwidth than
> > > >>> CRLF. It requires a lot of text to describe.
> > > >>>
> > > >>> In summary, I support CRLF for TCP, and would suggest to do
> > > >> STUN only
> > > >>> for UDP (i.e. its original purpose). STUN for TCP is 
> a bad idea
> > > >>>
> > > >>> Regards,
> > > >>> Jeroen
> > > >>>
> > > >>> PS Edge proxy choosing the mechanism: not a good idea
> > > >> either, better
> > > >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP)
> > > >>>
> > > >>> -----Oorspronkelijk bericht -----
> > > >>> Van: "Christer Holmberg (JO/LMF)" 
> > > >>> <[email-masked]>
> > > >>> Aan: "Rohan Mahy" <[email-masked]>;
> > > [email-masked]
> > > >>> CC: [email-masked]; [email-masked]
> > > >>> Verzonden: 30-11-06 13:56
> > > >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used
> > > transport
> > > >>> protocol
> > > >>>
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Why don't we let the edge proxy choose which keep-alive
> > > >> mechanism to
> > > >>> use?
> > > >>>
> > > >>> The outbound spec should now say (I haven't had time to
> > > >> check, but I
> > > >>> hope me and Rohan agreed to add it :) that the edge proxy
> > > >> can insert
> > > >>> the keepalive parameter in the Path header.
> > > >>>
> > > >>> So, we define a "CRLF" value for the parameter, and the
> > > >> edge proxy can
> > > >>> then use that value for TCP flows.
> > > >>>
> > > >>> Of course, if the UA is not mandated to implement all kind of 
> > > >>> keep-alives, it will also have to be able to indicate to the 
> > > >>> edge proxy which keep-alive mechanisms it support.
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Christer
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > >>> This list is for NEW development of the core SIP Protocol Use 
> > > >>> [email-masked] for questions on current sip 
> > > >>> Use [email-masked] for new developments on the 
> application of 
> > > >>> sip
> > > >>>
> > > >>
> > > >> _______________________________________________
> > > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > >> This list is for NEW development of the core SIP Protocol Use 
> > > >> [email-masked] for questions on 
> current sip Use 
> > > >> [email-masked] for new developments on the application of sip
> > > >>
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol Use 
> > > > [email-masked] for questions on 
> current sip Use 
> > > > [email-masked] for new developments on the application of sip
> > >
> > >
> >
> > _______________________________________________
> > 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: Hisham Khartabil <[email-masked]>
Date: Mon, 4 Dec 2006 15:31:52 +0100

On Nov 20, 2006, at 2:23 PM, Aki Niemi wrote:

> ma, 2006-11-20 kello 10:02 +0100, ext Christer Holmberg (JO/LMF)
> kirjoitti:
>>>
>>> Please enumerate the cases.
>>>
>>> Unless there are concrete cases where TCP simply does not
>>> work, I would strongly recommend we drop UDP from outbound
>>> altogether. Remember, UDP already kind of works in presence
>>> of NAT; this is why we have for instance rport.
>>
>> Outbound is not an alternative to rport. Outbound provides you with
>> keep-alives, and multiple flows (in case one fails), which rport
>> doesn't. rport simply tells you where to send some stuff.
>
> I never said it was a replacement. However, the world is full of
> deployments that use UDP and work through NAT just fine (kind of); some
> use rport, some use something else. Clearly, these folks aren't holding
> out their deployments waiting for outbound to finish.

No, but we do so by breaking SIP rules. Something we want to move away 
from.

Hisham

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 07 Dec 2006 07:26:13 +0000

I like this proposal. It makes it very attractive to implement outbound for
TCP, whilst still having the possibility of doing UDP if you really want to.
Don't forget that one of the use cases for outbound is TLS, where there is
no certificate deployed at the UA. For this case, outbound is needed
regardless of the presence of NAT/firewall. Having to do STUN keep-alive for
this case just because it is needed for the UDP NAT/firewall case is rather
burdensome.

John 

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: 07 December 2006 05:16
> To: Cullen Jennings
> Cc: Rohan Mahy; Fredrik Thulin; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Re: issue with oubound and the used 
> transport protocol
> 
> 
> On Dec 6, 2006, at 16:33, Cullen Jennings wrote:
> > I find this whole conversation way off base. If people 
> would like to 
> > deprecate UDP, go work on a document to explain that and 
> feel free to 
> > bring it to the WG. In the mean time, SIP is specified over 
> both UDP 
> > and TCP.
> 
> To be more specific, SIP is currently specified so it can use UDP for 
> requests smaller than 1300 bytes.  It is specified so it can use TCP 
> for requests of any size.
> 
> Some people have suggested that user agents SHOULD be able to 
> send and 
> receive requests larger than 1300 bytes when using the outbound 
> mechanism.  This seems like a logical requirement.  Are you objecting 
> to this requirement Cullen?
> 
> For the sake of this discussion, lets assume that we have 
> consensus on 
> this requirement.  What are the implications?  Well, most UAs 
> implementing outbound are doing so because they are behind a NAT or a 
> firewall and will not be able to receive inbound TCP flows.  
> These UAs 
> will need to establish a TCP flow if they want to meet this 
> requirement 
> of receiving requests larger than 1300 bytes. The logical normative 
> statement is to say a UA which cannot (or suspects that it cannot) 
> receive an inbound TCP flow from its outbound proxies SHOULD open at 
> least one TCP or TLS flow to a server in its outbound-proxy-set.
> 
> A few people on this mailing list have suggested that for any user 
> agent that actually bothers to open a TCP flow, there is no reason 
> whatsoever to open a corresponding UDP flow. I wholeheartedly agree 
> with them.
> 
> The problem is that this thread strikes right at the heart of our 
> community's dilemma. We have a large body of people who have deployed 
> UDP almost exclusively and effectively ignore the MUST use 
> (and several 
> even ignore the MUST implement) TCP statements in our core spec.  
> Ironically, one of the problems which prevents realistic 
> interoperable 
> deployment of TCP-based SIP implementations is the lack of a 
> standardized mechanism for doing outbound.  [Dean also 
> identified some 
> other problems often faced when deploying TCP with programs that use 
> "obvious" (Dean actually said "naive") textbook implementation 
> techniques.]
> 
> I think that a large number of the core spec contributors and 
> seasoned 
> implementors now recognize that there are many non-academic problems 
> with SIP over UDP and that some day we will want to either 
> deprecate or 
> at least seriously curtail the use of UDP.  Like a very heavy drinker 
> we know it will be good for us to kick the habit.  We are not 
> quitting 
> today. The question before us is are we going to do something in 
> outbound that makes it harder for us to quit in the future.
> 
> My concrete proposal is the following:
> - make CRLF the only keepalive mechanism for TCP and TLS over 
> TCP flow 
> (retain STUN for UDP flows)
> - make outbound registrations over UDP flows optional for UAs
> - include 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 (the 3GPP 
> exception).  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.
> 
> What's in it for the TCP crowd?  They get to implement 
> outbound with no 
> UDP if they so desire.  They don't have to implement STUN 
> over TCP. The 
> draft clearly explains why TCP is the technically preferred solution.
> 
> What's in it for the UDP crowd? They get outbound behavior (at least 
> for requests <1300 bytes) specified in the core draft for UDP.  They 
> can keep doing what they are doing, but with STUN keepalives 
> if the UA 
> and edge proxy both support it.
> 
> What's not to like?
> thanks,
> -rohan
> 
> 
> > Most deployments only use UDP, some only use TCP, and I 
> suspect there 
> > are some that do both but I am not aware of them. Outbound as it is 
> > seems very consistent with 3261 in that it allows a system 
> to use TCP 
> > or UDP. Keeping this in mind few comments inline ....
> >
> > On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote:
> >
> >> Let's go back to the original topic - what should the 
> draft say about 
> >> the transport protocol in relationship with outbound
> >>
> >> The major use case for outbound is UAs behind NAT / 
> firewalls. Many 
> >> of such devices have known issues with UDP fragmentation, 
> so for many 
> >> environments TCP will need to be used for messages larger than the 
> >> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts 
> >> the limit at 1300).
> >
> > These known issues with fragmentation might be less common than you 
> > think however, outbound does not have anything to do with 
> MTU issues. 
> > It does not try and solve them and it does not make them worse.
> >
> >>
> >> If you start from the requirement "MUST only use UDP", 
> then there is 
> >> little room for constructive discussions. For UDP-only to work you 
> >> will need to ensure that messages either stay below path MTUs, or 
> >> disallow NAT. This implies significant limitations for your 
> >> deployment environment. In any case, this is not a setup that 
> >> outbound should focus on.
> >
> > MTU is a problem regardless of NATs or Firewalls. 
> Fragmented packets 
> > do manager to traverse most NATs and Firewalls.
> >
> >>
> >> In the general case, there are environments that have to deal with 
> >> NAT and messages larger than path MTU. This is what outbound was 
> >> written for. This also implies a UA that supports TCP. 
> Given that the 
> >> UA supports TCP and the fact that presence of devices like 
> stateful 
> >> firewalls cannot reliably be detected, the UA SHOULD use TCP (or 
> >> another connection oriented transport). If in addition the UA 
> >> supports TLS, it SHOULD use TLS.
> >
> > Again, this topic is not really about outbound. If you 
> think a 3261 UA 
> > that supports both UDP and TCP SHOULD use TCP, that is a 
> fine argument 
> > to go make in the discussion about use of TCP and UDP but 
> it seems to 
> > be an independent choice from anything to do with outbound.
> >
> >
> > Cullen <with my individual hat on>
> >
> >>
> >> I think this is sufficient
> >>
> >> Regards,
> >> Jeroen
> >>
> >> Fredrik Thulin wrote:
> >>> Hisham Khartabil wrote:
> >>>>
> >>>> On Dec 5, 2006, at 3:33 PM, <[email-masked]> wrote:
> >>> ...
> >>>>> I personally believe going TCP-only would actually help 
> deployment
> >>>>> rather than hinder it, but I'd be really interested to 
> be convinced
> >>>>> otherwise.
> >>>>
> >>>> I could ask you the converse. I'd really be interested to be
> >>>> convinced how TCP deployment improves scalability.
> >>>
> >>> To name two things where TCP would provide better 
> scalability than 
> >>> UDP
> >>> for a SIP service provider :
> >>>
> >>>   1) Say that your services maximum capacity for 
> non-INVITEs is 1000
> >>>      requests per second. If you get 2000 in a single second, you
> >>>      won't only have to deal with all those 2000 
> requests, but also
> >>>      with quite a few retransmissions sent after 500ms. 
> With TCP, the
> >>>      wall isn't as dense.
> >>>
> >>>   2) UDP sockets have a shared receive buffer, most 
> commonly around
> >>>      64k I believe (even though the maximum seems to be 256k on
> >>>      FreeBSD at least). With SIP messages of perhaps 700 bytes on
> >>>      average, you have to be able to move messages out of 
> that buffer
> >>>      pretty fast to keep it from filling up. A full buffer means
> >>>      dropped packets. I've also heard that on for example Linux,
> >>>      every packet actually occupies an even 2k (or was it 
> 4k) in the
> >>>      buffer, so 64k buffer is actually at most 32 packets 
> at a time.
> >>>
> >>> And then there are of course other aspects than 
> scalability where UDP
> >>> is an inferior solution, most notably security related 
> things like 
> >>> for
> >>> example spoofed CANCELs (which can't be challenged, 
> RFC3261 #22.1).
> >>>
> >>> /Fredrik
> >>>
> >>>
> application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 8 Dec 2006 10:10:17 -0800

On Nov 30, 2006, at 9:45 AM, Francois Audet wrote:

> Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN
> instead?
>
> Remember: I favored the non-STUN TCP approach. However, if we can't
> stick to a decision,
> we'll debate this forever. It already feels like it.

I was thinking, wow, we won't really repeat the exact same  
conversation over again. But then I read the thread below and  
realized that I can not imagine this conversation going any  
differently than the last several times we have done it.

On Dec 8, 2006, at 7:40 AM, Rohan Mahy wrote:
>
> On Dec 8, 2006, at 5:57, Christer Holmberg ((JO/LMF)) wrote:
>
>>
>> Hi,
>>
>> A couple of questions:
>>
>> 1. What was the reason(s) the CRLF solution is not suitable for UDP?
>
> You can't detect that a NAT has rebooted and your binding has  
> changed over UDP unless your message contains the reflected address.
>
>> 2. Even for UDP it can be possible to use lower layer keep-alive
>> mechanisms, e.g. when UDP encapsulated IPSec, is used, so I think one
>> should be allowed to use that instead of STUN.
>
> There is not MUST USE for keepalive=stun, so I think this is  
> tacitly permitted anyway.
>
> thanks,
> -rohan
>
>> Regards,
>>
>> Christer

---

From: "STURA, Marco, VF-IT" <[email-masked]>
Date: Mon, 11 Dec 2006 11:34:25 +0100

> 3GPP IMS networks, if such are deployed in the "puristic" form, may be a different 
>thing, but even there TCP is a better option. 

I don't think such "puristic" deployments exist to date. In general I do agree with Markus that TCP would be a better option in 3GPP IMS networks too.

Br,
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: lunedì 11 dicembre 2006 10.24
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Re: issue with oubound and the used transport protocol

Hi,

I agree with Francois here. Even though there may be some performance limitations for TCP in the current implementations, I think that almost everyone agrees that it is the way to go in the long run. This is why it would be good to have an optimal solution for Outbound/TCP, instead of trying to keep consistency between UDP and TCP.

It would be great if we could do UAs supporting Outbound with TCP/TLS only, and leave mess with message size, fragment handling, UDP-based security, 20 second NAT keepalive timers etc. behind us. This may not be realistic yet, if there are enough service providers who will demand UDP (since unfortunately there are e.g. SBCs that do not even have a proper
TCP support at all), but that should be the aim.   

3GPP IMS networks, if such are deployed in the "puristic" form, may be a different thing, but even there TCP is a better option. 

Markus

>From: ext Francois Audet [mailto:[email-masked]]
>Sent: 09 December, 2006 02:31
>To: Cullen Jennings; Hisham Khartabil
>Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus (Nokia-SIR/Espoo); 
>Peter Leis; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis; Keith Drage
>Subject: RE: [Sip] Re: issue with oubound and the used transport 
>protocol
>
>Cullen,
>
>My best guest on why this is happening is that people used to be 
>thinking more about UDP than TCP and consequently expressed a 
>preference for the STUN approach.
>
>It seems now that more people are paying attention to TCP because of a 
>bunch of issues with UDP (including fragmentation, and TLS usage 
>catching up since it took us so long to finalize this document). Many 
>are reaching the conclusion that the CRLF approach makes more sense for 
>TCP.
>
>It seems that Rohan's last proposal of using CRLF for TCP, and STUN for 
>UDP to be reasonable and logical. And it seems to have lots of support 
>on the list.
>
>
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Friday, December 08, 2006 09:43
>> To: Hisham Khartabil
>> Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus
>(Nokia-TP/Espoo);
>> Peter Leis; Aki Niemi; Dean Willis; Keith Drage
>> Subject: Re: [Sip] Re: issue with oubound and the used transport 
>> protocol
>> 
>> 
>> On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote:
>> 
>> > Please, lets not wait until March to discuss this. We can
>> take a hum
>> > here on the mailing list
>> 
>> We had most of a room hum the other direction so, which did leave me 
>> thinking, assuming we don't get a single no on the the list,
>how many
>> yes do think the chairs should be looking for to overturn this? I 
>> don't really want to know the answer to this as this is
>something that
>> only the chairs need to figure out but it is an interesting question 
>> to think about when thinking about reopening this.
>> 
>> And just so people understand my position on this, if we reopen this 
>> issue, I will be voting for whichever path I think can get the draft 
>> to the IESG the soonest. I've implemented both and they are both 
>> trivial to implement. I really believe that what we need is to stop 
>> delaying this draft.
>> 

_______________________________________________
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