Subject: [Sip] I-D on handling large UDP responses

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Oct 2006 13:45:25 -0500

Folks: An I-D on handling large UDP response has just been
submitted to the I-D editor.  Until it appears in the archives, a
copy can be obtained from:

http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt
http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html

The draft suggests the use of 1xx-class responses to solve this
problem.

Please look at the draft and provide comments and/or concerns.

Thank you.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 03 Oct 2006 14:01:33 -0500

> Please look at the draft and provide comments and/or concerns.

So, are we stuck on advancing the hop-limit-diagnostics draft until we 
advance something like this draft?

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Oct 2006 14:11:45 -0500

> advance something like this draft?

Umm ... at least I see these as two distinct pieces of work...no?

- vijay

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 3 Oct 2006 22:18:15 +0200

Three initial comments:

1) I would expect the main source of large responses to be the UAS sending a 
large response body. A transport switch does not necessarily imply that a 
large response will follow, in general I think those 140 responses will 
often be a waste of bandwidth. You could instead consider sending it just 
before the proxy is about to forward a response >MTU (1500 if unknown) over 
UDP, and then preferrably only when no 140/141 response from some downstream 
node was forwarded already (only possible to detect this for stateful 
proxies).

2) The current draft can result in cases where both a 140 and a 141 response 
are sent, this seems wasteful. When the UAS sends a response >1500 bytes 
over non-UDP, it does not necessarily imply that there will be a response 
 >1500 bytes using UDP at some point. So if the proxy forwarding rule is 
changed per (1)above, the UAS should only send a 141 when it is sending over 
UDP itself (i.e. no inspection of the via chain needed). If there is a 
transition to UDP in the path beyond, a proxy will send 140 instead. This 
avoids duplicate 140/141 responses

3) Given the above, it could probably be done with only 1 response code. 
Proxies should then set the to-tag to the to-tag of the large response

Regards,

Jeroen

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 3 Oct 2006 16:16:12 -0500

I have some additional initial comment 
 
What will you do when 140/141 is lost? PRACK ? 
As 141 is sent just before sending the final response , so cross over ?
Forking with 141/140 in one branch, should CANCEL come into picture?

Thx
Samir

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Tuesday, October 03, 2006 1:18 PM
> To: Vijay K. Gurbani; IETF SIP List
> Subject: Re: [Sip] I-D on handling large UDP responses
> 
> Three initial comments:
> 
> 1) I would expect the main source of large responses to be the UAS
sending
> a
> changed per (1)above, the UAS should only send a 141 when it is
sending
> over
> > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-
> response/draft-gurbani-sip-large-udp-response-00.txt
> > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-
> response/draft-gurbani-sip-large-udp-response-00.html
> >

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 03 Oct 2006 16:12:23 -0700

I was working on a different solution to the same problem.  This
solution can be seen as an extension of what you are proposing in
section 4.1.

Until the I-D appears in the archives, a copy is available here:

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

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Oct 2006 21:36:13 -0500

> I have some additional initial comment 

Samir: Thanks for your comments.

> What will you do when 140/141 is lost? PRACK ? 

We thought of PRACK, but in the end decided not to use it.
It makes the machinery too complex.  Yes, there is a chance that
the 14x response is lost, or experiences excessive queuing delays.
But, dropped packets are not the norm in today's networks (I would
hope).

> As 141 is sent just before sending the final response , so cross over ?

If the final response arrives unscathed, then the 14x will have
no impact on the state machine when it is received later.  If on
the other hand, the final response is mangled, then when the UAC
gets the 14x, it has some semblance of what is going on...

> Forking with 141/140 in one branch, should CANCEL come into picture?

This is no different than other provisional responses and their
interaction with CANCEL.  If a CANCEL is received after the 14x
is sent out but before a final response has been sent out, then
the CANCEL takes precedence -- the 141 does not foreshadow a
2xx final response, it could just as well be a 487.

Otherwise, if a CANCEL is received after the final response
is sent out, then the CANCEL has no effect on the state machinery.
Probably worth pointing out in the next revision of the draft.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Oct 2006 21:35:58 -0500

> Three initial comments:

Jeroen: Thanks.  Please see inline.

> sending a large response body. 

Forking coupled with response aggregation of 401/407 is another
reason why the responses balloon.  R-R headers added with all kinds
of state is yet another.

> A transport switch does not necessarily 
> imply that a large response will follow, in general I think those 140 
> responses will often be a waste of bandwidth. 

Possibly so; but all the same, I think they can be a valuable feed-
back to the UAC.  One thing we have struggled with in the SIPS
debate is that there is no backwards feedback to the UAC if a
downgrade occurs.  Here, there is some explicit feedback that the
UAC may find pertinent.

> You could instead consider 
> sending it just before the proxy is about to forward a response >MTU 
> (1500 if unknown) over UDP, and then preferrably only when no 140/141 
> response from some downstream node was forwarded already (only possible 
> to detect this for stateful proxies).

True.

> 2) The current draft can result in cases where both a 140 and a 141 
> response are sent, this seems wasteful. When the UAS sends a response 
>  >1500 bytes over non-UDP, it does not necessarily imply that there will 
> be a response >1500 bytes using UDP at some point. 

I am unable to follow the last sentence ... sorry.  Can you
amplify?

> So if the proxy 
> forwarding rule is changed per (1)above, the UAS should only send a 141 
> when it is sending over UDP itself (i.e. no inspection of the via chain 
> needed). 

Having the UAS inspect the Via chain for a UDP link assures that
the 141 is sent out only if the response will traverse a UDP link
some time before reaching its final destination; i.e., the UAS may
have got the request over TCP, but there is some upstream entity
that used UDP to send the request downstream.

> If there is a transition to UDP in the path beyond, a proxy 
> will send 140 instead. This avoids duplicate 140/141 responses

If a UAS sends a final response, there will not be any transition
in the path beyond the UAS...

Thanks.

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 21:31:54 -0700

On Oct 3, 2006, at 12:01 PM, Dean Willis wrote:

> So, are we stuck on advancing the hop-limit-diagnostics draft until  
> we advance something like this draft?

At the last IETF, I think Vijay, Scott and I had come up with a way  
to deal with hop-limit-diag without doing this but I have no  
objections if folks want to have it wait for something like this.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 4 Oct 2006 08:47:10 +0200

Vijay,
see inline

Regards,
Jeroen

----- Original Message ----- 
From: "Vijay K. Gurbani" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>
Sent: Wednesday, October 04, 2006 4:35 AM
Subject: Re: [Sip] I-D on handling large UDP responses

> reason why the responses balloon.  R-R headers added with all kinds

I think it would be good if the draft provided some text on this. For 
starters: the current draft does not help in case of large responses due to 
forking+401/407 aggregation as you describe here. Another reason to have the 
proxy send 140 just before it forwards a large response.

>> A transport switch does not necessarily imply that a large response will 
>> follow, in general I think those 140 responses will often be a waste of 
>> bandwidth.
>

There may be situations where this is valuable feedback. However, it seems 
orthogonal to large UDP responses (i.e. solution for different problem)

>> You could instead consider sending it just before the proxy is about to 
>> forward a response >MTU (1500 if unknown) over UDP, and then preferrably 
>> only when no 140/141 response from some downstream node was forwarded 
>> already (only possible to detect this for stateful proxies).
>
> True.
>

Suppose the UAS sends a response of 1510 bytes over TCP. The next upstream 
proxy removes the topmost Via, making the response smaller than 1500 bytes, 
and then forwards it over UDP. In this case there is no response > 1500 
travelling over UDP, even though the UAS sent a response larger than 1500 
bytes and there is UDP in the chain

>> So if the proxy forwarding rule is changed per (1)above, the UAS should 
>> only send a 141 when it is sending over UDP itself (i.e. no inspection of 
>> the via chain needed).
>
>> If there is a transition to UDP in the path beyond, a proxy will send 140 
>> instead. This avoids duplicate 140/141 responses
>

I meant the upstream path, the chain formed by the Via headers. If there is 
one that says 'UDP', the element before that (i.e. host in Via which appears 
above the one with UDP) will be the one sending a 140/141 response

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 04 Oct 2006 07:39:06 -0400

> > copy can be obtained from:
[...]
> advance something like this draft?

I don't think so.  This draft was, in part, inspired by the problem of
how to diagnose when responses are lost due to UDP fragmentation.  The
hop limit responses will usually be very large (if only because of all
those Via headers), so they are one of the cases.

It may be that having this mechanism takes a bit of the heat off of the
problem of trimming those error responses down to a size that's sure to
get through, since at least some indication will... what do people
think?

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

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 4 Oct 2006 14:09:04 +0200

> get through, since at least some indication will... what do people

Perhaps, if you would put the status line of the error response as a body in 
the 140/141 response. If not, the UAC would make a wrong diagnosis (and 
retry the request over TCP, and likely hit the same hop limit)

Being a specific case, IMO splitting the hop limit response in two parts 
like this can help. However, generating 140/141 liberally (such as every 
time a transport switch occurs) concerns me. The risk is that corner cases 
are improved, at the cost of overall degredation of the system.

Regards,

jeroen

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 04 Oct 2006 10:23:58 -0400

> node was forwarded already (only possible to detect this for stateful 

That's worth thinking about, certainly.  I'd personally prefer to leave
off the qualifier that makes it require a stateful proxy.  The advantage
of sending the 140 when sending in the downstream direction is that the
proxy can be stateless and it will only send one 140 regardless of the
number and size of replies coming from downstream.

> avoids duplicate 140/141 responses

The motivation for having both 140 and 141 is that it maximizes the
chance that _something_ in the path will provide the hint that messages
are getting large on a path without congestion control.  The case we're
most concerned about cutting off is the very bad one in which the real
response(s) are lost, so the originator is retrying them, and if it's an
INVITE the responder(s) are _also_ retrying because there's no ACK.
Getting some hint to the originator that this isn't going to work offers
the hope that the retries can be eliminated or forced onto a congestion
controlled transport.

> Proxies should then set the to-tag to the to-tag of the large response

Why would proxies want to behave as though they were anything other than
proxies?  They can leave the to-tag empty - this is a 1xx response after
all.  Since messages could have been reordered it doesn't matter when
they send the message and the user agent has the same set of cases to
deal with (that is, the UAC should not be bothered by getting a 1xx
response after a final response anyway).

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 4 Oct 2006 18:29:10 +0200

Scott,

> response after a final response anyway).

My thinking was that in case of forking the UAC might want to know which 
early dialog the problem belongs to. And for mid-dialog requests, RFC3261 
8.2.6.2 says "If a request contained a To tag in the request, the To header 
field in the response MUST equal that of the request.".

The problem with inserting a to-tag, is that the UAC will assume the 
response was sent by the UAS. So some dialog state based on headers such as 
Contact, Allow etc might get updated. You're probably right that leaving the 
to-tag empty is better (even for mid-dialog responses), perhaps correlation 
in case of forking can be solved in another way (if desired)

Regards,

Jeroen

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 04 Oct 2006 13:12:26 -0400

> field in the response MUST equal that of the request.".

I don't think that anyone was thinking about deferred provisional
responses when they wrote that...

> in case of forking can be solved in another way (if desired)

Well, if the UAS at the target sends the 141 then that's taken care of
too.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Oct 2006 16:11:23 -0500

> I think it would be good if the draft provided some text on this. 

OK; will put in some introductory text in next revision.

> For starters: the current draft does not help in case of large 
> responses due to forking+401/407 aggregation as you describe here. 

Ummm ... AFAIK, it does.  In such a case, the proxy, acting as
a UAS will aggregate the responses, and if > 1500 bytes, send
a 141 first.  In all probability, a large UDP response between
a proxy and a UAC in the same domain will succeed.  Problem
cases are those agents that are separated by WAN links and NATs.

> There may be situations where this is valuable feedback. However, 
> it seems orthogonal to large UDP responses (i.e. solution for 
> different problem)

All things being equal, I think this feedback is germaine enough
that retaining it may be worthwhile.

> Suppose the UAS sends a response of 1510 bytes over TCP. The next 
> upstream proxy removes the topmost Via, making the response smaller than 
> 1500 bytes, and then forwards it over UDP. In this case there is no 
> response > 1500 travelling over UDP, even though the UAS sent a response 
> larger than 1500 bytes and there is UDP in the chain

OK, I see.  This makes the entity that is ready to send the
response be responsible for sending a 141, as you suggested in
your email.

Thanks.

- vijay

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 5 Oct 2006 00:02:43 +0200

>> For starters: the current draft does not help in case of large responses 
>> due to forking+401/407 aggregation as you describe here.
>

The "acting as a UAS" bit is not how I interpret RFC3261 section 16.7 point 
7 (it reads as if the proxy is forwarding one of the received 401/407 
responses and adds headers from the others to that), but I suppose it could 
work in this way. Needs to be spelled out though...

Regards,

jeroen

---

From: [email-masked]
Date: Wed, 4 Oct 2006 22:01:11 -0400

In regard to 140's sent by proxies when about to send an oversized
request:  I forgot that 1xx's other than 100 can have a missing
to-tag, but that is so.  (section 13.2.2.1) But within-dialog requests
have to-tags and demand responses that do, too, so I'd say that the
140 should have a to-tag if and only if the request does.  (If an
initial request elicited a 140 with a to-tag, the to-tag would
necessarily be different from any UAS's to-tag, and the UAC might
construct an early dialog for it.)

We might be able to reduce the number of 140's by having the proxy in
question add a (short!) parameter to the Via of the outgoing request
indicating "140 already sent for this request".  Then a proxy would
not generate a 140 for a request that had this flag on a Via.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Oct 2006 23:08:39 -0500

> not generate a 140 for a request that had this flag on a Via.

This is interesting -- but if a proxy, P1, switches to TCP from UDP,
and sends a 140, then chances are that all proxies downstream from
P1 will use TCP as well (for the same reason that P1 did -- the
request was over 1500 bytes).

So, a 140 should happen only once, and not at every hop.

- vijay

---

From: [email-masked]
Date: Thu, 5 Oct 2006 11:58:06 -0400

That requires that all the proxies have the same idea what the UDP
limit is (and that the request isn't modified enough to shrink at any
step).  That can be satisfied if all the proxies have the same idea of
the path MTU.  Is that a reasonable assumption?  Or maybe the more
reasonable assumption that *none* of the proxies know what the path
MTU is, and all of them use 1500.

Dale

---

From: "Samir Srivastava" <[email-masked]>
Date: Sat, 14 Oct 2006 18:37:48 -0500

If we really want a fool proof solution, then we should look into Path
MTU discovery work. More complications.

The more, we want to fix unreliability/fragmentation etc in SIP, the
more problems we are inviting.

In spite of current UDP installed base, I am for deprecating UDP. Do we
really need to have exception for MESSAGE where it is useful ?
Unreliable transports raises the another question of DTLS.

Thx
Samir

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 05, 2006 8:58 AM
> To: [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Sat, 14 Oct 2006 22:12:58 -0500

> MTU discovery work. More complications.

If you think any known technique for path MU discovery is foolproof, you 
must have a very modest idea of "fools".

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 14 Oct 2006 22:29:30 -0500

> must have a very modest idea of "fools".

er, MTU. Clearly, I'm a fool . . .

--
Dean

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 15 Oct 2006 14:10:21 -0400

> MTU discovery work. More complications.

I'm not sure which work you're referring to, but I don't think that
you're going to get much traction with trying to do more messages before
an INVITE just to learn something about the Path MTU (and even if you
do, that doesn't ensure that the INVITE will follow the exact same
path).

>From a practical point of view, getting rid of UDP completely is just
not going to happen.  Commercial products at least just have to live
with it.  We should work on making the better transports more widely
implemented and otherwise more attractive, but in the mean time it's
important that we be able to diagnose when and how UDP is causing
problems.

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 16 Oct 2006 03:25:52 -0500

Hi Scott,

I was referring the work being done PMTU group. 
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-10.txt
I didn't look details of the draft earlier. It does imposes new
requirements. 
Yes. you are correct Path MTU doesn't help completely in the view of
alternate routes etc. It is less/more similar in the value as of
diagnostic tools. As they MAY not follow the same SIP path as the actual
requests. 

The proposed mechanism can be used only for REQ/RSP. How can we address
the problems caused in 200 OK (Offer) and ACK (Answer) due to UDP
between some proxies ? In the current model,  UAC gets the complete
Large 200 OK (with delayed arrival of 140/141 or you change the current
solution w.r.t. 140/141), but ACK follows the different IP hops etc...

We might be doing congestion handling in SIP for UDP transports in
future, where some of it is provided by other transports. In my purist
mind, SIP messages are becoming huge, so UDP is no more relevant. UDP
was taken initially, as it was simple to transport short SIP message at
that time.

IMHO, Simplicity wins and It is difficult decision for UDP.

Thx
Samir

-----Original Message-----
From: Scott Lawrence [mailto:[email-masked]] 
Sent: Sunday, October 15, 2006 11:10 AM
To: Srivastava, Samir (SC100:8826)
Cc: [email-masked]
Subject: RE: [Sip] I-D on handling large UDP responses

> In spite of current UDP installed base, I am for deprecating UDP. Do 
> we really need to have exception for MESSAGE where it is useful ?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 17:37:46 -0400

Thanks for startign on this problem, Vijay.

I understand how the mechanism can diagnose the problem, but I don't see 
how it can fix it. In particular, when the UAC gets a 140 or 141, and 
then the transaction times out, the document says it should retry with 
congestion controlled transport. Well, that would work on the first hop. 
But nothing in the request would tell the proxy NOT to switch back to 
UDP. Unless you use sips, and thats assuming its implemented AND 
assuming its over TLS and all of that...

Another problem with the mechanism you have proposed is the long delays 
involved in waiting for the transaction to timeout.

You have discarded the 4xx case, and I think it has merit. You are 
correct that it may result in false positives - but so what? There are 
no increases in call setup delays (to me, a worse result). And its 
reliable. It might help solve this problem above if the 4xx response 
contains a URI that reaches the resource that wanted to send the error 
response, but has a DNS entry only for TCP (like a TCP-only GRUU for a 
UAS). The client also retries with TCP. In the trapezoid model this 
would at least get you TCP all the way to the terminating proxy. In 
configurations with many more than that, you do still have the same 
problem of no way of explicitly requesting TCP. We can solve that with a 
Proxy-Require I suppose, though we're talking about a proxy upgrade at 
each hop.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 18 Oct 2006 09:39:44 -0400

> assuming its over TLS and all of that...

The retried request could be sent with a request URI that includes a url
parameter of 'transport=tcp'.  That aught to cause intermediate hops to
try that first at least.

There are going to be cases, such as a proxy in the path that can only
do UDP, where it just won't be possible to make it work reliably.  I
think that the most we can really achieve is a good diagnostic. 

> correct that it may result in false positives - but so what? 

I think that forcing a call to fail that might have succeeded is pretty
serious.

> There are

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 18 Oct 2006 09:44:53 -0400

> solution w.r.t. 140/141), but ACK follows the different IP hops etc...

Are you asking how this helps to detect a lost ACK?  If so, I don't
think that it does, but a lost ACK will cause the final response to be
resent, so you'll know anyway.  Eventually the 14x should arrive,
providing a hint as to the possible problem.  Besides, the only time the
ACK is likely to be lost due to UDP fragmentation is if it has the SDP
answer and is itself large, which the sender already knows.

> was taken initially, as it was simple to transport short SIP message at

I'm hoping that providing better diagnostics that show how UDP fails
will cause end users to put pressure on vendors to support TCP and/or
TLS.