RE: [Sip] I-D on handling large UDP responses

["Samir Srivastava" <samirsr at nortel.com>]

Hi Scott,

I was referring the work being done PMTU group. 
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-10.txt
I didn't look details of the draft earlier. It does imposes new
requirements. 
Yes. you are correct Path MTU doesn't help completely in the view of
alternate routes etc. It is less/more similar in the value as of
diagnostic tools. As they MAY not follow the same SIP path as the actual
requests. 

The proposed mechanism can be used only for REQ/RSP. How can we address
the problems caused in 200 OK (Offer) and ACK (Answer) due to UDP
between some proxies ? In the current model,  UAC gets the complete
Large 200 OK (with delayed arrival of 140/141 or you change the current
solution w.r.t. 140/141), but ACK follows the different IP hops etc...

We might be doing congestion handling in SIP for UDP transports in
future, where some of it is provided by other transports. In my purist
mind, SIP messages are becoming huge, so UDP is no more relevant. UDP
was taken initially, as it was simple to transport short SIP message at
that time.

IMHO, Simplicity wins and It is difficult decision for UDP.

Thx
Samir

-----Original Message-----
From: Scott Lawrence [mailto:slawrence at pingtel.com] 
Sent: Sunday, October 15, 2006 11:10 AM
To: Srivastava, Samir (SC100:8826)
Cc: sip at ietf.org
Subject: RE: [Sip] I-D on handling large UDP responses

On Sat, 2006-10-14 at 18:37 -0500, Samir Srivastava wrote:
> If we really want a fool proof solution, then we should look into Path

> MTU discovery work. More complications.

I'm not sure which work you're referring to, but I don't think that
you're going to get much traction with trying to do more messages before
an INVITE just to learn something about the Path MTU (and even if you
do, that doesn't ensure that the INVITE will follow the exact same
path).

> The more, we want to fix unreliability/fragmentation etc in SIP, the 
> more problems we are inviting.
> 
> In spite of current UDP installed base, I am for deprecating UDP. Do 
> we really need to have exception for MESSAGE where it is useful ?
> Unreliable transports raises the another question of DTLS.

>From a practical point of view, getting rid of UDP completely is just
not going to happen.  Commercial products at least just have to live
with it.  We should work on making the better transports more widely
implemented and otherwise more attractive, but in the mean time it's
important that we be able to diagnose when and how UDP is causing
problems.


--
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:slawrence at pingtel.com
  sipXpbx project coordinator - SIPfoundry
http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip