IETF Logo Mail Archive

[Sip] RE: Hop limit diagnostics

Sean Olson <Sean.Olson@microsoft.com> Wed, 11 July 2007 18:33 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzk-0001ah-Js; Wed, 11 Jul 2007 14:33:00 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8gzj-0001ZQ-JX for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 14:32:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzi-0001YQ-Sn for sip@ietf.org; Wed, 11 Jul 2007 14:32:58 -0400
Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8gze-0002P5-FL for sip@ietf.org; Wed, 11 Jul 2007 14:32:58 -0400
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.154.1; Wed, 11 Jul 2007 11:32:53 -0700
Received: from df-mlt-04.exchange.corp.microsoft.com (157.54.68.219) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.154.1; Wed, 11 Jul 2007 11:32:53 -0700
Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-mlt-04.exchange.corp.microsoft.com ([157.54.68.219]) with mapi; Wed, 11 Jul 2007 11:32:39 -0700
From: Sean Olson <Sean.Olson@microsoft.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "sip@ietf.org" <sip@ietf.org>
Date: Wed, 11 Jul 2007 11:32:39 -0700
Thread-Topic: Hop limit diagnostics
Thread-Index: AcfDxMmAH4k0yTi8Q9i3/pvfpjBfaAAJOeSQ
Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC556@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc:
Subject: [Sip] RE: Hop limit diagnostics
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

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:drage@alcatel-lucent.com]
Sent: Wednesday, July 11, 2007 7:07 AM
To: sip@ietf.org
Subject: [Sip] Hop limit diagnostics

(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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

v2.23.0 | Report a Bug | By Email