Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 4 Jan 2007 14:30:41 +0100

I just submitted a new version of my proposal to support hybrid TCP-UDP
 transport in Outbound.  Until it appears in the archives, a copy can be
found here:

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

This is a nearly complete rewrite.  Please read at least the
Introduction and the Overview of Operation sections and you will see
that this proposal does not add a lot of complexity to Outbound.

Comments and questions 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: <[email-masked]>
Date: Fri, 5 Jan 2007 14:05:56 +0200

Hi,

>that this proposal does not add a lot of complexity to Outbound.

I quite much disagree and still think it is too complex. 
The draft introduces the following pattern:

1. Proxy receives such a big SIP request that it can not pass it
   to the UA via the persistent UDP flow
2. Consequently the proxy will send ForceTCP message to the UA
3. The UA will open a temporary TCP connection towards the proxy
4. The UA will send a GetToken request to the proxy over the TCP
   connection
5. The proxy will respond GetToken with a new flow token assigned
   to the TCP flow
6. UA will store this new TCP flow token and associate it with the
   UDP flow
7. UA will respond to the ForceTCP message returning the flow token
   of the TCP flow to the proxy
8. Based on the response from the UA the proxy can now re-map the
   big SIP request from UDP flow to the new TCP flow and forward
   it to the UA

That does not sound too easy to me. Especially when thinking about:
- Various interactions between the SIP and STUN stacks required
- Requirement for the UA to start opening TCP connections when
  there is no SIP request to sent (a change to the connection
  management architecture laid out in RFC 3261).
- Usage of SigComp together with SIP and STUN muxed over a 
  TCP connection, if the deployment requires using SigComp

I believe the proposed mechanism does not clearly describe to 
which address and port the UA should set up its TCP connection.
Usually UA resolves the SIP URI of the next hop when sending
a request and opens the connection towards a resolved address-port
pair. In the context of ForceTCP at least the port is not evident.

If proxy has a TCP SIP port configured to the DNS, the UA might
already have a TCP connection open towards the proxy even if the
proxy does not recognize it. Instead of opening a new TCP connection
the existing one could be used, see below. But if DNS does
not have TCP SRV record for the proxy, then which port to use ?
Always 5060 or should ForceTCP tell the port number ?

But if you anyway would like to continue with the draft, please
consider an alternative pattern.

I believe that the requirement for the UA to associate the UDP and
TCP flows together does not make sense. The proxy should maintain
this association as it is the proxy who really needs this info,
in order to remap inbound requests between flows. Consequently
the pattern could be like this:

1. Proxy receives such a big SIP request that it can not pass it
   to the UA via the persistent UDP flow
2. Consequently the proxy will send ForceTCP message to the UA.
   This message would contain the flow token of the UDP flow.
3. UA would immediately respond to the ForceTCP message
4. The UA will open a temporary TCP connection towards the proxy
   or skip this phase if it already has a persistent TCP connection
5. The UA will send a GiveToken request to the proxy over the TCP
   connection, giving the token of the associated UDP flow
6. The proxy will respond GiveToken request and store the mapping
   between the TCP and UDP flows
7. Based on the GiveToken from the UA the proxy can now re-map the
   big SIP request from UDP flow to the TCP flow and forward
   it to the UA

This pattern would also avoid ForceTCP transaction to time out
(or retransmissions of ForceTCP) while UA is opening the TCP
connection and performing the GetToken exchange.

P.S. I still have doubts whether this mechanism, introduced as a 
separate draft, would gain wide enough acceptance to be really
useful for deployments. I also anticipate that when reviewed in
detail, the complexity will grow as the problems and different
error cases etc. pop up.

Regards,

Erkki

>-----Original Message-----
>From: ext Marc Petit-Huguenin [mailto:[email-masked]] 
>Sent: 04.January.2007 15:31
>To: [email-masked]
>Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 5 Jan 2007 15:25:25 +0100

Hi Erkki,

Thanks for your comments.  Please see my responses inline.

> Always 5060 or should ForceTCP tell the port number ?

The remote UDP IP address and port are used to open the TCP connection.
 This works because "[f]or any port and interface that a server listens
on for UDP, it MUST listen on that same port and interface for TCP."
(RFC 3261 Section 18.2.1).

I will add this to the draft.

>    big SIP request from UDP flow to the TCP flow and forward

This is a nice improvement on my proposal, and I would suggest an
additional improvement by using Indications for ForceTCP and GiveToken.
The proxy can retransmit the ForceTCP Indication until the GiveToken is
received, and so reduce the number of STUN messages exchanged to two.

The only problem I see with this pattern is that it is not scalable.
The reason I proposed to store the association in the UA is that there
is no need for data locking in the proxy.  With your pattern, the
structure that contains the mapping between UDP and TCP flows needs to
be locked during the access, and as this is a global structure that will
be under heavy use, this will reduce the scalability.

> connection and performing the GetToken exchange.

Yes, I knew about this problem.  I thought about using a STUN 100 Error
response to stop the retransmission, but I discovered that it does not
work.  I sent an email to the BEHAVE list about this issue:

http://www1.ietf.org/mail-archive/web/behave/current/msg01859.html

> detail, the complexity will grow as the problems and different

I do not expect to have this draft published as an RFC.  I do not like
to complain about problems without proposing solutions, and an I-D is a
good way to present them.

UDP as it is in Outbound does not work and need to be fixed.  My
proposal (or another proposal) can be added to the existing Outbound
draft, but I do not think that this is a good idea to delay even more
Outbound.  Another solution would be to remove completely UDP from
Outbound and add a text saying that UDP is still mandatory, but Outbound
covers only TCP, and to start to work on a UDP-Outbound draft (based or
not on my draft).

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 5 Jan 2007 16:33:33 +0200

> >    big SIP request from UDP flow to the new TCP flow and forward

you must be joking.  looks like ietf folks are living in an extremely
complex surrealistic world.

-- juha

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 5 Jan 2007 09:08:00 -0700

With all due respect to everyone, I would like to echo and amplify this.
The entire direction of the SIP spec lately, outbound, ice, etc. have really
become overly complex.  I think a concerted effort to take a step back and
simplify things would benefit the entire community.

Thanks,
FM

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 7:34 AM
To: Marc Petit-Huguenin
Cc: [email-masked]
Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01

-- juha

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 5 Jan 2007 17:32:58 +0100

> simplify things would benefit the entire community.

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken (1880-1956)

SIP didn't create the problem.  The ISPs who didn't deploy IPv6, the
vendors who sold NAT boxes and especially people who does not understand
the end to end argument created the problem.

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 5 Jan 2007 10:13:33 -0700

Do you honestly think that there wouldn't be NAT if the world were
completely IPv6?  NAT may have originally been put in place to alleviate the
IPv4 address exhaustion problem but separation of address spaces is more
useful than that, no matter how big the address spaces are.  While I would
luv for the public Internet to be purely end-to-end wrt IP addresses, this
just is never going to happen again.  The early days of a few hundred VAXs
all happily talking to each other directly are long gone.  The days of trust
are gone forever and NAT is just one reflection of that.

FM

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 5 Jan 2007 18:31:57 +0100

Frank W. Miller wrote:
> useful than that, no matter how big the address spaces are.  

What about distributed firewall?

http://www.cs.columbia.edu/~smb/papers/distfw.html

> While I would
> just is never going to happen again.  

I agree, but it is not a reason to not try to improve things.  NAT,
firewalls, load balancers, B2BUA and SBC are the cancer of Internet.

> The early days of a few hundred VAXs

So, how do you solve the problem of using a SIP endpoint behind a NAT? a
SIP endpoint been defined as running on UDP AND TCP.  Because this is
the problem here.

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 5 Jan 2007 10:50:49 -0700

Well, you asked...

There are two ways that I think are a lot simpler, one more radical than the
other.

First, the "less" radical approach.

For SIP, just spec TCP for transport and have the UAs punch holes through
the Firewall/NAT and keepalive them.  This I think is sort of what Dean was
eluding to in an earlier email.

For media, ICE is a solution.  But, it seems overly complex to me.  Consider
this article:

http://www.heise-security.co.uk/articles/82481

When you see the address of the incoming media in the SDP, just punch a hole
in the FW/NAT.

Second, the "more" radical approach.

If we really want to solve the NAT problem simply, we need to revisit the
basic assumption that signaling and media are on different transport ports.
We could use the basic idea in IAX2 of separate address space behind the
transport port number.  We've already breached the multiplexing of multiple
protocols onto a single transport address.  Why not do it right?  Allow
STUN, SIP, and RTP to all use the same transport address and use another
address behind the port number to de/mux them.

Here's the basic architecture of IAX2 for those that haven't seen it
(http://www.ietf.org/internet-drafts/draft-guy-iax-02.txt):

       +-----------------+                     +------------------+
       | Stream          |                     |           Stream |
       | Number          |                     |           Number |
       |  +-+            |                     |            +-+   |
       |  | |---+        |                     |        +---| |   |
       |  +-+    \       |                     |       /    +-+   |
       |  +-+     \ Port |     +---------+     | Port /     +-+   |
       |  | |---+  \+-+  |     |   IP    |     |  +-+/  +---| |   |
       |  +-+    \_ | |<------>| Network |<------>| | _/    +-+   |
       |  ...     _ +-+  |     +---------+     |  +-+ _     ...   |
       |  +-+    /       |                     |       \    +-+   |
       |  | |---+        |                     |        +---| |   |
       |  +-+            |                     |            +-+   |
       +-----------------+                     +------------------+
             Host 1                                   Host 2

Something completely different.  Like I said before, I would prefer the
separation of signaling and media on separate ports but the NAT problem in
my opinion, along with the close relationship between signaling and media
streams, makes it untenable.

FM

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 5 Jan 2007 22:40:40 +0200

> SIP endpoint been defined as running on UDP AND TCP.  Because this is

it has already been solved in practise.  see see/openser documentation
for proxy operation and, for example, nokia SIP UA for TCP UA operation.
there is no need to standardize anything for nat traversal.  

there would have been need to standardize UA behavior for load balanced
resilient operation, but that was excluded from outbound.  now there is
nothing left worth writing an outbound rfc.

-- juha

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 6 Jan 2007 08:27:38 +0100

> eluding to in an earlier email.

Ah, but you do not answer the question:
"[H]ow do you solve the problem of using a SIP endpoint behind a NAT? a
SIP endpoint been defined as running on UDP AND TCP."

Basically what you are saying (with the other UDP-haters in this list)
is that the UDP problem is too complex, so let's just remove UDP from
the list of transports supported by SIP.

As this is the I *E* T F, I was hoping for more enthusiasm to solve
problems, instead of sweeping them under the rug.

> 
> For media, ICE is a solution.  But, it seems overly complex to me.  

ICE is a brilliant and complex solution to complex problems.  But the
problems solved by ICE goes beyond just NAT traversal.  It also offers a
strategy for IPv4 to IPv6 migration, a way to create direct connection
for two UA behind the same NAT and a nice solution for multihomed UA.

> Consider

Yes, it is extremely funny to see sysadmins discovering STUN more than
five years after the publication of the first draft.

BTW sysadmins also break the end to end argument.  Think about that.

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 6 Jan 2007 09:35:32 -0700

-----Original Message-----
From: Marc Petit-Huguenin [mailto:[email-masked]] 
Sent: Saturday, January 06, 2007 12:28 AM
To: Frank W. Miller
Cc: [email-masked]; 'Juha Heinanen'
Subject: Re: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01

FM: Hole punching will work for UDP and TCP both.

FM: I'm not a UDP hater but I do think that TCP is the proper transport
protocol that fits this application.  I also think that if you have TCP, UDP
is probably unnecessary.  I would advocate the dropping of UDP in a "version
3.0" of SIP but not for -outbound.  There is too much installed base that
uses UDP (including my stuff!).

FM: What does ICE do for IPv6 transistion that hole punching does not?

FM: Two UAs behind the same NAT should not have to traverse the NAT.  They
should be smart enough to figure that out.  I don't think there's anything
wrt "IPv4 to IPv6 transition" (whatever that means) that would not be
possible with hole punching.

FM: The article talks about hole punching, which is more than STUN.  In SIP,
you would get your visible IP address, put that into the SDP and when the
other UA gets it, they punch a hole in their FW/NAT based on the address you
sent them to allow incoming media to flow.

FM: No comment on the more radical approach I guess...   ;)

FM

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 7 Jan 2007 08:42:59 +0100

Inline.

Frank W. Miller wrote:

[snip]

> uses UDP (including my stuff!).

This is exactly where I do not follow.  You are proposing to remove UDP
from SIP (RFC 3261), where it works perfectly well, and to keep it in
Outbound, where it does not.

> FM: What does ICE do for IPv6 transistion that hole punching does not?

The ICE algorithm will prefer an IPv6 route for the media if it can find
one.

> should be smart enough to figure that out.  

How?  Comparing IP addresses does not work.  AFAIK, ICE is the only
specification that permit this.

> I don't think there's anything

[snip]

> FM: No comment on the more radical approach I guess...   ;)

Well, the question started with "[h]ow do you solve the problem of using
a SIP endpoint behind a NAT?"

The protocol that you proposed is perhaps interesting, but does not
respond to this question.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 14 Jan 2007 22:57:08 -0800

>> the list of transports supported by SIP.

One of the hilarious parts of this whole conversation is that one of  
the key reason UDP was done in the first place was that implementers  
felt it was much simpler and the "just keep SIP simple" argument was  
one of arguments for including UDP.