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

["Drage, Keith (Keith)" <[e-mail]>]

We'd also get pretty much the same thing by using the "by reference" mechanism in draft-ietf-sip-location-conveyance.

The server sends a URI to some location where the diagnostic information is placed. All the issues that exist have to be handled for location-conveyance with that mechanism.

Out of interest, for Jonathan's proposal, on networks where we're running on the verge of hop limit expiries for all requests, don't we tend to some form of amplification situation. The server sends the 4xx response plus a new request with the diagnostic information. A certain percentage (because they took slightly longer paths) of the new requests hit the hop limit in the reverse direction and send 4xx back to the original server plus a request containing the diagnostic inforation, etc, etc. Of course, on properly configured networks...

regards

Keith


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: 07 July 2006 06:45
> To: Scott Lawrence
> Cc: Cullen Jennings; SIP WG List
> Subject: 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
> [e-mail]                              FAX:   [phone]
> http://www.jdrosen.net                         PHONE: [phone]
> 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip