Re: [Tsvwg] SCTP: new chunks definition

Randall Stewart <rrs@lakerest.net> Mon, 02 March 2009 14:09 UTC

Return-Path: <rrs@lakerest.net>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E38E3A6861 for <tsvwg@core3.amsl.com>; Mon, 2 Mar 2009 06:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QvM0OxMLfyS for <tsvwg@core3.amsl.com>; Mon, 2 Mar 2009 06:09:14 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 0609E3A67E1 for <tsvwg@ietf.org>; Mon, 2 Mar 2009 06:09:13 -0800 (PST)
Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n22E9jg2020008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Mar 2009 09:09:46 -0500 (EST) (envelope-from rrs@lakerest.net)
Message-Id: <85201008-04C3-497F-A9BF-2C960B7D080E@lakerest.net>
From: Randall Stewart <rrs@lakerest.net>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <345F8ADB-42B3-4283-ADFD-AB0880BAB5E7@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 02 Mar 2009 09:09:35 -0500
References: <296afac70903012356y6dd06d13s7a06a75d7dbb5417@mail.gmail.com> <406B9630-F52C-456A-9062-AB1D2BB65804@lakerest.net> <296afac70903020546j4cf83fc0o4eb1292dc03f7b4e@mail.gmail.com> <345F8ADB-42B3-4283-ADFD-AB0880BAB5E7@lurchi.franken.de>
X-Mailer: Apple Mail (2.930.3)
Cc: Andrey Konstantinov <avkonst@gmail.com>, tsvwg@ietf.org
Subject: Re: [Tsvwg] SCTP: new chunks definition
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 14:09:15 -0000

Opps.

It appears my posting are not going .. need to get the right
from email address..

Bottom line.. Yes I agree with Michael and Brian here. We would
need a far vaster understanding of why one would want to do this.

It does not make sense to me.. I am sure there is more to
it then just the desire not to implement a hash table...

Andrey is most welcome to write a draft on the subject. But I don't
think he will find support in the SCTP community without more
details..

Regards


R
On Mar 2, 2009, at 8:50 AM, Michael Tüxen wrote:

> On Mar 2, 2009, at 2:46 PM, Andrey Konstantinov wrote:
>
>> Hi,
>>
>> If extend it for V-Tag resetting it could suit...
> The problem remains: Why do you want this?
> Without having a good reason why you want to change
> the v-tag, I hesitating to put that into an ID.
> It might be a good thing (then I would support adding
> it), it might be a bad thing... Currently I see no
> good reason why you want to change the v-tag...
>
> Randy?
>>
>> Thanks, I'll take it into account.
>>
>> Best regards,
>> Andrey Konstantinov
>>
>> 2009/3/2 Randy Stewart <randall@lakerest.net>:
>>> Andrey:
>>>
>>> Please go take a close examination of:
>>>
>>> http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpstrrst-01.txt
>>>
>>>
>>> This already has a mechanism to do some of the things you are
>>> interested in I think.
>>>
>>> R
>>> On Mar 2, 2009, at 2:56 AM, Andrey Konstantinov wrote:
>>>
>>>> Dear experts,
>>>>
>>>> I am looking for the possibility to change local V-Tag of the
>>>> association in run time without it's restart.
>>>>
>>>> The idea of the extension is following:
>>>> Local SCTP asks remote SCTP to change V-Tag (firstly defined by  
>>>> local
>>>> side during start-up).
>>>> I guess new chunk should be defined for this purpose. Remote side
>>>> changes it and acknowledges the operation with help of another new
>>>> chunk.
>>>> INIT and INIT_ACK chunks are extended in order to negotiate  
>>>> support of
>>>> the feature during start-up.
>>>>
>>>> Could you point me out to a RFC or draft if a similar extension of
>>>> SCTP has been already defined?
>>>>
>>>> If I am the first with such type of request could you provide me  
>>>> input
>>>> information how can we register, develop, review and approve this
>>>> extension with IETF?
>>>> The company which will possibly drive the development of the  
>>>> extension
>>>> is Ericsson and/or Tieto.
>>>>
>>>> Thanks in advance,
>>>> Andrey Konstantinov
>>>>
>>>
>>> -----
>>> Randall Stewart
>>> randall@lakerest.net
>>>
>>>
>>>
>>>
>>>
>>
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)