Subject: RE: [Sip] moving UDP support out of the core SIP document

From: [email-masked]
Date: Fri, 25 Oct 2002 10:36:11 +0300

Moving UDP to another document, downgrading it to a MAY in the SIP base document or whatever will not achieve anything, IMO. UA implementations will still have it (its easier to start with UDP when implementing SIP). Proxies MUST still support it.

We either deprecate it from the spec or leave it as is.

Regards,
Hisham

> -----Original Message-----
> From: ext Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Thursday, October 24, 2002 6:27 PM
> To: Rohan Mahy
> Cc: [email-masked]
> Subject: Re: [Sip] moving UDP support out of the core SIP document
> 
> 
> Rohan Mahy wrote:
> > Hello Everyone,
> > 
> > I wanted to share some thoughts that I had about removing 
> UDP from the 
> > core SIP document when we go to draft standard. 
> [...]
> > Obviously UDP is still very attractive in wireless networks 
> (due to RTT 
> > issues) and in other typically private networks with 
> well-understood 
> > delay and loss characteristics. To make most 
> implementations simpler 
> > however, I am proposing that we make unreliable transports (UDP and 
> > DCCP) of SIP optional in User Agents, and that we put the 
> UDP-specific 
> > mechanism (ex: much of the complication of the transaction 
> layer for 
> > handling retransmissions) in a separate Draft Standard document.  
> 
> Making UDP optional is fine, but I think it should stay in the core
> SIP specification.  Over the years, the SIP state machines for
> INVITE and non-INVITE transactions have evolved keeping multiple
> transports in mind.  The sourrounding text and the FSM figures
> (Figure 5, 6, 7, and 8 in rfc3261) at this point in time are well
> specified and, I beleive, well understood by the SIP community in
> general.
> 
> Divorcing UDP transport from the core spec to another RFC raises other
> questions:
> 
>    1/ Since proxies are optional in SIP and a UA can initiate
>       a session directly with its peer, will a UDP-only UA
>       insert a "Require: udp" in the request?
> 
>    2/ Issues such as reassembly, UDP response growing
>       larger than the request, etc. still remain.
> 
> If it is a choice between deprecating UDP entirely or moving it to
> another RFC, I would choose the latter.  But so long as we tacitly
> support UDP, it would be nice to have it in the base document (maybe
> degrade it to a MAY instead of a SHOULD).
> 
> Regards,
> 
> - vijay
> -- 
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Wireless Networks Group/Internet Software and Services
> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
> Naperville, Illinois 60566     Voice: +1 630 224 0216
> 
> _______________________________________________
> 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: "Alexeitsev, D" <[email-masked]>
Date: Fri, 25 Oct 2002 16:42:23 +0200

Hello All

Will then the unreliable responses became reliable?

Greetings,
Denis Alexeitsev

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 25 Oct 2002 17:36:05 +0200

Rohan, 

I don't think moving UDP support out of the core SIP document is a good idea. Doing so will probably solve many technical problems, but in my opinion doing such important changes all the time leads to interoperability problems and to additional delays in adoption of SIP as a basis for real customer solutions. SIP over UDP works fine within enterprise networks and IP-VPNs.
  
I also can remember UDP was one of our main arguments again H.323 about 3 years ago...

Thanks, Laura     

> -----Ursprungliche Nachricht-----
> Von: Rohan Mahy [mailto:[email-masked]]
> Gesendet: Mittwoch, 23. Oktober 2002 21:03
> An: Victor Paulsamy
> Cc: [email-masked]
> Betreff: Re: [Sip] moving UDP support out of the core SIP document
> 
> 
> Hi Victor,
> 
> Having no default transport does not encourage interoperability which 
> is a major goal of Internet protocols.
> 
> thanks,
> -rohan
> 
> On Wednesday, October 23, 2002, at 11:23 AM, Victor Paulsamy wrote:
> 
> > If SIP is "truly" independent of underlying transport protocols, 
> > wouldn't it
> > be appropriate to make all transports "optional"?
> >
> > Regards,
> >
> > --victor
> >
> >> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Rohan
> >> Mahy
> >> Sent: Wednesday, October 23, 2002 11:02 AM
> >> To: [email-masked]
> >> Subject: [Sip] moving UDP support out of the core SIP document
> >>
> >>
> >> Hello Everyone,
> >>
> >> core SIP document when we go to draft standard. We are probably at
> >> least one year away from going to Draft Standard. I hope 
> that during
> >> this time most implementations will support RFC3261, and therefore
> >> support TCP.  In addition, it is quite likely that when moving to 
> >> Draft
> >> Standard that the IESG will REQUIRE TLS support on SIP User Agents.
> >> This would ensure a ubiquitous hop-by-hop channel security 
> mechanism,
> >> but which requires a reliable transport (TCP or SCTP).
> >>
> >> Obviously UDP is still very attractive in wireless 
> networks (due to 
> >> RTT
> >> handling retransmissions) in a separate Draft Standard 
> document.  It 
> >> is
> >> very likely that if we did this there would also be a baseline 
> >> security
> >> mechanism for UDP as well (probably some profile of 
> IPsec).  The net
> >> effect is that SIP User Agents could also talk to each 
> other using TCP
> >> or TLS+TCP, and that User Agents with a strong preference for UDP 
> >> would
> >> have a consistent security mechanism.  Proxies would still support 
> >> both
> >> transports, so you could easily communicate between a TCP-only User
> >> Agent, and as User Agent which prefers UDP without 
> requiring the User
> >> Agent to switch over to TCP.
> >>
> >> I welcome your discussion and comments on this idea.
> >>
> >> thanks,
> >> -rohan
> >>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Oct 2002 14:35:49 -0000

Comments/questions as follows:

1)	Your proposal deals with the change of UDP from mandatory to optional at the UE. What changes, if any, would you expect to make to proxy support and handling?

2)	I did a quick look at the RFCs for TCP, and failed to work out whether all IETF compliant TCPs are now RFC 2914 compliant or not. This is because I am not sure whether the term "updates" used in the RFC index, automatically obsoletes the previuos version, and therefore is it possible to claim IETF compliance by implementing the core TCP RFC without implementing the congestion control extension. I assume that what we would require is mandatory support of a TCP that is RFC 2914 compliant.

3)	Given that you intend to retain support of UDP, although as an optional feature, I am not sure I would agree to moving it to a separate RFC. By all means move it and the supporting procedures to a normative annex, but moving it to a separate specification will lead to endless requests on the mailing list by people asking where the UDP support has gone.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 23 October 2002 19:02
> To: [email-masked]
> I wanted to share some thoughts that I had about removing UDP 
> from the 
> least one year away from going to Draft Standard. I hope that during 
> support TCP.  In addition, it is quite likely that when 
> moving to Draft 
> This would ensure a ubiquitous hop-by-hop channel security mechanism, 
> issues) and in other typically private networks with well-understood 
> delay and loss characteristics. To make most implementations simpler 
> mechanism (ex: much of the complication of the transaction layer for 
> document.  It is 
> very likely that if we did this there would also be a 
> baseline security 
> mechanism for UDP as well (probably some profile of IPsec).  The net 
> effect is that SIP User Agents could also talk to each other 
> using TCP 
> or TLS+TCP, and that User Agents with a strong preference for 
> UDP would 
> have a consistent security mechanism.  Proxies would still 
> support both 
> Agent, and as User Agent which prefers UDP without requiring the User