Subject: [Sip] strawman text for FASTEST proposal in outbound

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 21 Nov 2006 11:59:20 -0800

Hi,

To make the discussion about the outbound transport issues more
concrete, here is some strawman text for the "FASTEST" direction.

thanks,
-rohan

PROPOSED TEXT:
Use of outbound with UDP flows prevents messages larger than 1300
bytes from being delivered using TCP as described in Section 18.1.1
RFC 3261.  Use of outbound in conjunction with UDP flows in
environments where requests are expected to be larger than this size
is therefore NOT RECOMMENDED.

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Tue, 21 Nov 2006 15:44:06 -0500

I just wanted to point out that at  everyone of the recent IETF  
meetings Rohan and I have gotten strong feedback from the WG that  
they want this done soon so I feel pretty strongly we should be on  
the route Rohan described as "Fastest". Some of the comments for  
alternatives from this I think I would argue with but that is  
probably not very relevant if people feel they can live with the text  
below and just get outbound finished.

Cullen <with my outbound editor hat on>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Nov 2006 15:39:03 -0600

> To make the discussion about the outbound transport issues 
> more concrete, here is some strawman text for the "FASTEST" direction.
> 
> thanks,
> -rohan
> 
> PROPOSED TEXT:
> Use of outbound with UDP flows prevents messages larger than 
> 1300 bytes from being delivered using TCP as described in 
                                        ^^^
                                Shouldn't this say "UDP"?

> Section 18.1.1 RFC 3261.  Use of outbound in conjunction with 
> UDP flows in environments where requests are expected to be 
> larger than this size is therefore NOT RECOMMENDED.

But otherwise, looks good. 

Like Cullen, I do agree with the FASTEST direction.

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Nov 2006 17:42:54 -0600

>                                 Shouldn't this say "UDP"?

Normally, if one were not able to deliver a response using UDP due to  
the size of that response, one might establish a TCP connection to  
deliver that response.

But unless you do something tricky when using outbound to cross a NAT  
(like have a pre-established TCP connection), you can't just "fall  
back" to TCP for responses from "outbound proxy" to UA, because you'd  
be in a position of trying to initialize a TCP connection going the  
"wrong way" through a NAT.

--
dean

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 21 Nov 2006 16:15:32 -0800

Hi Francois,

>                                 Shouldn't this say "UDP"?

No.  Outbound using UDP flows prevents the switchover to a
congestion-controlled transport, such as TCP as described in this
quote from RFC 3261:

If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU
is unknown, the request MUST be sent using an RFC 2914 [36] congestion
controlled transport protocol, such as TCP. If this causes a change in
the transport protocol from the one indicated in the top Via, the
value in the top Via MUST be changed. This prevents fragmentation of
messages over UDP and provides congestion control for larger messages.

I think we've already established that if a UA was going to bother
establishing a TCP or TLS flow that there would be no benefit to using
a UDP flow.
thanks,
-rohan

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2006 16:15:00 -0800

> "wrong way" through a NAT.
Right... the thing that struck me about this is that there seems to be an
implicit assumption that deployments can "know" how things will be
used. It seems to me that you "know" these things for about as long as
it takes for the assumption to broken and then you're really hosed.
Considering that SIP is not entirely unlike a trash barge hauling stuff
out to the New Jersey outer banks, I'm not very convinced that the
barge isn't going to repeatedly sink unless there's explicit fallback for
those inevitable heavy loads.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Nov 2006 16:27:03 -0800

> establishing a TCP or TLS flow that there would be no benefit to using
Does there exist any plausible scenario where that won't be the
case? Let's take into consideration that the time horizon here
should be viewed in the decades rather than in the months.

       Mike

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 21 Nov 2006 17:15:08 -0800

Hi Francois,

    If a request is within 200 bytes of the path MTU, or if it is
larger than 1300 bytes and the path MTU is unknown, the request MUST
be sent using an RFC 2914 [36] congestion controlled transport
protocol, such as TCP. If this causes a change in the transport
protocol from the one indicated in the top Via, the value in the top
Via MUST be changed. This prevents fragmentation of messages over UDP
and provides congestion control for larger messages.

thanks,
-rohan

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 21 Nov 2006 20:32:05 -0600

Hi, Rohan,

> is therefore NOT RECOMMENDED.

I like this, but it seems to be confusing. Perhaps

"Use of outbound with UDP flows prevents fallback to TCP for messages larger 
than 1300 bytes as described in ..."

Since you are giving guidance anyway, is it possible (and non-contentious) 
to provide a little more help to people who are trying to connect the dots?

"... NOT RECOMMENDED. Environments where large requests are likely to occur 
include ..."

I guess my concern is that NOT RECOMMENDED is roughly a SHOULD NOT, so the 
reader is responsible for figuring out whether the problem will occur or 
not.

Thanks,

Spencer

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 Nov 2006 08:39:50 -0800

On Nov 22, 2006, at 6:11, <[email-masked]> wrote:

> Hi,
>
>> -----Original Message-----
>> From: ext Rohan Mahy [mailto:[email-masked]]
>>
>> Hi,
>>
> Practical question: In which kind of environment the messages could be
> expected to always be below 1300 bytes?

Folks using Sigcomp between the edge proxy and the UA.

> Some kind of isolated island of
> SIP where all endpoints and their features are under control?

Possibly.

thanks,
-rohan

> Clearly,
> this won't work in any real inter-domain Internet deployment, and might
> actually make such a thing even harder to achieve. Isn't this just evil
> from the perspective of long-term well-being and deployment of SIP? :O
>
> Markus

---

From: <[email-masked]>
Date: Wed, 22 Nov 2006 16:11:12 +0200

Hi,

Practical question: In which kind of environment the messages could be
expected to always be below 1300 bytes? Some kind of isolated island of
SIP where all endpoints and their features are under control? Clearly,
this won't work in any real inter-domain Internet deployment, and might
actually make such a thing even harder to achieve. Isn't this just evil
from the perspective of long-term well-being and deployment of SIP? :O 

Markus

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Nov 2006 14:49:53 -0500

> establishing a TCP or TLS flow that there would be no benefit to using

Note I disagree that we have established this but I think it is more  
or less irrelevant to the discussion on what we should do here.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Nov 2006 15:13:21 -0600

I understand Rohan, but the current text is confusing.

I prefer the "switchover" explanation you gave below. Or something
along the lines of what Spencer proposed in his posting. 

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 17:15
> To: Audet, Francois (SC100:3055)
> Cc: SIP WG; Cullen Jennings; Rohan Mahy
> Subject: Re: [Sip] strawman text for FASTEST proposal in outbound
> 
> Hi Francois,
> 
> > > bytes from being delivered using TCP as described in
> >                                         ^^^
> congestion-controlled transport, such as TCP as described in 
> this quote from RFC 3261:
> 
>     If a request is within 200 bytes of the path MTU, or if 
> it is larger than 1300 bytes and the path MTU is unknown, the 
> request MUST be sent using an RFC 2914 [36] congestion 
> controlled transport protocol, such as TCP. If this causes a 
> change in the transport protocol from the one indicated in 
> the top Via, the value in the top Via MUST be changed. This 
> prevents fragmentation of messages over UDP and provides 
> congestion control for larger messages.
> 
> thanks,
> -rohan
>