Re: [Sip] draft-ietf-sip-hop-limit-diagnostics-03

inline.

Scott Lawrence wrote:

> On Mon, 2006-06-26 at 09:00 -0700, Cullen Jennings wrote:
> 
>>On Jun 16, 2006, at 2:59 PM, Scott Lawrence wrote:
>>
>>
>>>There are, I think, two issues remaining for discussion:
>>
>>I disagree - I don't think the draft of the discussion has addressed  
>>the issue I brought up.
> 
> 
> I'm going to guess here - do you mean the issue of how large the
> response should be?
> 
> There is text in the draft on _how_ to reduce the size of the response.
> 
> 3261 does not provide guidance clear guidance on response size limits.
> It _does_ say that all implementations MUST be able to handle messages
> up to the maximum UDP packet size, which can probably handle even 70 hop
> messages.  If you think that SIP needs better definition of _when_ to
> limit response sizes and _what_ size they should be limited to, then I
> think that's an interesting discussion, but it's a bigger question than
> this error response and a problem that already exists whether this draft
> is accepted or not.
> 

Well, here is the history.

The transport design of SIP was based on the model that the response 
used the same transport as the request. We had the somewhat naive view 
that the response wouldn't be much larger than the request. So, we would 
take the MTU, subtract off a few hundred bytes to account for any 
possible increase in the size of the response, and that should be OK.

So, the implied limit is the path MTU itself, or 1500 bytes if unknown. 
But this is not stated explicitly, its implicit from the design.

One idea on dealing with the size problem is, instead of including the 
sip-frag in a response, the resposne just indicates that the hop limit 
was exceeded. The server which generated the response then sends a 
request in a totally new transaction, towards the contact of the 
request. That request contains the sip-frag with all of the information, 
and could be sent over TCP if needed.

That idea doesn't work for requests which omit contact, and also means 
that intermediate proxies on the path of the failed request might not 
see the diagnostic information, since it would come over a different 
transaction.

Anyway, just a thought.

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip