Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02

From: "Andrew Burr" <[email-masked]>
Date: Thu, 15 Mar 2007 14:12:04 +0000

The original SIP would have sufficed to say that SIP runs on a reliable 
transport. Another specification titled "SIP UDP adaptation layer" could 
have specified retransmission and backing off retransmit timers and 
fragmentation.

SIP message size may be bloated by tunneling session related information 
thru SIP using the attachment mechanism. Controlling SIP header size with an 
arbitrary limit is perhaps an ideal way to control header fields and prevent 
bloating of the SIP core which should never exceed 65K; but it's unfeasible 
to limit the size of what is tunneled in attachments.

"SIP UDP adaptation layer" needs to handle the UDP limitations with a 
fragmentation and reassembly mechanism.

Perhaps it is short sighted to tie-up SIP with a specific 
transport/security/media protocol, if SIP has to head off a ledge then why 
not disentangle it from transport/security/media issues and reduce SIP to 
the responsibilities of session offering whatever that session may be and 
make SIP generic enough to work for both SIP and TCP transports.

Andrew

----Original Message Follows----
From: Spencer Dawkins <[email-masked]>
To: [email-masked]
Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02
Date: Thu, 15 Mar 2007 07:04:01 -0500

If I understand correctly, Erkki is saying that we're driving off a cliff, 
and Jonathan is saying that we haven't given anyone outside the IETF an 
indication that we're going to change direction, so suddenly deprecating UDP 
isn't realistic.

I do see what both Jonathan and Erkki are saying, and I think both have 
valid points.

Perhaps it would be worth putting together a short I-D, either as 
Informational or (probably better) as BCP, to say:

- we know 3261 requires TCP support,

- we know many SIP devices were deployed without it and work today,

- we know that we are in the process of developing new standards-track 
specifications that will significantly increase the size of SIP messages,

- we know that IP-level fragmentation will increase, and is likely to be a 
problem,

- so if you have already deployed UDP-only SIP, this would be a good time to 
start planning for TCP support".

I can name some specifications that qualify here (Erkki mentioned ICE, and 
GRUU was discussed earlier this week), but is there a complete list that 
could be included, just off the top of anyone's head?

This is probably less than two pages of non-boilerplate text, even including 
the list. Could it help the current situation?

Spencer

----- Original Message ----- From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 15, 2007 5:44 AM
Subject: RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-02

Hi,

>Listen, if folks are running a real SIP network and they are using
>outbound, and they elect to use UDP knowing that this problem can
>happen, then the consequence is that things won't work for large
>messages. Thats the consequence of making this choice, and we are
>providing them a way to know that it has actually happened.
>
>I expect in reality, providers will know exactly how big each
>message will be since their clients are controlled by them and
>they have tested them with exactly the messages they will emit.
>So, this error code is really likely to show up in pre-deployment
>testing, at which point you either switch to tcp, or live with the
>risk.

You are making quite strict assumptions in what you are saying.
In practice this model would have the following limitations:

- As ICE is likely to increase the size of the SDP body
  of INVITE by 200-400 bytes, when applying the full set
  of NAT traversal method the probability grows that the
  size of the INVITE request ultimately hits the MTU limit.

- UDP would only apply to closed environments (walled gardens)
  where the service provider is able to certify all the
  connected clients and control the number of proxies in
  any possible route within the network (to limit the number
  of Via and Record-Route headers). Furthermore there can
  not be any direct SIP connectivity to rest of world.
  I admit that this may apply to how SIP is used e.g. in
  enterprises with their IT departments testing and validating
  all pieces of equipment or VoIP operators exclusively providing
  the UAs for their customers and having their PSTN gateways
  towards the rest of the world.

- It would preclude consumers connecting the service with
  their favourite new softphone just installed to their PC.

- Only the services certified by the service provider could
  ever be applied.

- Or in best case if the service provider is able to control
  the types of NATs applied within the network so that those
  would be able to cope with IP fragmentation, in this case
  UDP could be used even for messages larger than MTU.

If the provider is happy with all these limitations, yes
then Outbound with UDP could make sense for the deployment.
I still have the feeling that there are two many 'if's
preventing this scheme to be robust and reliable. Too
many things might simply go wrong.

>>>- folks whose tcp scale is a problem need to FIX it,
>>>since there is this issue with UDP outbound.
>>
>>I agree. Said that, it seems to me once again that the idea to
>>keep UDP within the Outbound draft _is_ a bad idea.
>
>I'm trying to be pragmatic.
>
>THe *reality* is that there IS still a lot of UDP out there. And IETF
>producing specifications that ignore this is just ignoring reality.
>It'll just mean that folks ignore sip-outbound.

It is hard for me to understand that while all the UAs and proxies
have to be modified in order to support Outbound, upgrading for
TCP support would be as difficult as it appears to many. For the
UA point of view, having a IP stack with TCP support integrated
to SIP does not appear much more difficult than supporting STUN
keepalives. For the proxy point of view I am hearing evidence
from multiple independent research projects that scaling TCP
would not be impossible to solve (at least for Linux servers).
TCP could even help some of the scalability problems since it
uses even more lighweight keepalive schemes as STUN and the
frequency of keepalives is lower in TCP compared to UDP.

>The best we can do is clearly document the ongoing and
>increasing troubles of UDP, so that a provider or enterprise
>can make an educated choice and make
>the move to tcp based on the evidence we've provided.

What I am worried about is that the message IETF makes in
SIP Outbound draft (only one paragraph in the spec giving
a hint that there may be a problem) is very vague. Yes it
has been discussed in the list, but still providing extensive
UDP machinery in Outbound (STUN keepalives etc.) would create a
mixed message and delay the whole proxy industry to face the
issue and start actions to fix the TCP scalability problem.

Also it would call the vendors to provide more complex
solutions as necessary. Here I mostly refer to STUN
keepalives needed for UDP vs the CRLF/TCP keepalives
only needed for TCP. This also can delay how soon
Outbound really hits the market in large scale.

About the dynamic fix with reg-event:

>>>An alternative to dynamically repair it is to use the
>>>reg-event package for the notification, since we already have that.
>>>..... The home proxy/registrar would generate a
>>>notification to the client telling it to re-register over tcp.
>>
>>The problem is that the size of the simplest reg-event notifications
>>I have seen are close to 1000 bytes. The ultimate size will depend
>>on a number of things but there is a risk for the NOTIFY to become
>>bigger than MTU so that it can not be delivered over UDP. There is
>>a potential chicken and egg problem in this proposal.
>
>Well, close to 1000 is still under the MTU by plenty, so it works fine.

I agree that typical reg-event NOTIFYs are smaller than MTU,
but there is not really any upper limit so there is a chance
of fatal failure. As an example consider a case where a person
called Gordon had registered his wireless PDA arrives to office
and registers now also from his PC using Outbound and UDP:

-> REGISTER
<- 200 OK
-> SUBSCRIBE
<- 200 OK
<- NOTIFY

In this case the full reg-event notification could be over
1300 bytes e.g. like this one:

Request-Line: NOTIFY sip:[email-masked]:12363
SIP/2.0
Call-ID: VZ8iKyeJoIc2TwYRTcSB5j_bBPdQ3x
Contact: <sip:registrar.yourserviceprovider.com>
Content-Type: application/reginfo+xml
CSeq: 1 NOTIFY
From: "Gordon Maverick"
<sip:[email-masked]>;tag=poqw089q23oijf0+as9e
Max-Forwards: 69
To:  "Gordon Maverick"
<sip:[email-masked]>;tag=kh0h5eib81hc7r1i1sqt
Via: SIP/2.0/UDP
proxy.yourserviceprovider.com:5060;branch=z9hG4bK2147483647
Via: SIP/2.0/UDP
registrar.yourserviceprovider.com:5060;branch=z9hG4bK2134765492
Event:  reg
Subscription-State: active;expires=3600
Content-Length: 649
Message body
<?xml version="1.0" encoding="UTF-8"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0"
state="full">
<registration aor="sip:[email-masked]"
id="a100" state="active">
<contact id="980" state="active" event="created"
duration-registered="0">
<uri>sip:[email-masked]:12363</uri>
<display-name>Gordon Maverick</display-name>
</contact>
<contact id="977" state="active" event="registered"
duration-registered="1204" call-id="Vqpwoidf034i0_jv0wj090vasdfj">
<uri>sip:[email-masked]:14568</uri>
<display-name>Gordon Maverick</display-name>
</contact>
</registration>
</reginfo>

Do you believe we should impose some limitations about how
the reg-event notifications can look like if sent for UAs
using Outbound with UDP ? Or introduce some exceptional
practices to send partial notification right after SUBSCRIBE
asking the client to register with TCP if the full notification
would be bigger than MTU ? Sorry to say but to me this mechanism
appears as broken.

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

_________________________________________________________________
Have Some Fun Out Of The Sun This March Break 
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!142

_______________________________________________
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: "Spencer Dawkins" <[email-masked]>
Date: Sun, 18 Mar 2007 04:32:13 +0100

> have specified retransmission and backing off retransmit timers and 

So, backing up slightly - is this something we can do NOW, or is it 
something we should have done a long time ago and can't do now?

My concern is that we need to tell people something about UDP fairly soon, 
or we'll be having the same "but what about all the UDP-only devices?" 
conversation next year.

And the year after that.

Spencer

> thru SIP using the attachment mechanism. Controlling SIP header size with 
> an arbitrary limit is perhaps an ideal way to control header fields and 
> prevent bloating of the SIP core which should never exceed 65K; but it's 
> unfeasible to limit the size of what is tunneled in attachments.
>
> indication that we're going to change direction, so suddenly deprecating 
> UDP isn't realistic.
>
> - so if you have already deployed UDP-only SIP, this would be a good time 
> to start planning for TCP support".
>
> This is probably less than two pages of non-boilerplate text, even 
> including the list. Could it help the current situation?
>
> Spencer