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

From: <[email-masked]>
Date: Fri, 1 Dec 2006 14:12:25 +0200

Hi,

You asked me to clarify my CRLF proposal, so I try to do it here.

I have been exploring ways of rescoping drafts related to Outbound
and simplifying the mechanisms within them since the limitations
of using UDP flows became apparent in this thread. I could vote
for a number of different approaches and would be happy the WG
to agree with at least one of them. Those approaches in my 
preference order are:

1. Outbound draft to re-scope itself to "Outbound TCP connection"
   draft without any support to UDP, STUN or multiple registrations.
   Multiple registrations and mid-dialog failover (using either TCP
   or UDP) to be specified within another draft.

   - This proposal as such did not raise any discussion 
     on the list, probably because it would be a dramatic
     change at a quite late stage of the draft.
   - Remarkable changes needed (but I already outlined the
     "Outbound TCP connection" draft within my earlier mail :).
     http://www1.ietf.org/mail-archive/web/sip/current/msg17495.html

2. Outbound draft to replace STUN keepalive over TCP with CRLF
   keepalive over TCP. (No impact to UDP support of Outbound)

   - This option is equivalent to your formulation, which I
     can very much agree on:

> Clearly you are suggesting that we make CRLF mandatory to implement
> for TCP.  There would be no longer any need to do STUN over TCP and
> therefore no need implement code to deal with stream-based demuxing.
> The text about sigcomp over TCP and STUN over TLS over TCP could
> also go away.

   - Some WG members already expressed their support for this
     option
   - Minor changes needed to the draft

3. Outbound draft to introduce a third optional keepalive method
   for TCP: CRLF (in addition to STUN and TCP keepalives)

   - This option would be the _last resort_ to get at least some
     benefit for TCP-based UA implementation, even if it would
     not help the proxies. Proxies would still have to support
     STUN over TCP. 
   - Minimal changes needed to the draft

> To clarify are you suggesting that an edge proxy can implement
> outbound without support for UDP flow tokens, without support for STUN
> keepalives over UDP, both, or neither?

My proposals were born "UA centric" as I am from the UA vendor camp.

Anyway if Outbound will specify both UDP and TCP as transport options,
I would believe the proxies still have to support both since the
selection of the transport is basically an UA decision (even if
assisted by DNS SRV) as it depends on if the proxy URI configured
to the UA has a transport parameter. If the proxy would not support 
UDP & STUN, how could it tell it to the UA ? Outbound would at 
least need a mechanism for that e.g. a specific response code, 
option tag or something else. Or is this yet another thing where
Outbound would rely on the UA and DNS configuration to tell the
UA to avoid using UDP ?

Considering the option to drop UDP & STUN support from Outbound
draft: I would agree that combination of UDP and STUN keepalives
does not seem to provide a practical way for NAT traversal. Keeping
UDP flows alive with STUN seems not to add value in comparison
to persistent TCP flows and I could agree dropping UDP flows from
the draft. The only problem I see here that Outbound covers also
the multiregistration mechanism, which could still be useful with
UDP e.g. in cellular access context without NAT/FWs. That is why
I have been proposing re-scoping of the drafts:

- Flow keepalive mechanisms to be specified only for TCP (one draft)
- Protocol agnostic multiregistration mechanism with mid-dialog
  failover support (another draft)

Regards,

Erkki

> -----Original Message-----
> From: ext Rohan Mahy [mailto:[email-masked]]
> Sent: 29 November, 2006 20:30
> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Re: issue with oubound and the used transport
> protocol
> 
> 
> Hi Erkki,
> 
> Clearly you are suggesting that we make CRLF mandatory to implement
> for TCP.  There would be no longer any need to do STUN over TCP and
> therefore no need implement code to deal with stream-based demuxing.
>   The text about sigcomp over TCP and STUN over TLS over TCP could
> also go away.
> 
> To clarify are you suggesting that an edge proxy can implement
> outbound without support for UDP flow tokens, without support for STUN
> keepalives over UDP, both, or neither?
> 
> thanks,
> -rohan
> 
> On 11/29/06, [email-masked] 
> <[email-masked]> wrote:
> >
> > Hi,
> >
> > >about STUN keepalive usage and discovery, since double 
> CRLF is fully
> > >backwards compatible with even RFC 2543 implementations.  I am
> > >bringing this up on the list because I hope the WG can look back on
> > >this and not make the mistake of snowballing complexity to preserve
> > >UDP parity again in the future.
> >
> > Rohan is making a valid point here and I believe in Outbound there
> > is still room for change to cater for CRLF keepalives as an option
> > to STUN keepalives over TCP.
> >
> > I am calling the WG to look back on the keepalive decision made
> > earlier for TCP and proposing that Outbound should also cover
> > CRLF keepalive option.
> >
> > Reasons for this proposal:
> >
> > >The problem I see is that we have two separate communities 
> using the
> > >outbound draft:
> > >
> > >1) folks that want to get through NATs and Firewalls in the public
> > >Internet at large - they want to use TCP and TLS with 
> double CRLF for
> > >keepalives. One "flow" is always one connection.  The milestone for
> > >this would read "Make TCP and TLS work in the Internet".
> >
> > I agree with the intents of this community. However this is not what
> > the current Outbound provides. Outbound specifies two options for
> > keepalives for reliable connections: TCP keepalive and STUN.
> >
> > These options were agreed in IETF 65, a cite from the minutes:
> >
> > Proposal:
> >    Do STUN for TCP and UDP
> >    Do CRLF for TCP and STUN for UDP
> >    TCP KeepAlive if supported, 1 or 2 otherwise
> >
> > Resolutions:
> >    OS TCP KeepAlive should be used if the client supports it.
> >    Need something more because OS TCP KeepAlive is not supported in
> > every
> >    client OS.
> >    Consensus to use STUN for UDP
> >    Consensus to use STUN for TCP, with use of OS TCP keep 
> alive above.
> >
> > In that meeting the basic assumption was that every Outbound
> > compliant client should implement both UDP and TCP even if that
> > is not explicitely mentioned in the draft. However latest -06
> > version now makes that debatable by stating:
> >
> >    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.
> >
> > In practice this seems to justify implementing "TCP only" UAs
> > what comes to the Outbound support. In that case the basic 
> assumption
> > with STUN keepalive (implement it for TCP as it is anyway needed for
> > UDP as well) would become obsolete. For implementations which can
> > not use TCP keepalive, CRLF would obviously provide a great benefit
> > without significant increase of complexity to Outbound.
> >
> >
> > P.S. Last week I made a proposal for "stripped Outbound" without
> > UDP, STUN keepalives and multiple registrations. As that proposal
> > did not receive any comments, I decided to propose this minimal
> > addition to Outbound as an alternative that might be a bit easier
> > to accept but still achieve some of the benefits.
> >
> > Regards,
> >
> > Erkki
> >
> > _______________________________________________
> > 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: "Francois Audet" <[email-masked]>
Date: Fri, 1 Dec 2006 12:43:47 -0600

I'm OK with either 1 or 2.

The difference is that with 1 we make it obvious that TCP is better.
With 2, the reader has
to figure it out by himself. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 04:12
> To: [email-masked]
> Subject: RE: [Sip] Re: issue with oubound and the used 
> transport protocol
> 
> 
> Hi,
> 
> I have been exploring ways of rescoping drafts related to 
> Outbound and simplifying the mechanisms within them since the 
> limitations of using UDP flows became apparent in this 
> thread. I could vote for a number of different approaches and 
> would be happy the WG to agree with at least one of them. 
> Those approaches in my preference order are:
> 
> > The text about sigcomp over TCP and STUN over TLS over TCP 
> could also 
> > go away.
> 
> Anyway if Outbound will specify both UDP and TCP as transport 
> options, I would believe the proxies still have to support 
> both since the selection of the transport is basically an UA 
> decision (even if assisted by DNS SRV) as it depends on if 
> the proxy URI configured to the UA has a transport parameter. 
> If the proxy would not support UDP & STUN, how could it tell 
> it to the UA ? Outbound would at least need a mechanism for 
> that e.g. a specific response code, option tag or something 
> else. Or is this yet another thing where Outbound would rely 
> on the UA and DNS configuration to tell the UA to avoid using UDP ?
> 
> draft: I would agree that combination of UDP and STUN 
> keepalives does not seem to provide a practical way for NAT 
> traversal. Keeping UDP flows alive with STUN seems not to add 
> value in comparison to persistent TCP flows and I could agree 
> dropping UDP flows from the draft. The only problem I see 
> here that Outbound covers also the multiregistration 
> mechanism, which could still be useful with UDP e.g. in 
> cellular access context without NAT/FWs. That is why I have 
> been proposing re-scoping of the drafts:
> 
> > On 11/29/06, [email-masked] <[email-masked]> 
> > wrote:
> > >
> > > Hi,
> > >
> > > earlier for TCP and proposing that Outbound should also 
> cover CRLF 
> > > keepalive option.
> > >
> > > compliant client should implement both UDP and TCP even 
> if that is 
> > > not explicitely mentioned in the draft. However latest 
> -06 version 
> > > now makes that debatable by stating:
> > >
> > > In practice this seems to justify implementing "TCP only" 
> UAs what 
> > > comes to the Outbound support. In that case the basic
> > assumption
> > > addition to Outbound as an alternative that might be a 
> bit easier to 
> > > accept but still achieve some of the benefits.
> > >
> > > Regards,
> > >
> > > Erkki
> > >
> > > 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
> > >
> > 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Aki Niemi" <[email-masked]>
Date: Mon, 4 Dec 2006 12:28:07 +0200

+1 for #1 

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 01 December, 2006 14:12
>To: [email-masked]
>limitations of using UDP flows became apparent in this thread. 
>I could vote for a number of different approaches and would be 
>happy the WG to agree with at least one of them. Those 
>approaches in my preference order are:
>
>decision (even if assisted by DNS SRV) as it depends on if the 
>proxy URI configured to the UA has a transport parameter. If 
>the proxy would not support UDP & STUN, how could it tell it 
>to the UA ? Outbound would at least need a mechanism for that 
>e.g. a specific response code, option tag or something else. 
>Or is this yet another thing where Outbound would rely on the 
>UA and DNS configuration to tell the UA to avoid using UDP ?
>
>dropping UDP flows from the draft. The only problem I see here 
>that Outbound covers also the multiregistration mechanism, 
>which could still be useful with UDP e.g. in cellular access 
>context without NAT/FWs. That is why I have been proposing 
>re-scoping of the drafts:
>
>> > earlier for TCP and proposing that Outbound should also cover CRLF 
>> > keepalive option.
>> >
>> > compliant client should implement both UDP and TCP even if that is 
>> > not explicitely mentioned in the draft. However latest -06 version 
>> > In practice this seems to justify implementing "TCP only" UAs what 
>> > addition to Outbound as an alternative that might be a bit 
>easier to