Subject: [Sip] Hop limit diagnostics

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 11 Jul 2007 16:07:16 +0200

(As WG chair)

We have a couple of related milestones on our charter that we are stuck
on:

Jul 2007    Diagnostic Responses for SIP Errors to WGLC (PS)  
Nov 2007    Diagnostic Responses for SIP Errors to IESG (PS) 

The draft associated with this expired some way back, but you can find
it at:

http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03

The charter item is for a more general document that covers other error
situations as well as hop limit issues.

However the editor's hit the intractable problem in that any transport
decision is made on the request on any particular hop, and if UDP is
used on the request, it will also be used on the response on any
particular hop. This was specified based on the assumption that any
response would not be significantly larger than the request, but as soon
as we start putting lots of useful diagnostic information in the
response, this no longer applies.

So we are now looking for the way forward. Options include:

A)	It is not worth the extra cycles - delete the milestone.

B)	Limit the diagnostic information (to say around 100 bytes in the
worst case). If so will it contain enough useful information to make it
usable.

C)	Solve the transport problem. And no, we do not have a debate
here on deprecating UDP. We've been there and done that.

Unless people can come up with something that looks achievable, the
working group chairs are currently favouring A) above.

Comments please.

Keith

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Wed, 11 Jul 2007 10:06:42 -0500

For completeness - haven't we also talked about requests in the  
opposite direction and diagnostics
by indirection? I know each of those have their own thorny problems,  
but the tradeoff against really
large responses may make them the least unpalatable.

And I remember conversations, but not much list traffic about a  
series of best-effort provisionals
to carry the information.

I still think its worth figuring out, but won't throw fits if the WG  
decides to put it off to the indefinite future.

RjS

---

From: Sean Olson <[email-masked]>
Date: Wed, 11 Jul 2007 11:32:39 -0700

Why not:

D) Define a diagnostic information mechanism that works with TCP and accept that it will not work with UDP

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, July 11, 2007 7:07 AM
To: [email-masked]
Subject: [Sip] Hop limit diagnostics

(As WG chair)

Comments please.

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 12 Jul 2007 11:23:51 +0200

I believe content-indirection was looked at and also sending a new
request in the reverse direction.

I believe the issue with content indirection was the issue of if the
sender of the original request cannot construct a routeable SIP query,
will they be able to construct a routeable HTTP query to get to the
content indirection server. Would welcome a fuller explanation or
correction here. 

The problem with issuing a new request falls into two parts:

-	it does not solve the problem of standalone transactions like
MESSAGE.

-	will a new request in the reverse direction reach the original
sender given that the routeing path can be totally independent of the
original request.

Again would welcome a fuller explanation or correction here. 

Regards

Keith

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 4:07 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sip] Hop limit diagnostics
> 
> For completeness - haven't we also talked about requests in 
> the opposite direction and diagnostics by indirection? I know 
> each of those have their own thorny problems, but the 
> tradeoff against really large responses may make them the 
> least unpalatable.
> 
> And I remember conversations, but not much list traffic about 
> a series of best-effort provisionals to carry the information.
> 
> I still think its worth figuring out, but won't throw fits if 
> the WG decides to put it off to the indefinite future.
> 
> RjS
> 
> 
> > The charter item is for a more general document that covers other 
> > error situations as well as hop limit issues.
> >
> > response would not be significantly larger than the request, but as 
> > soon as we start putting lots of useful diagnostic 
> information in the 
> > worst case). If so will it contain enough useful 
> information to make 
> > it usable.
> >
> > 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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 12 Jul 2007 15:23:15 +0200

So to explore further. 

If the final hop is TCP and a preceding hop is UDP, does it just get
thrown away at the transport protocol boundary in this solution.

Regards

Keith

> From: Sean Olson [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 7:33 PM
> To: DRAGE, Keith (Keith); [email-masked]
> Subject: RE: Hop limit diagnostics
> 
> Why not:
> 
> D) Define a diagnostic information mechanism that works with 
> TCP and accept that it will not work with UDP
> 
> 
> 
> The draft associated with this expired some way back, but you 
> can find it at:
> 
> The charter item is for a more general document that covers 
> other error situations as well as hop limit issues.
> 
> However the editor's hit the intractable problem in that any 
> transport decision is made on the request on any particular 
> hop, and if UDP is used on the request, it will also be used 
> on the response on any particular hop. This was specified 
> based on the assumption that any response would not be 
> significantly larger than the request, but as soon as we 
> start putting lots of useful diagnostic information in the 
> worst case). If so will it contain enough useful information 
> to make it usable.
> 
> Unless people can come up with something that looks 
> achievable, the working group chairs are currently favouring A) above.
> 
> Comments please.
> 
> 
> Keith
> 
> 
> [email-masked] for questions on current sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Jul 2007 08:55:43 -0500

> Again would welcome a fuller explanation or correction here. 

A bit of the latter was explored in S4.3 of a now expired,
though still archived draft on handling large UDP responses.
See http://tools.ietf.org/html/draft-gurbani-sip-large-udp-response-00.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Sean Olson <[email-masked]>
Date: Thu, 12 Jul 2007 11:43:11 -0700

Yes, I think that would be appropriate.  I hate to throw out features/improvement just because they don't work over UDP.

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Thursday, July 12, 2007 6:23 AM
To: Sean Olson; [email-masked]
Subject: RE: Hop limit diagnostics

So to explore further.

Regards

Keith