Subject: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP)

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 06 Dec 2006 16:05:31 -0800

I followed a little bit the discussion about the usage of UDP and TCP
with Outbound, and my opinion is that both UDP and TCP need to be supported.

Obviously UDP alone cannot be used with Outbound because if there is a
potential fragmentation in a request sent to the UA or in a response
sent from the UA, there is no way to switch to a congestion controlled
transport.

So we (Packet8) did some tests by comparing UDP and TCP, and we found
that, even by using advanced coding techniques, UDP uses less resources
than TCP.

So we tried a combination of temporary TCP and UDP.  The idea is that
TCP is really needed only for few types of transactions on a real life
endpoint.  One of this transactions is an INVITE, because the size added
by the SDP, especially when carrying ICE attributes and audio+video+text
sessions, nearly always results in a packet size that is over the MTU.
Another case is the full state NOTIFY for the reg-event that is to be
received after sending a SUBSCRIBE (partial state NOTIFY are OK).
REGISTER, even fully loaded with extensions are generally OK.

We retried our tests and found that using temporary TCP for the INVITE
and full state NOTIFY transaction with UDP for all the other
transactions was using more ressources than UDP alone, but still less
than using only TCP.

So I wrote this I-D that describe a solution to implement this mixed
UDP/TCP as an extension to Outbound.  This is really a first draft, as
there is a lot missing (e.g. how an edge proxy knows that the UA
supports this, etc...), but I wanted to know if there is interest in
working on this direction.

Until the draft appears in the archives, a copy can be found here:

http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-00.txt

Questions and comments are welcome.

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [ RFC1855-compliant space for rent]
Work: [email-masked]            [                                 ]

_______________________________________________
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: Wed, 6 Dec 2006 19:38:04 -0600

Maybe I'm missing something in this keep-alive and UDP/TCP debate.

I find the obsession with performance out of place.

All the evidence that I've seen is that in a commercial product, that
the server is 
really not spending much of it's cycles doing keep-alives. The evidence
is also that
if you are doing keep-alives, the transport will matter even less.

We keep going back to the same issues, with the same conclusions
regarding
performance: the keep-alive mechanism doesn't really matter, and the
transport 
doesn't matter either.

Yet somehow, we keep agonising over this. In the real world, people
keep on using PING/OPTIONS/short-lived-REGISTER/CRLF/STUN and whatever.

Let's pick something and move on.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 06 Dec 2006 20:50:44 -0800

> I find the obsession with performance out of place.

Performance is important at least for service providers, because they
have to buy the hardware to run the servers, pay the licenses per CPU,
pay the datacenters cost, pay the sysadmins to run the servers and pay
the managers to manage the sysadmins.

So yes, performance is important, but perhaps not for the hardware
vendors, the software vendors and the sysadmins.

---

From: "Aki Niemi" <[email-masked]>
Date: Tue, 12 Dec 2006 12:19:17 +0200

>Performance is important at least for service providers, 
>because they have to buy the hardware to run the servers, pay 
>the licenses per CPU, pay the datacenters cost, pay the 
>sysadmins to run the servers and pay the managers to manage 
>the sysadmins.
>
>So yes, performance is important, but perhaps not for the 
>hardware vendors, the software vendors and the sysadmins.

This is all relative.

Your draft seems to add enormous amounts of complexity -- to both UAs and
outbound proxies -- to get around what you claim to be a performance
bottleneck. First of all, I disagree with the assumption that running TCP
only is that much more of a burden. And secondly, I believe complexity is
the biggest enemy here, much more so than the performance concerns. 

Cheers,
Aki

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 12 Dec 2006 09:41:39 -0800

Aki Niemi wrote:
> bottleneck. 

No, this draft is not about performance.  This draft is about be able to
use UDP or TCP with Outbound, i.e. be compliant with RFC 3261 (Section
18: "All SIP elements MUST implement UDP and TCP."

The performance issue is about implementers be able to use UDP or TCP or
whatever they want, as explicitly authorized by RFC 3261.

> First of all, I disagree with the assumption that running TCP
> only is that much more of a burden. 

This is an implementation problem. Outbound MUST support TCP and UDP
because RFC 3261 says it.  The only thing I ask is to let implementers
do their job.

> And secondly, I believe complexity is

Well, complexity is relative, and again it is not about performance, but
about compliance.

I am currently implementing my two drafts about fragmentation in my
endpoints and servers, so I will have a better idea of the real
complexity soon.  I will eventually ask the chairs for a slot at the
68th IETF meeting to present this.

---

From: <[email-masked]>
Date: Wed, 13 Dec 2006 08:18:21 +0200

Hi,

>Well, complexity is relative, and again it is not about 
>performance, but about compliance.

This reasoning sounds very confusing to me.

Is your suggestion really like this:

a) You do not actually have any technical reason why Outbound
   must support UDP, not even the performance would do. 

b) The only reason for Outbound to support UDP would be its
   full compatibility to RFC 3261.

If this is the case, I would ask WG to consider this reasoning
very carefully and if it makes any sense or not. To me it sounds
like: "UDP is actually not needed but because the WG decided to
mandate it a few years ago, it just has to be there."

According to your I-D the client has to anyway support TCP (or
other congestion controlled transport) so it would not even allow
to implement UDP-only clients (which might be desirable for
some vendors that currently only support UDP). Thus what is
the point with the UDP flows ? Why could they not be optional
for an UA ?

Regards,

Erkki

>-----Original Message-----
>From: ext Marc Petit-Huguenin [mailto:[email-masked]] 
>Sent: 12.December.2006 19:42
>To: Niemi Aki (Nokia-NRC/Helsinki)
>Cc: 'IETF SIP List'; 'Francois Audet'
>Subject: Re: [Sip] I-D: Preventing Fragmentation 
>forClientInitiated Connections in the Session Initiation Protocol (SIP)
>
>Aki Niemi wrote:

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 13 Dec 2006 08:33:18 +0200

just a reality check.  yesterday when i was going to make some sip tcp
tests, i tried to find a sip phone that supports tcp.  the most popular
ones from linksys/sipura (cisco) and grandstream didn't.

-- juha

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Dec 2006 07:26:53 -0800

>    must support UDP, not even the performance would do. 

No, performance is still the reason why *I* will mix UDP and TCP in my
endpoints and servers.  The discussions about making UDP obsolete are
not new, it is always someone claiming that SIP over TCP has the same
performances than SIP over UDP, it is just that the SIP implementers are
morons who do not know how to use select or poll, or epoll, etc...
At first I believed this, and I was ready to move all our customers to
TCP only, until something I read made me doubt this.  So I asked our QA
department to write some tests and to run them on our servers.  The I-D
was written because of the result of this tests.

The problem with performance is that if I publish my results someone
else will come with different results to prove the opposite.  Also not
everybody is interested in performance.  I am, because we have to pay
for every server, data center, etc... to run SIP.  I guess that the
vendors selling the servers, or the software licenses does not care as much.

So I think that we should accept that different members of this WG have
different needs and that we should not have any performance discussion,
as long as the implementers have the tools they need to design servers
and endpoints that works for them.

So this is why I am switching my focus from performance to 1) do not
prevent implementers to use UDP if they need it and 2) anyway RFC 3261
mandates UDP AND TCP on all elements.

>    full compatibility to RFC 3261.

This is a good enough reason.

> the point with the UDP flows ? Why could they not be optional

UDP-only clients are not SIP compliant.  So how a UDP flow can be
optional if UDP in the endpoint is not?

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 13 Dec 2006 16:47:16 +0100

Marc Petit-Huguenin wrote:
...
> mandates UDP AND TCP on all elements.

Not even RFC3261 manages to get you everything if using UDP though - 
large messages for one, security (SIPS) for another.

As I see it, it is too complicated to try and make SIP over UDP work 
across NATs to even try it. For those cases where the properties of 
Outbound are desired, everyone will be better off using TCP.

For the cases where you have small messages, don't require security and 
don't have to worry about NATs or firewalls in your network paths, then 
UDP is fine (if I don't think about the re-inveted reliability). I don't 
mind anyone using it where it actually works.

I'm genuinely worried though that Outbound with UDP won't actually work 
in the field once finished, because of something we fail to think of at 
this time.

If anyone can tell me of some other UDP based network application that 
actually attempts to work through NATs by using keepalives (that means: 
not DNS), and without users configuring their NAT with port forwards or 
similar then please tell me so that I don't have to worry that we're 
spending all this energy chasing a solution that might not even exist in 
the first place. There must be some kind of precedence in this area, I'm 
sure.

/Fredrik

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Dec 2006 08:51:02 -0800

> large messages for one, security (SIPS) for another.

Let's exclude SIPS from the discussion, as DTLS can be used here.

Yes, large messages must go through TCP, but the reality is that not all
messages mandates to use TCP, and this is especially true for messages
that are sent periodically, REGISTER and SUBSCRIBE for example.

RFC 3261 already can mix UDP and TCP when there is no NAT[1].  The
problem here is that it not longer works behind a NAT, even with
Outbound.  My proposal is to extend Outbound so it works the same way.

> in the field once finished, because of something we fail to think of at

Outbound with UDP does not work.  Because of this some people want to
exclude UDP from Outbound, which is inconvenient for implementers who
care about performance.   What I am proposing is to make UDP working
with Outbound instead of excluding it.

Remember that this is not the endpoint that decide to use UDP or TCP,
its the servers (i.e. NAPTR records as described by RFC 3263).  If the
server decides that the endpoint must use TCP, then everything is fine
with Outbound.  But if the server decides that the endpoint must use UDP
(and switch to TCP if the message is too big), then things breaks for
the cases described in my draft, i.e. incoming messages too big and
outgoing responses too big.

> the first place. There must be some kind of precedence in this area, I'm

[1] Excepted for the fragmentation response problem. See:
http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt
http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 13 Dec 2006 11:56:07 -0500

> optional if UDP in the endpoint is not?

I think it is perfectly reasonable to say that a new enhancement to SIP
(eg Outbound) is defined to work only over certain transports, if doing
so is either required to make it work at all, to limit the complexity of
the specification, or to make the resulting implementations more robust
in the wild.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 13 Dec 2006 15:20:35 -0800

Hi Juha,

I proposed that since edge proxies and registrars have to support both
UDP and TCP, UAs that want to implement outbound for TCP don't have to
also implement outbound for UDP.  My proposal does not prevent
UDP-only devices from working.

I would also like to point out that devices that don't support TCP are
not compliant with RFC 3261.  I suspect one of the reasons these
devices have not implemented TCP is because the devices you mentioned
are usually used in a residential setting and therefore need a
standardized mechanism to get inbound requests when they are behind a
NAT.  This was the original intent of outbound and the title of the
document reflects that: " Managing Client Initiated *Connections*".
There are clearly people who want to implement this spec for TCP, so I
don't see what the problem is with finally doing something that makes
it so we can have interoperable implementations that use TCP behind
NATs.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 13 Dec 2006 15:43:18 -0800

Marc,

To date, I think you are the only person who has spoken on the list
who actually wants to use TCP for some requests and UDP for others.

What I have heard from the UDP-apologist crowd is generally that they
are using UDP for either historical reasons (with which I sympathize)
or for performance reasons (of which I am skeptical).  The historical
argument basically boils down to having a large number of components
that will all would need to be replaced or drastically reconfigured at
once.  I think the language I proposed explains and makes room for
this.

On the performance side, I consistently hear several UDP-apologists
concerned with the maximum number of connections they can handle.
Your approach does nothing to address this concern since it ends up in
the same number of TCP connections as the pure-TCP approach.  From the
TCP-advocates I hear that in their implementations they can handle a
very large number of TCP connections by getting rid of poll/select,
and that they can handle about the same number of UAs using UDP as
TCP.  The performance bottleneck I usually hear about with these
implementations is access to the registration/location server
database.  (I have also heard about the registration/location server
database being a bottleneck in UDP-only implementations as well.) Your
approach would effectively double the number of entries in the
registration database and therefore seems to make things worse rather
than better.  Certainly it does not address the perceived performance
problems of either the pro-UDP or the pro-TCP crowd.

thanks,
-rohan

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Dec 2006 16:48:15 -0800

> problems of either the pro-UDP or the pro-TCP crowd.

No, this is not how it would work.   The TCP connections are temporary,
not permanent.

I think that we can compare this to a HTTP server.  Even if I am
constantly logged in slashdot.org, there is no permanent TCP connection
between my browser and slashdot.org's HTTP server.  This is because it
is more efficient to close the connection at the end of the transaction,
and to open a new one when I click on reload.

So there is 3 possible combinations of transports for SIP; UDP alone,
permanent TCP and UDP + temporary TCP.  I excluded UDP alone, because of
the fragmentation problem. So we wrote two tests with the same kind of
transactions an endpoints would do, the first test with a permanent TCP
connection, and the second test with a mix of UDP and temporary TCP.
The TCP/UDP mixed test, even if it have to create TCP connections and
close them each time a SIP message bigger than the MTU have to be sent
or received, was using half the resources of the test with the permanent
TCP connection.  And the UDP+TCP test was using the additional mechanism
to request the opening of the TCP connection.

So the idea is that at a specific time, a specific flow can use UDP or
TCP but not both.  The transport for the flow changes depending on what
needs to be used for incoming request or outgoing response.  After the
end of the transaction that needed TCP, the TCP flows is replaced by an
UDP flow and the TCP connection is closed.

Obviously this works only if the transaction that create the flow, i.e.
the REGISTER, does not need TCP.  If it is the case, then the only
transactions that need TCP are INVITE that carries a big SDP (thanks to
ICE) and the NOTIFY that carries big XML documents.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Dec 2006 17:02:34 -0800

> to request the opening of the TCP connection.

Doesn't this all go down the drain when you add (D)TLS to the mix? The
relative costs of establishment are orders of magnitude different right?
(I wish I had that number off the top of my head, but I don't) That's
really the thing that's swayed me with these debates since we shouldn't
be counting on non-use of crypto going forward.

       Mike

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 13 Dec 2006 19:15:03 -0800

> be counting on non-use of crypto going forward.

This is a good point.  I'll try to find an answer to this.

Thanks.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 14 Dec 2006 07:30:35 +0200

> UDP-only devices from working.

yes, i didn't actually comment on your proposal, but just how far from
rfc3261 requirements the real world is.

 > it so we can have interoperable implementations that use TCP behind

we already have that.  after i finally found a sip tcp implementation
(in nokia phone), i made the phone to register from behind symmetric NAT
with my OpenSER based proxy.  the proxy kept tcp connection persistently
open and i didn't have any trouble of making both in and outbound calls
from that phone.

no non-rfc3261 compliant features were in use in the phone.  thus i
still fail to see what value add would outbound give now when its REAL
value add has been removed, i.e., mandating the phone to register with
more than one proxy.

-- juha

---

From: "Rohan Mahy" <[email-masked]>
Date: Fri, 15 Dec 2006 17:44:17 -0800

Hi Marc,

What is the edge proxy supposed to do when it wants to deliver a large
INVITE request to the UA and the UA does not have a TCP-connection
established at the moment?

thanks,
-rohan

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 15 Dec 2006 18:04:07 -0800

> established at the moment?

As I proposed in my draft[1], the edge proxy sends a STUN ForceCCP[2]
request over UDP to the UA to replace the flow by a TCP flow.  The edge
proxy can then use the TCP connection to send the INVITE.  The TCP flow
is replaced by an UDP flow at the end of the SIP transaction, or after 5
seconds if there is no SIP transaction.  The TCP connection is then closed.

Note that the draft is missing lot of stuff, e.g. how an edge proxy
knows that the endpoint supports this, etc...

[1]
http://tools.ietf.org/html/draft-petithuguenin-sip-outbound-fragmentation-00#section-6
[2] Force Congestion Controlled Transport Protocol