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

[<Erkki.Koivusalo at nokia.com>]

Hi,

While my email contained a lot of questions for you rather
than a clear proposal I am not sure if we interpret each
others opinion well enough to say we agree. Anyway to clarify
my opinion - I agree with the proposal given for the poll:

> Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS
> over TCP flow (retain STUN for UDP flows).
>
> Proposal 2: Make outbound registrations over UDP flows optional for
> UAs.
>
> 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. 

Do you agree with that ?

As a summary what that would mean in terms of deployments:

- Every Outbound compliant (UA or proxy) implementation MUST 
  support TCP but MAY support UDP too.

- It will be up to the deployment to select whether TCP or UDP
  (or even both) shall be used for that specific deployment.
  Supporting UDP only would have known limitations and it would
  also mean that TCP-only implementations could not be used for
  that deployment.

Erkki 

>-----Original Message-----
>From: ext Cullen Jennings [mailto:fluffy at cisco.com] 
>Sent: 31.December.2006 02:48
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: audet at nortel.com; sip at ietf.org
>Subject: Re: [Sip] Question about Poll: Proposal relating to 
>keepalive, TCP,and UDP usage in draft-ietf-sip-outbound
>
>
>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.
>
>
>On Dec 20, 2006, at 12:18 AM, <Erkki.Koivusalo at nokia.com>  
><Erkki.Koivusalo at nokia.com> wrote:
>
>>
>> Hi Cullen,
>>
>>>> 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.
>>>
>>> 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.
>>
>> 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 ?
>>
>>> 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.
>>
>> Please remember that the proposal that you do not agree with was
>> like this:
>>
>>> Proposal 2: Make outbound registrations over UDP flows optional for
>>> UAs.
>>
>> 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
>>>> 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.
>>
>> 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
>
>

_______________________________________________
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