Re: [Tsvwg] SCTP stream EOF

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Wed, 17 September 2008 19:01 UTC

Return-Path: <tsvwg-bounces@ietf.org>
X-Original-To: tsvwg-archive@optimus.ietf.org
Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4CE28C29A; Wed, 17 Sep 2008 12:01:30 -0700 (PDT)
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 32E5A3A68D3 for <tsvwg@core3.amsl.com>; Wed, 17 Sep 2008 12:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 HT99z86oVBT5 for <tsvwg@core3.amsl.com>; Wed, 17 Sep 2008 12:01:28 -0700 (PDT)
Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 970C93A69B1 for <tsvwg@ietf.org>; Wed, 17 Sep 2008 12:01:09 -0700 (PDT)
Received: from [IPv6:2002:508f:c56f::21e:c2ff:fe00:76c8] (unknown [IPv6:2002:508f:c56f:0:21e:c2ff:fe00:76c8]) by mail-n.franken.de (Postfix) with ESMTP id 44FE71C0C0BCA; Wed, 17 Sep 2008 20:56:15 +0200 (CEST)
Message-Id: <3BC05FBC-20D3-419B-8170-9EA52618C7AD@lurchi.franken.de>
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
To: Florian Niederbacher <florian.niederbacher@student.uibk.ac.at>
In-Reply-To: <48D10AD3.10307@student.uibk.ac.at>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 17 Sep 2008 20:56:14 +0200
References: <48D10AD3.10307@student.uibk.ac.at>
X-Mailer: Apple Mail (2.929.2)
Cc: tsvwg@ietf.org
Subject: Re: [Tsvwg] SCTP stream EOF
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: <https://www.ietf.org/mailman/private/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>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org

On Sep 17, 2008, at 3:49 PM, Florian Niederbacher wrote:

> Hi,
> I would ask what are you thinking about a definition for an EOF on  
> streams in SCTP. My problem is that I would need a signaling method  
> to report an EOF without closing the whole SCTP association. If I am  
> right, socket connections get only an EOF if the connection will be  
> closed (no sending of EOF on socktes in another way is possible). In  
> draft-stewart-tsvwg-sctpstrrst-00 the possibility the reset of  
> streams is discussed. This would also be a solution if you can check  
> the numbering sequence in User Space.
Using the stream reset ID, you could this. There is currently no  
socket API defined for it
in an ID, but it seems to be a good idea to get a notification on the  
receiver side.
>
> A proposal would be to generate an SCTP_EVENT e.g. SCTP_STREAM_EOF  
> to signal EOF on streams. In this way you can stop receiving and  
> also reuse the stream or at least continue in multi-streamed network  
> applications, if you use different threads or processes for the  
> receiving procedure on streams. Maybe an other possibility exists to  
> signal an EOF on SCTP streams, but at the moment I can't find any  
> solution to deal with this problem. What are your proposals and  
> comments?
As said above, sctp reset with a notification should do it...
>
>
> Best regards
> Florian Niederbacher