Re: [Tsvwg] Event Notifications

[Chris Benson <[e-mail]>]

Vlad (and Kacheong and Michael),

> [...] suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC

Please pluralize the macro names though ...

    SCTP_ALL_ASSOCS and SCTP_FUTURE_ASSOCS

:-D

Chris Benson, Adax inc.

On Fri, 27 Feb 2009, Vlad Yasevich wrote:

>>  Date: Fri, 27 Feb 2009 16:12:30 -0500
>>  From: Vlad Yasevich <[e-mail]>
>>  To: Kacheong Poon <[e-mail]>
>>  Cc: Michael T?xen <[e-mail]>,
>>      tsvwg <[e-mail]>, Randy Stewart <[e-mail]>
>>  Subject: Re: [Tsvwg] Event Notifications
>>  
>>  > 
>>  >> I do not care that much about the name...
>>  >> So you are suggesting SCTP_ALL_ASSOC and SCTP_FUTURE_ASSOC?
>>  > 
>>  > 
>>  > They are fine.
>>  > 
>>  > 
>>  
>>  Fine with me as well.
>>  
>>  -vlad
>>  

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AE928C229 for <[e-mail]>; Thu,  5 Feb 2009 03:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.691
X-Spam-Level: 
X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.258,  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 X8se8ERhllx8 for <[e-mail]>; Thu,  5 Feb 2009 03:40:44 -0800 (PST)
Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by core3.amsl.com (Postfix) with ESMTP id 6D7093A6940 for <[e-mail]>; Thu,  5 Feb 2009 03:40:44 -0800 (PST)
Received: from [192.168.1.4] (p5481F450.dip.t-dialin.net [84.129.244.80]) by mail-n.franken.de (Postfix) with ESMTP id B5E821C0B4621; Thu,  5 Feb 2009 12:40:18 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: tsvwg <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 5 Feb 2009 12:40:17 +0100
X-Mailer: Apple Mail (2.930.3)
Cc: Robin Seggelmann <[e-mail]>
Subject: [Tsvwg] DTLS interop server available on interop.fh-muenster.de
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 11:40:54 -0000

Dear all,

Robin and myself have setup an DTLS interop server at
interop.fh-muenster.de (195.37.125.98).

It runs an echo and discard server for DTLS/UDP and
DTLS/SCTP.

The DTLS implementation use is the one from OpenSSL with
Robins bug fixes available at
http://sctp.fh-muenster.de

If you have comments, questions, found bugs or anything else
related to the above interop testing, please send an e-mail to
[e-mail] or [e-mail].

Best regards
Michael



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60AD3A6AFE for <[e-mail]>; Thu,  5 Feb 2009 06:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 8R2NUYg10WzU for <[e-mail]>; Thu,  5 Feb 2009 06:32:51 -0800 (PST)
Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by core3.amsl.com (Postfix) with ESMTP id 438263A698E for <[e-mail]>; Thu,  5 Feb 2009 06:32:51 -0800 (PST)
Received: (qmail 25602 invoked from network); 5 Feb 2009 14:32:31 -0000
Received: from imac.asomi.com ([e-mail]@[66.92.48.27]) (envelope-sender <[e-mail]>) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 5 Feb 2009 14:32:31 -0000
Message-ID: <[e-mail]>
Date: Thu, 05 Feb 2009 06:32:31 -0800
From: Caitlin Bestler <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Transport WG <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Tsvwg] draft-ietf-sctpsocket-18: sinfo_context and successful sendmsg
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 14:32:52 -0000

This is a repost - the original went astray.
--------------------------------------------



In the current draft the sinfo_context is only specified to be
returned "back to the upper layer if an error occurs" [page 25].

RDMA interfaces typically have an option where transmit requests
will generate an explicit completion even if the operation completes
successfully.

When iWARP is implemented over SCTP sockets it would be useful to
have an option where the sinfo_context would be returned for a
specific SCTP message even when no error occurs. I would propose
that an additional sendmsg() flag be defined for this option.
The same completion mechanism as used for errors could be used,
just with a "no error" error code.







Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id BF47A3A6985; Mon,  9 Feb 2009 07:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Feb 2009 07:15:01 -0800 (PST)
Cc: [e-mail]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-10.txt
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 15:15:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.


	Title           : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-10.txt
	Pages           : 37
	Date            : 2009-02-09

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set
of administrative domains that closely coordinate their network
policy and network design.  The mechanisms defined in this document
can be used for a session whose path spans over such a controlled
environment in order to elevate the session establishment probability
through the controlled environment (thereby elevating the end to end
session establishment probability).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-emergency-rsvp-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id E31A23A6ACE; Mon, 16 Feb 2009 06:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 16 Feb 2009 06:15:01 -0800 (PST)
Cc: [e-mail]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-sctpsocket-19.txt
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2009 14:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.


	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-19.txt
	Pages           : 87
	Date            : 2009-02-16

This document describes a mapping of the Stream Control Transmission
Protocol SCTP into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-sctpsocket-19.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 1C8E63A6917; Wed, 18 Feb 2009 11:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 18 Feb 2009 11:15:02 -0800 (PST)
Cc: [e-mail]
Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-emergency-rsvp-11.txt
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 19:15:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.


	Title           : Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-11.txt
	Pages           : 37
	Date            : 2009-02-18

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-emergency-rsvp-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DC63A689C for <[e-mail]>; Mon, 23 Feb 2009 13:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Sv3ePJhDKtwS for <[e-mail]>; Mon, 23 Feb 2009 13:05:18 -0800 (PST)
Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id D1DDF3A6833 for <[e-mail]>; Mon, 23 Feb 2009 13:05:18 -0800 (PST)
Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 719D8381D0; Mon, 23 Feb 2009 21:05:36 +0000 (UTC)
Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id BBF8E1001D; Mon, 23 Feb 2009 21:05:35 +0000 (UTC)
Message-ID: <[e-mail]>
Date: Mon, 23 Feb 2009 16:05:34 -0500
From: Vlad Yasevich <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Michael Tuexen <[e-mail]>,  Randall Stewart <[e-mail]>, Kacheong Poon <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tsvwg <[e-mail]>
Subject: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 21:05:19 -0000

Hi All

I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
After re-rereading the spec, I realized that the text is rather sparse.

The first question that came to mind was whether this should be limited
to 1-1 sockets (as it appears to be), or should it also be available
for 1-many sockets?  If the later, the API needs to change to include
the association id.

The other thing is that we need to explain the limitation of this
option wrt. to multi-streaming.  I've had to explain to a few users
already this limitation and it considerable changed their plans.

Additionally,  since there is no signaling mechanism that lets a peer
know that this API is in use, there needs to some guidance here as well.
As it stands right now,  when the sender uses this option, the receiver
needs to reset its partial deliver point so that data gets delivered instead
of waiting to be fully reassembled, which may be a very long time.

-vlad





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498603A6858 for <[e-mail]>; Tue, 24 Feb 2009 01:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ucRI3bua6uCp for <[e-mail]>; Tue, 24 Feb 2009 01:37:20 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id C6C373A6942 for <[e-mail]>; Tue, 24 Feb 2009 01:37:19 -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 n1O9bVvD067517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Feb 2009 04:37:42 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: Vlad Yasevich <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 24 Feb 2009 04:37:21 -0500
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Michael Tuexen <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 09:37:21 -0000

On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:

> Hi All
>
> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
> After re-rereading the spec, I realized that the text is rather  
> sparse.
>
> The first question that came to mind was whether this should be  
> limited
> to 1-1 sockets (as it appears to be), or should it also be available
> for 1-many sockets?  If the later, the API needs to change to include
> the association id.

Hmm if you get that impression it is INCORRECT. the explicit EOR mode
should work no matter if you are one-2-one or one-2-many.

If you are on a 1-2-m socket then once you do a EOR mode on
that assoc whenever you write to that one association, until
you explicitly say "EOR" you are sending to that same stream. In
fact the BSD implementation will give you an error if you try
to change the stream number. So for example I could do

socketopt(12msd, set EOR mode, assoc1);
send("msgpart1", assoc1, stream-1);
send("mspart2", assoc1, stream-1)
send("entire msg", assoc2, stream-8);
send("mspart3", assoc1, stream-1);

If I tried
send ("msgforanotherstream", assoc1, stream-5); // ERRROR return

Until I finally do

send ("msgfinalpart", assoc1, stream-1, "EEOR");

Now once this last one is done I can send again to some
other stream

send ("newmsg", assoc1, stream-N);

For that matter I could send just like EEOR mode was off if I did:

send ("newmsg", assoc1, stream-N, "EEOR");

I should have lots of time after March 4th to look at the i-d I will
see if I can't tighten up the wording a bit :-)

>
>
> The other thing is that we need to explain the limitation of this
> option wrt. to multi-streaming.  I've had to explain to a few users
> already this limitation and it considerable changed their plans.

Yes, it needs to stated explicitly if you start sending to stream-x
until you do EOR you must send to stream-x... at least thats
the way I envisioned it. If you will until you indicate EEOR
the connection becomes no different than a TCP connection... i.e.
a stream of bytes. Hmm.. I wonder if we could lift this restriction..
I will have to think about that...

>
>
> Additionally,  since there is no signaling mechanism that lets a peer
> know that this API is in use, there needs to some guidance here as  
> well.
> As it stands right now,  when the sender uses this option, the  
> receiver
> needs to reset its partial deliver point so that data gets delivered  
> instead
> of waiting to be fully reassembled, which may be a very long time.

Yep, the only reasonable way to use this is to set the PD-API point to  
1. This
way you will not be stuck waiting for data without being aware of it :-)

I am sure we need to add a bit of text here :-)

R

>
>
> -vlad
>
>
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8424B3A6874 for <[e-mail]>; Tue, 24 Feb 2009 05:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.605
X-Spam-Level: 
X-Spam-Status: No, score=-104.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Ea6a1g0Y79Gg for <[e-mail]>; Tue, 24 Feb 2009 05:23:55 -0800 (PST)
Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 8BD393A6839 for <[e-mail]>; Tue, 24 Feb 2009 05:23:55 -0800 (PST)
Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 3A4E1240DF; Tue, 24 Feb 2009 13:24:14 +0000 (UTC)
Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id 4F7FE10007; Tue, 24 Feb 2009 13:24:13 +0000 (UTC)
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2009 08:24:12 -0500
From: Vlad Yasevich <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Randy Stewart <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Michael Tuexen <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 13:23:56 -0000

Randy Stewart wrote:
> 
> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
> 
>> Hi All
>>
>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>> After re-rereading the spec, I realized that the text is rather sparse.
>>
>> The first question that came to mind was whether this should be limited
>> to 1-1 sockets (as it appears to be), or should it also be available
>> for 1-many sockets?  If the later, the API needs to change to include
>> the association id.
> 
> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
> should work no matter if you are one-2-one or one-2-many.

I get this "impression" because the is no way to turn on explicit EOR on
an association.  The interface doesn't allow one to pass the association
id to the kernel.  Thus, it's really a per-socket value, meaning that every
association on a 1-many socket would use explicit EOR mode.  If we want
to offer full support for 1-many api, we need change the option api to
be able to take association id, just like most other API already specified.

> 
> If you are on a 1-2-m socket then once you do a EOR mode on
> that assoc whenever you write to that one association, until
> you explicitly say "EOR" you are sending to that same stream. In
> fact the BSD implementation will give you an error if you try
> to change the stream number. So for example I could do
> 
> socketopt(12msd, set EOR mode, assoc1);

But you can't with the api.  Generic setsockopt doesn't take assoc id.

Thanks
-vlad

> send("msgpart1", assoc1, stream-1);
> send("mspart2", assoc1, stream-1)
> send("entire msg", assoc2, stream-8);
> send("mspart3", assoc1, stream-1);
> 
> If I tried
> send ("msgforanotherstream", assoc1, stream-5); // ERRROR return
> 
> Until I finally do
> 
> send ("msgfinalpart", assoc1, stream-1, "EEOR");
> 
> Now once this last one is done I can send again to some
> other stream
> 
> send ("newmsg", assoc1, stream-N);
> 
> For that matter I could send just like EEOR mode was off if I did:
> 
> send ("newmsg", assoc1, stream-N, "EEOR");
> 
> I should have lots of time after March 4th to look at the i-d I will
> see if I can't tighten up the wording a bit :-)
> 
>>
>>
>> The other thing is that we need to explain the limitation of this
>> option wrt. to multi-streaming.  I've had to explain to a few users
>> already this limitation and it considerable changed their plans.
> 
> Yes, it needs to stated explicitly if you start sending to stream-x
> until you do EOR you must send to stream-x... at least thats
> the way I envisioned it. If you will until you indicate EEOR
> the connection becomes no different than a TCP connection... i.e.
> a stream of bytes. Hmm.. I wonder if we could lift this restriction..
> I will have to think about that...
> 
>>
>>
>> Additionally,  since there is no signaling mechanism that lets a peer
>> know that this API is in use, there needs to some guidance here as well.
>> As it stands right now,  when the sender uses this option, the receiver
>> needs to reset its partial deliver point so that data gets delivered
>> instead
>> of waiting to be fully reassembled, which may be a very long time.
> 
> Yep, the only reasonable way to use this is to set the PD-API point to
> 1. This
> way you will not be stuck waiting for data without being aware of it :-)
> 
> I am sure we need to add a bit of text here :-)
> 
> R
> 
>>
>>
>> -vlad
>>
>>
>>
> 
> -----
> Randall Stewart
> [e-mail]
> 
> 
> 
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C719E28C244 for <[e-mail]>; Tue, 24 Feb 2009 10:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.458
X-Spam-Level: 
X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1quGcschA0Br for <[e-mail]>; Tue, 24 Feb 2009 10:29:28 -0800 (PST)
Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id A178028C168 for <[e-mail]>; Tue, 24 Feb 2009 10:29:28 -0800 (PST)
Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 852003825E; Tue, 24 Feb 2009 18:29:47 +0000 (UTC)
Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id AD9E610020; Tue, 24 Feb 2009 18:29:46 +0000 (UTC)
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2009 13:29:45 -0500
From: Vlad Yasevich <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>, Randy Stewart <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2009 18:29:31 -0000

Michael Tüxen wrote:
> Hi Vlad,
> 
> comments in-line.
> 
> Best regards
> Michael
> 
> On Feb 24, 2009, at 2:24 PM, Vlad Yasevich wrote:
> 
>> Randy Stewart wrote:
>>>
>>> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
>>>
>>>> Hi All
>>>>
>>>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>>>> After re-rereading the spec, I realized that the text is rather sparse.
>>>>
>>>> The first question that came to mind was whether this should be limited
>>>> to 1-1 sockets (as it appears to be), or should it also be available
>>>> for 1-many sockets?  If the later, the API needs to change to include
>>>> the association id.
>>>
>>> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
>>> should work no matter if you are one-2-one or one-2-many.
>>
>> I get this "impression" because the is no way to turn on explicit EOR on
>> an association.  The interface doesn't allow one to pass the association
>> id to the kernel.  Thus, it's really a per-socket value, meaning that
>> every
>> association on a 1-many socket would use explicit EOR mode.  If we want
>> to offer full support for 1-many api, we need change the option api to
>> be able to take association id, just like most other API already
>> specified.
> We could use
> 
>    struct sctp_assoc_value {
>      sctp_assoc_t assoc_id;
>      uint32_t assoc_value;
>    };
> 
> instead of an int and use assoc_value to enable/disable if we want
> to be able to control this on a per association base, which makes sense
> for me.
> Kacheong, what do you think?

Hi Michael

That would work.  If assoc_id is set to 0, option applies to socket
and future associations.

>>
>>>
>>> If you are on a 1-2-m socket then once you do a EOR mode on
>>> that assoc whenever you write to that one association, until
>>> you explicitly say "EOR" you are sending to that same stream. In
>>> fact the BSD implementation will give you an error if you try
>>> to change the stream number. So for example I could do
>>>
>>> socketopt(12msd, set EOR mode, assoc1);
>>
>> But you can't with the api.  Generic setsockopt doesn't take assoc id.
> Correct. We can't do this for socket options. And we can't enable
> notifications on a per association base. Should we change that too?

Hmm..  That's an interesting question.  Is it a possible scenario where
an application decides to change event subscription of an association after
it's established?  I can't see a reason right now, but that doesn't mean it
doesn't exist.

On the other hand, I see an application wanting to temporarily enable EEOR,
to transfer a very large message, and then turn EEOR off again.  It's simple
on the 1-1 socket, but on a 1-many you can change the setting for a single
association without peeling it off.

Thanks
-vlad

>>
>>
>> Thanks
>> -vlad
>>
>>> send("msgpart1", assoc1, stream-1);
>>> send("mspart2", assoc1, stream-1)
>>> send("entire msg", assoc2, stream-8);
>>> send("mspart3", assoc1, stream-1);
>>>
>>> If I tried
>>> send ("msgforanotherstream", assoc1, stream-5); // ERRROR return
>>>
>>> Until I finally do
>>>
>>> send ("msgfinalpart", assoc1, stream-1, "EEOR");
>>>
>>> Now once this last one is done I can send again to some
>>> other stream
>>>
>>> send ("newmsg", assoc1, stream-N);
>>>
>>> For that matter I could send just like EEOR mode was off if I did:
>>>
>>> send ("newmsg", assoc1, stream-N, "EEOR");
>>>
>>> I should have lots of time after March 4th to look at the i-d I will
>>> see if I can't tighten up the wording a bit :-)
>>>
>>>>
>>>>
>>>> The other thing is that we need to explain the limitation of this
>>>> option wrt. to multi-streaming.  I've had to explain to a few users
>>>> already this limitation and it considerable changed their plans.
>>>
>>> Yes, it needs to stated explicitly if you start sending to stream-x
>>> until you do EOR you must send to stream-x... at least thats
>>> the way I envisioned it. If you will until you indicate EEOR
>>> the connection becomes no different than a TCP connection... i.e.
>>> a stream of bytes. Hmm.. I wonder if we could lift this restriction..
>>> I will have to think about that...
>>>
>>>>
>>>>
>>>> Additionally,  since there is no signaling mechanism that lets a peer
>>>> know that this API is in use, there needs to some guidance here as
>>>> well.
>>>> As it stands right now,  when the sender uses this option, the receiver
>>>> needs to reset its partial deliver point so that data gets delivered
>>>> instead
>>>> of waiting to be fully reassembled, which may be a very long time.
>>>
>>> Yep, the only reasonable way to use this is to set the PD-API point to
>>> 1. This
>>> way you will not be stuck waiting for data without being aware of it :-)
>>>
>>> I am sure we need to add a bit of text here :-)
>>>
>>> R
>>>
>>>>
>>>>
>>>> -vlad
>>>>
>>>>
>>>>
>>>
>>> -----
>>> Randall Stewart
>>> [e-mail]
>>>
>>>
>>>
>>>
>>
>>
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C8D3A6928 for <[e-mail]>; Tue, 24 Feb 2009 19:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 wiZRyciCWKMP for <[e-mail]>; Tue, 24 Feb 2009 19:33:12 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 194903A680A for <[e-mail]>; Tue, 24 Feb 2009 19:33:12 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P3XT7O015125; Wed, 25 Feb 2009 03:33:30 GMT
Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1P3XOIX782072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 19:33:26 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2009 11:33:25 +0800
From: Kacheong Poon <[e-mail]>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 2.0.0.19 (X11/20090110)
MIME-Version: 1.0
To: Vlad Yasevich <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, tsvwg <[e-mail]>, Randy Stewart <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 03:33:13 -0000

Vlad Yasevich wrote:
> Michael Tüxen wrote:
...
>> We could use
>>
>>    struct sctp_assoc_value {
>>      sctp_assoc_t assoc_id;
>>      uint32_t assoc_value;
>>    };
>>
>> instead of an int and use assoc_value to enable/disable if we want
>> to be able to control this on a per association base, which makes sense
>> for me.
>> Kacheong, what do you think?
> 
> Hi Michael
> 
> That would work.  If assoc_id is set to 0, option applies to socket
> and future associations.


This is fine.


>> Correct. We can't do this for socket options. And we can't enable
>> notifications on a per association base. Should we change that too?
> 
> Hmm..  That's an interesting question.  Is it a possible scenario where
> an application decides to change event subscription of an association after
> it's established?  I can't see a reason right now, but that doesn't mean it
> doesn't exist.


I am also not sure if it is worthwhile to do that.


-- 

						K. Poon.
						[e-mail]



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EBC3A6928 for <[e-mail]>; Tue, 24 Feb 2009 19:46:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.896
X-Spam-Level: 
X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 4XZ7CCMlHjmK for <[e-mail]>; Tue, 24 Feb 2009 19:46:40 -0800 (PST)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 1DFDD3A67B2 for <[e-mail]>; Tue, 24 Feb 2009 19:46:40 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1P3krsQ022147; Wed, 25 Feb 2009 03:46:53 GMT
Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1P3kmPN784527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 19:46:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2009 11:46:50 +0800
From: Kacheong Poon <[e-mail]>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 2.0.0.19 (X11/20090110)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Vlad Yasevich <[e-mail]>, tsvwg <[e-mail]>, Randy Stewart <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 03:46:41 -0000

Michael Tüxen wrote:
> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
...
>> Hmm..  That's an interesting question.  Is it a possible scenario where
>> an application decides to change event subscription of an association 
>> after
>> it's established?  I can't see a reason right now, but that doesn't 
>> mean it
>> doesn't exist.
> We do this for the DRY event since we are only interested in it
> during some specific states in DTLS (during renegotiations).


If we want to explore this, I'd suggest we retire (just keep
it there for backward compatibility) the sctp_event_subscribe.
It is not extensible.  Just use sctp_assoc_value.  An app can
subscribe/unsubscribe each event one by one.

BTW, I guess it should not cause a problem if the DRY event is
enabled for all associations controlled by one socket all the
time.


-- 

						K. Poon.
						[e-mail]



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F9D3A68E4 for <[e-mail]>; Wed, 25 Feb 2009 00:22:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 CHayVpG96JHR for <[e-mail]>; Wed, 25 Feb 2009 00:22:57 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 79E093A6B56 for <[e-mail]>; Wed, 25 Feb 2009 00:22:56 -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 n1P8NKdj036364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 03:23:21 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: Kacheong Poon <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 03:23:10 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 08:22:59 -0000

On Feb 24, 2009, at 10:33 PM, Kacheong Poon wrote:

> Vlad Yasevich wrote:
>> Michael T=FCxen wrote:
> ...
>>> We could use
>>>
>>>   struct sctp_assoc_value {
>>>     sctp_assoc_t assoc_id;
>>>     uint32_t assoc_value;
>>>   };
>>>
>>> instead of an int and use assoc_value to enable/disable if we want
>>> to be able to control this on a per association base, which makes =20=

>>> sense
>>> for me.
>>> Kacheong, what do you think?
>> Hi Michael
>> That would work.  If assoc_id is set to 0, option applies to socket
>> and future associations.
>
>
> This is fine.

Yeah, I agree here.. and I had missed the fact that
I forgot to add on/off EOR mode for per assoc... good catch
lets add this (and I will fix my code too :-D)


>
>
>
>>> Correct. We can't do this for socket options. And we can't enable
>>> notifications on a per association base. Should we change that too?
>> Hmm..  That's an interesting question.  Is it a possible scenario =20
>> where
>> an application decides to change event subscription of an =20
>> association after
>> it's established?  I can't see a reason right now, but that doesn't =20=

>> mean it
>> doesn't exist.
>
>
> I am also not sure if it is worthwhile to do that.


I agree here too.. I don't see the value in notifications on a per
assoc basis...

R
>
>
>
> --=20
>
> 						K. Poon.
> 						[e-mail]
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035533A6B62 for <[e-mail]>; Wed, 25 Feb 2009 00:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 a6NJuNs-NfdM for <[e-mail]>; Wed, 25 Feb 2009 00:32:28 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 3FC4F3A6951 for <[e-mail]>; Wed, 25 Feb 2009 00:32:27 -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 n1P8WsuM036700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 03:32:54 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: Kacheong Poon <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 03:32:44 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 08:32:30 -0000

On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:

> Michael T=FCxen wrote:
>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
> ...
>>> Hmm..  That's an interesting question.  Is it a possible scenario =20=

>>> where
>>> an application decides to change event subscription of an =20
>>> association after
>>> it's established?  I can't see a reason right now, but that =20
>>> doesn't mean it
>>> doesn't exist.
>> We do this for the DRY event since we are only interested in it
>> during some specific states in DTLS (during renegotiations).
>
>
> If we want to explore this, I'd suggest we retire (just keep
> it there for backward compatibility) the sctp_event_subscribe.
> It is not extensible.  Just use sctp_assoc_value.  An app can
> subscribe/unsubscribe each event one by one.
>
> BTW, I guess it should not cause a problem if the DRY event is
> enabled for all associations controlled by one socket all the
> time.
>

Hmm so let me summarize what I think we have agreed to so far

1) We will add support for using the sctp_assoc_value structure
    to turn on/off EEOR mode on a per assoc basis.
2) If the value of the assoc is 0, then the entire socket (1-2many or =20=

1-1) is
    set to EEOR mode this includes future and all existing sockets.


On the events... I am not convinced a per-assoc subscription is
needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
socket .. you know if you are sending and can turn it off as soon
as the dry-event occurs. If you get a dry event on another
association, you can pretty easily ignore it. It might be nice
to have per-association on/off of some events. But I am mixed
on how useful that is.

I do agree with Kacheong here though, if we have to go this route we
need a new structure.. i.e. one that includes an assoc id.. and then
do the thing that says if the assoc-id=3D=3D0 its to future associations
or the entire socket... vs just changing a single association. I would
also think we want to make it more extensible and as Kacheong said
just retire the old SCTP_EVENTS... i.e. support for backward =20
compatibility
but move to the new structure for future things..

But again, is this really worth it? I am not convinced it is yet..

R



>
> --=20
>
> 						K. Poon.
> 						[e-mail]
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9863A686C for <[e-mail]>; Wed, 25 Feb 2009 01:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.032
X-Spam-Level: ****
X-Spam-Status: No, score=4.032 tagged_above=-999 required=5 tests=[AWL=1.994,  BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311,  MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 xSsZAZ-GQcdK for <[e-mail]>; Wed, 25 Feb 2009 01:35:27 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A3C0D3A6781 for <[e-mail]>; Wed, 25 Feb 2009 01:35:26 -0800 (PST)
Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 313271C0B4620; Wed, 25 Feb 2009 10:35:41 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: Randy Stewart <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 10:35:40 +0100
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 09:35:28 -0000

On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:

>
> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>
>> Michael T=FCxen wrote:
>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>> ...
>>>> Hmm..  That's an interesting question.  Is it a possible scenario =20=

>>>> where
>>>> an application decides to change event subscription of an =20
>>>> association after
>>>> it's established?  I can't see a reason right now, but that =20
>>>> doesn't mean it
>>>> doesn't exist.
>>> We do this for the DRY event since we are only interested in it
>>> during some specific states in DTLS (during renegotiations).
>>
>>
>> If we want to explore this, I'd suggest we retire (just keep
>> it there for backward compatibility) the sctp_event_subscribe.
>> It is not extensible.  Just use sctp_assoc_value.  An app can
>> subscribe/unsubscribe each event one by one.
>>
>> BTW, I guess it should not cause a problem if the DRY event is
>> enabled for all associations controlled by one socket all the
>> time.
>>
>
> Hmm so let me summarize what I think we have agreed to so far
>
> 1) We will add support for using the sctp_assoc_value structure
>   to turn on/off EEOR mode on a per assoc basis.
> 2) If the value of the assoc is 0, then the entire socket (1-2many =20
> or 1-1) is
>   set to EEOR mode this includes future and all existing sockets.
>
>
> On the events... I am not convinced a per-assoc subscription is
> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
> socket .. you know if you are sending and can turn it off as soon
> as the dry-event occurs. If you get a dry event on another
> association, you can pretty easily ignore it. It might be nice
> to have per-association on/off of some events. But I am mixed
> on how useful that is.
>
> I do agree with Kacheong here though, if we have to go this route we
> need a new structure.. i.e. one that includes an assoc id.. and then
> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
> or the entire socket... vs just changing a single association. I would
> also think we want to make it more extensible and as Kacheong said
> just retire the old SCTP_EVENTS... i.e. support for backward =20
> compatibility
> but move to the new structure for future things..
>
> But again, is this really worth it? I am not convinced it is yet..
There are two points here specific to the DRY event:

1. Performance: I might be interested only in the events for one
    particular association, but I get them for all. Of course I
    can ignore them for all associations I'm not interested in,
    but this means the kernel is going to generate a lot of =20
notifications
    I'm not interested in. This is just waisted cycles and mbufs.

2. The DRY event is generated when it is enabled and the the association
    is dry.  So assume I have N associations (being dry), I'm interested
    in one. Now I enable it. The kernel has to generate N notifications
    instantly. This might be a resource problem (on Mac OS X I ran into
    it), because you need N mbufs at about the same time. There is also
    no "flow control" for notifications.
    That is why I implemented this currently only for 1-to-1 style =20
sockets.

But I think we should be more future proof here.
I like Kacheongs idea to use the assoc_value structs:
1. This allows it to control it on an association base. No limitation
    here.
2. It can be used with any future notification. It is just adding a
    new constant, not changing a structure which might break ABI =20
compatibility.
3. It is simple.

I think we should add this.
>
> R
>
>
>
>>
>> --=20
>>
>> 						K. Poon.
>> 						[e-mail]
>>
>
> -----
> Randall Stewart
> [e-mail]
>
>
>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D90528C154 for <[e-mail]>; Wed, 25 Feb 2009 03:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 PsfG2XAlNNOp for <[e-mail]>; Wed, 25 Feb 2009 03:26:52 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id A8DFB28C152 for <[e-mail]>; Wed, 25 Feb 2009 03:26:51 -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 n1PBRF1U043328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 06:27:16 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: Randy Stewart <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 25 Feb 2009 06:27:06 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] EXPLICIT_EOR api
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 11:26:53 -0000

Let me reply to myself :-)

Since I had no coffee when I wrote this (never
answer email at 3am when you first wakeup without coffee :-D):


>
>
> Hmm so let me summarize what I think we have agreed to so far
>
> 1) We will add support for using the sctp_assoc_value structure
>   to turn on/off EEOR mode on a per assoc basis.
> 2) If the value of the assoc is 0, then the entire socket (1-2many  
> or 1-1) is
>   set to EEOR mode this includes future and all existing sockets.
>
>


I think the above needs to be reworded.. to be consistent with what
we do in the rest of the api:

1) We will add support for using the sctp_assoc_value structure
    to turn on/off EEOR mode on a per assoc basis.

This is fine ;-)

but 2 should be:

2) if the value of the assoc is 0, then all FUTURE sockets only
    are setup to be EEOR mode. Not existing assoc's..

I realized this AM that we are pretty consistent that when we
do an assoc-id ==0  on some setting then the change only
effects "future" assoc's.

I will reply separately on the sender-dry event since this is a separate
thread I think. Lets keep the two things separate please :-)

R
-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3FE3A6A18 for <[e-mail]>; Wed, 25 Feb 2009 03:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 DTTEMNwhKcN0 for <[e-mail]>; Wed, 25 Feb 2009 03:34:32 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 4552D3A6843 for <[e-mail]>; Wed, 25 Feb 2009 03:34:30 -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 n1PBYuAs043588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 06:34:57 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 06:34:47 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 11:34:33 -0000

On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:

> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>
>>
>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>
>>> Michael T=FCxen wrote:
>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>> ...
>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>> scenario where
>>>>> an application decides to change event subscription of an =20
>>>>> association after
>>>>> it's established?  I can't see a reason right now, but that =20
>>>>> doesn't mean it
>>>>> doesn't exist.
>>>> We do this for the DRY event since we are only interested in it
>>>> during some specific states in DTLS (during renegotiations).
>>>
>>>
>>> If we want to explore this, I'd suggest we retire (just keep
>>> it there for backward compatibility) the sctp_event_subscribe.
>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>> subscribe/unsubscribe each event one by one.
>>>
>>> BTW, I guess it should not cause a problem if the DRY event is
>>> enabled for all associations controlled by one socket all the
>>> time.
>>>
>>
>> Hmm so let me summarize what I think we have agreed to so far
>>
>> 1) We will add support for using the sctp_assoc_value structure
>>  to turn on/off EEOR mode on a per assoc basis.
>> 2) If the value of the assoc is 0, then the entire socket (1-2many =20=

>> or 1-1) is
>>  set to EEOR mode this includes future and all existing sockets.
>>
>>
>> On the events... I am not convinced a per-assoc subscription is
>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>> socket .. you know if you are sending and can turn it off as soon
>> as the dry-event occurs. If you get a dry event on another
>> association, you can pretty easily ignore it. It might be nice
>> to have per-association on/off of some events. But I am mixed
>> on how useful that is.
>>
>> I do agree with Kacheong here though, if we have to go this route we
>> need a new structure.. i.e. one that includes an assoc id.. and then
>> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
>> or the entire socket... vs just changing a single association. I =20
>> would
>> also think we want to make it more extensible and as Kacheong said
>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>> compatibility
>> but move to the new structure for future things..
>>
>> But again, is this really worth it? I am not convinced it is yet..
> There are two points here specific to the DRY event:
>
> 1. Performance: I might be interested only in the events for one
>   particular association, but I get them for all. Of course I
>   can ignore them for all associations I'm not interested in,
>   but this means the kernel is going to generate a lot of =20
> notifications
>   I'm not interested in. This is just waisted cycles and mbufs.
>
> 2. The DRY event is generated when it is enabled and the the =20
> association
>   is dry.  So assume I have N associations (being dry), I'm interested
>   in one. Now I enable it. The kernel has to generate N notifications
>   instantly. This might be a resource problem (on Mac OS X I ran into
>   it), because you need N mbufs at about the same time. There is also
>   no "flow control" for notifications.
>   That is why I implemented this currently only for 1-to-1 style =20
> sockets.
>
> But I think we should be more future proof here.
> I like Kacheongs idea to use the assoc_value structs:
> 1. This allows it to control it on an association base. No limitation
>   here.
> 2. It can be used with any future notification. It is just adding a
>   new constant, not changing a structure which might break ABI =20
> compatibility.
> 3. It is simple.
>
> I think we should add this.


Michael so what you are proposing is that we:

1) Keep the existing SCTP_EVENT's socket call.

2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
    sctp_assoc_value structure. Where the assoc-id is the
    assoc you want the notification on. And the value is the
    Notification id. We would type all current notifications
    with constants e.g. SCTP_DRY_NOTIFICATION

3) I think we would want 0 to be again, future associations
    and non-zero to be specific associations.


Now this would also mean that the existing SCTP_EVENT's would have
a slight change, which I think is ok. It would now be a short cut
equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
the assoc-id set to 0. I.e. it would ONLY effect future assoc's.

This is a subtle difference but one we should document well. I think
its ok, since most folks using the SCTP_EVENT's do not change
things in the middle. They basically open a socket, set the events
they may want... and then never touch it again.

I do agree this would then add a nice extensible mechanism to add
future events as well.

As long as Kacheong and Vlad are ok with this I am too... I can see
it will at least be useful for the sender-dry-event. Not sure about
other ones but you never know.

Kacheong, Vlad, -- thoughts.. if you agree I will start making
changes in BSD and the ID..

R

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663CB3A6997 for <[e-mail]>; Wed, 25 Feb 2009 03:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.367
X-Spam-Level: ***
X-Spam-Status: No, score=3.367 tagged_above=-999 required=5 tests=[AWL=1.329,  BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311,  MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 8BEOTmBLnvHp for <[e-mail]>; Wed, 25 Feb 2009 03:54:24 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 6E4023A699C for <[e-mail]>; Wed, 25 Feb 2009 03:54:23 -0800 (PST)
Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id F06681C0E9633; Wed, 25 Feb 2009 12:54:40 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: Randy Stewart <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 12:54:39 +0100
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 11:54:25 -0000

On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>
>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>
>>>
>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>
>>>> Michael T=FCxen wrote:
>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>> ...
>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>> scenario where
>>>>>> an application decides to change event subscription of an =20
>>>>>> association after
>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>> doesn't mean it
>>>>>> doesn't exist.
>>>>> We do this for the DRY event since we are only interested in it
>>>>> during some specific states in DTLS (during renegotiations).
>>>>
>>>>
>>>> If we want to explore this, I'd suggest we retire (just keep
>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>> subscribe/unsubscribe each event one by one.
>>>>
>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>> enabled for all associations controlled by one socket all the
>>>> time.
>>>>
>>>
>>> Hmm so let me summarize what I think we have agreed to so far
>>>
>>> 1) We will add support for using the sctp_assoc_value structure
>>> to turn on/off EEOR mode on a per assoc basis.
>>> 2) If the value of the assoc is 0, then the entire socket (1-2many =20=

>>> or 1-1) is
>>> set to EEOR mode this includes future and all existing sockets.
>>>
>>>
>>> On the events... I am not convinced a per-assoc subscription is
>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>>> socket .. you know if you are sending and can turn it off as soon
>>> as the dry-event occurs. If you get a dry event on another
>>> association, you can pretty easily ignore it. It might be nice
>>> to have per-association on/off of some events. But I am mixed
>>> on how useful that is.
>>>
>>> I do agree with Kacheong here though, if we have to go this route we
>>> need a new structure.. i.e. one that includes an assoc id.. and then
>>> do the thing that says if the assoc-id=3D=3D0 its to future =
associations
>>> or the entire socket... vs just changing a single association. I =20
>>> would
>>> also think we want to make it more extensible and as Kacheong said
>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>> compatibility
>>> but move to the new structure for future things..
>>>
>>> But again, is this really worth it? I am not convinced it is yet..
>> There are two points here specific to the DRY event:
>>
>> 1. Performance: I might be interested only in the events for one
>>  particular association, but I get them for all. Of course I
>>  can ignore them for all associations I'm not interested in,
>>  but this means the kernel is going to generate a lot of =20
>> notifications
>>  I'm not interested in. This is just waisted cycles and mbufs.
>>
>> 2. The DRY event is generated when it is enabled and the the =20
>> association
>>  is dry.  So assume I have N associations (being dry), I'm interested
>>  in one. Now I enable it. The kernel has to generate N notifications
>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>  it), because you need N mbufs at about the same time. There is also
>>  no "flow control" for notifications.
>>  That is why I implemented this currently only for 1-to-1 style =20
>> sockets.
>>
>> But I think we should be more future proof here.
>> I like Kacheongs idea to use the assoc_value structs:
>> 1. This allows it to control it on an association base. No limitation
>>  here.
>> 2. It can be used with any future notification. It is just adding a
>>  new constant, not changing a structure which might break ABI =20
>> compatibility.
>> 3. It is simple.
>>
>> I think we should add this.
>
>
> Michael so what you are proposing is that we:
>
> 1) Keep the existing SCTP_EVENT's socket call.
The socket option is called SCTP_EVENTS. I suggest to keep it.
>
>
>
> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>   sctp_assoc_value structure. Where the assoc-id is the
>   assoc you want the notification on. And the value is the
>   Notification id. We would type all current notifications
>   with constants e.g. SCTP_DRY_NOTIFICATION
What about SCTP_EVENT (no S, so singular)? This would use
struct sctp_assoc_value.
>
>
> 3) I think we would want 0 to be again, future associations
>   and non-zero to be specific associations.
Correct. And ignore for 1-to-1 style sockets.
>
>
>
> Now this would also mean that the existing SCTP_EVENT's would have
> a slight change, which I think is ok. It would now be a short cut
Why do you want to change that? I would suggest to keep it at it is.
>
> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>
> This is a subtle difference but one we should document well. I think
> its ok, since most folks using the SCTP_EVENT's do not change
> things in the middle. They basically open a socket, set the events
> they may want... and then never touch it again.
>
> I do agree this would then add a nice extensible mechanism to add
> future events as well.
>
> As long as Kacheong and Vlad are ok with this I am too... I can see
> it will at least be useful for the sender-dry-event. Not sure about
> other ones but you never know.
>
> Kacheong, Vlad, -- thoughts.. if you agree I will start making
> changes in BSD and the ID..
>
> R
>
> -----
> Randall Stewart
> [e-mail]
>
>
>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C86B28C14B for <[e-mail]>; Wed, 25 Feb 2009 04:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 RLHXo2IjhQz9 for <[e-mail]>; Wed, 25 Feb 2009 04:02:11 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 39EBF3A6AB7 for <[e-mail]>; Wed, 25 Feb 2009 04:02:09 -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 n1PC2Y6n044686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 07:02:35 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 07:02:24 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 12:02:12 -0000

On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:

> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario where
>>>>>>> an application decides to change event subscription of an =20
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>> particular association, but I get them for all. Of course I
>>> can ignore them for all associations I'm not interested in,
>>> but this means the kernel is going to generate a lot of =20
>>> notifications
>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>> is dry.  So assume I have N associations (being dry), I'm interested
>>> in one. Now I enable it. The kernel has to generate N notifications
>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>> it), because you need N mbufs at about the same time. There is also
>>> no "flow control" for notifications.
>>> That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>> here.
>>> 2. It can be used with any future notification. It is just adding a
>>> new constant, not changing a structure which might break ABI =20
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
>> Michael so what you are proposing is that we:
>>
>> 1) Keep the existing SCTP_EVENT's socket call.
> The socket option is called SCTP_EVENTS. I suggest to keep it.

Opps.. you are right so I did not go look at the header file :-)

>
>>
>>
>>
>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>  sctp_assoc_value structure. Where the assoc-id is the
>>  assoc you want the notification on. And the value is the
>>  Notification id. We would type all current notifications
>>  with constants e.g. SCTP_DRY_NOTIFICATION
> What about SCTP_EVENT (no S, so singular)? This would use
> struct sctp_assoc_value.

Thats fine with me..

>
>>
>>
>> 3) I think we would want 0 to be again, future associations
>>  and non-zero to be specific associations.
> Correct. And ignore for 1-to-1 style sockets.

Not if you are a listener.. A listening 1-on-1 socket would
be setting up for its future "accepted" associations.

>
>>
>>
>>
>> Now this would also mean that the existing SCTP_EVENT's would have
>> a slight change, which I think is ok. It would now be a short cut
> Why do you want to change that? I would suggest to keep it at it is.

I guess we could.. but it will really be the first socket
option that digs through a 1-M socket and grabs each
assoc and applies some settings. Which in my mind kinda makes
it inconsistent.

The current events are set socket wide.. so at an implementation
level we are discussing moving the events onto the actual
"assoc structure" not the "socket level structure". Which in my
mind changes the semantics of the way the thing is manipulated.

Inside the API we have been pretty consistent. If its a over-reaching
socket level thing it of course effects everything when you change
it. However if its something ON an association changes at
the socket level effect future associations vs changes on a specific
assoc...

This concerns me somewhat.. but I guess for compatibility reasons it
would be ok...

But honestly other than this new sender-dry event of yours most everyone
I have ever taught the API too or worked with on it sets up the
SCTP_EVENTS once and only once.. and then never touches it again.

R

>
>>
>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>
>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [e-mail]
>>
>>
>>
>>
>>
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF043A6AA4 for <[e-mail]>; Wed, 25 Feb 2009 05:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.836
X-Spam-Level: **
X-Spam-Status: No, score=2.836 tagged_above=-999 required=5 tests=[AWL=0.798,  BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311,  MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 5RIBVecqkh4R for <[e-mail]>; Wed, 25 Feb 2009 05:31:47 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 50F1F3A67D6 for <[e-mail]>; Wed, 25 Feb 2009 05:31:46 -0800 (PST)
Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id EF8EE1C0E9633; Wed, 25 Feb 2009 14:32:02 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: Randy Stewart <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 14:32:01 +0100
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 13:31:48 -0000

On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:
>
>> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>>
>>>
>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>
>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>
>>>>>
>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>
>>>>>> Michael T=FCxen wrote:
>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>> ...
>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>> scenario where
>>>>>>>> an application decides to change event subscription of an =20
>>>>>>>> association after
>>>>>>>> it's established?  I can't see a reason right now, but that =20
>>>>>>>> doesn't mean it
>>>>>>>> doesn't exist.
>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>
>>>>>>
>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>
>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>> enabled for all associations controlled by one socket all the
>>>>>> time.
>>>>>>
>>>>>
>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>
>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>> (1-2many or 1-1) is
>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>
>>>>>
>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>> many
>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>> as the dry-event occurs. If you get a dry event on another
>>>>> association, you can pretty easily ignore it. It might be nice
>>>>> to have per-association on/off of some events. But I am mixed
>>>>> on how useful that is.
>>>>>
>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>> route we
>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>> then
>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>> associations
>>>>> or the entire socket... vs just changing a single association. I =20=

>>>>> would
>>>>> also think we want to make it more extensible and as Kacheong said
>>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>>> compatibility
>>>>> but move to the new structure for future things..
>>>>>
>>>>> But again, is this really worth it? I am not convinced it is yet..
>>>> There are two points here specific to the DRY event:
>>>>
>>>> 1. Performance: I might be interested only in the events for one
>>>> particular association, but I get them for all. Of course I
>>>> can ignore them for all associations I'm not interested in,
>>>> but this means the kernel is going to generate a lot of =20
>>>> notifications
>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>
>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>> association
>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>> interested
>>>> in one. Now I enable it. The kernel has to generate N notifications
>>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>>> it), because you need N mbufs at about the same time. There is also
>>>> no "flow control" for notifications.
>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>> sockets.
>>>>
>>>> But I think we should be more future proof here.
>>>> I like Kacheongs idea to use the assoc_value structs:
>>>> 1. This allows it to control it on an association base. No =20
>>>> limitation
>>>> here.
>>>> 2. It can be used with any future notification. It is just adding a
>>>> new constant, not changing a structure which might break ABI =20
>>>> compatibility.
>>>> 3. It is simple.
>>>>
>>>> I think we should add this.
>>>
>>>
>>> Michael so what you are proposing is that we:
>>>
>>> 1) Keep the existing SCTP_EVENT's socket call.
>> The socket option is called SCTP_EVENTS. I suggest to keep it.
>
> Opps.. you are right so I did not go look at the header file :-)
>
>>
>>>
>>>
>>>
>>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>> sctp_assoc_value structure. Where the assoc-id is the
>>> assoc you want the notification on. And the value is the
>>> Notification id. We would type all current notifications
>>> with constants e.g. SCTP_DRY_NOTIFICATION
>> What about SCTP_EVENT (no S, so singular)? This would use
>> struct sctp_assoc_value.
>
> Thats fine with me..
>
>>
>>>
>>>
>>> 3) I think we would want 0 to be again, future associations
>>> and non-zero to be specific associations.
>> Correct. And ignore for 1-to-1 style sockets.
>
> Not if you are a listener.. A listening 1-on-1 socket would
> be setting up for its future "accepted" associations.
I meant: Ignore the association ID on the 1-to-1 style sockets.
On a listener, it is for future association, on a non listener,
it is for the specific one belonging to the socket.
>
>
>>
>>>
>>>
>>>
>>> Now this would also mean that the existing SCTP_EVENT's would have
>>> a slight change, which I think is ok. It would now be a short cut
>> Why do you want to change that? I would suggest to keep it at it is.
>
> I guess we could.. but it will really be the first socket
> option that digs through a 1-M socket and grabs each
> assoc and applies some settings. Which in my mind kinda makes
> it inconsistent.
>
> The current events are set socket wide.. so at an implementation
> level we are discussing moving the events onto the actual
> "assoc structure" not the "socket level structure". Which in my
> mind changes the semantics of the way the thing is manipulated.
I see what you mean... However, this means that some applications
might break since we are changing the semantics. But I think
it is worth the price.

Anyway: I think the best would be anyway to put a note in the
text that people should use the new API (SCTP_EVENT) instead
of the old one (SCTP_EVENTS). This way they can better use
additional features (Stream Reset comes to my mind...)
>
>
> Inside the API we have been pretty consistent. If its a over-reaching
> socket level thing it of course effects everything when you change
> it. However if its something ON an association changes at
> the socket level effect future associations vs changes on a specific
> assoc...
>
> This concerns me somewhat.. but I guess for compatibility reasons it
> would be ok...
>
> But honestly other than this new sender-dry event of yours most =20
> everyone
> I have ever taught the API too or worked with on it sets up the
> SCTP_EVENTS once and only once.. and then never touches it again.
I vote for changing the semantic!
>
>
> R
>
>>
>>>
>>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>>
>>> This is a subtle difference but one we should document well. I think
>>> its ok, since most folks using the SCTP_EVENT's do not change
>>> things in the middle. They basically open a socket, set the events
>>> they may want... and then never touch it again.
>>>
>>> I do agree this would then add a nice extensible mechanism to add
>>> future events as well.
>>>
>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>> it will at least be useful for the sender-dry-event. Not sure about
>>> other ones but you never know.
>>>
>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>> changes in BSD and the ID..
>>>
>>> R
>>>
>>> -----
>>> Randall Stewart
>>> [e-mail]
>>>
>>>
>>>
>>>
>>>
>>
>
> -----
> Randall Stewart
> [e-mail]
>
>
>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596603A686D for <[e-mail]>; Wed, 25 Feb 2009 06:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 sI40CDSY51Ih for <[e-mail]>; Wed, 25 Feb 2009 06:42:46 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 4B1C93A6841 for <[e-mail]>; Wed, 25 Feb 2009 06:42:44 -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 n1PEh7M7051088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 09:43:07 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 09:42:57 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 14:42:47 -0000

I will go with whatever one else wants... I really
don't have much of an opinion.. the SCTP_EVENT is fine
and to the semantic changes... I will listen to
whatever Kacheong says on this.. since of all the
co-authors I think he is closest to being the
semantic police :-)

R
On Feb 25, 2009, at 8:32 AM, Michael T=FCxen wrote:

>
> On Feb 25, 2009, at 1:02 PM, Randy Stewart wrote:
>
>>
>> On Feb 25, 2009, at 6:54 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 12:34 PM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>>
>>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>>
>>>>>>
>>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>>
>>>>>>> Michael T=FCxen wrote:
>>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>>> ...
>>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>>> scenario where
>>>>>>>>> an application decides to change event subscription of an =20
>>>>>>>>> association after
>>>>>>>>> it's established?  I can't see a reason right now, but that =20=

>>>>>>>>> doesn't mean it
>>>>>>>>> doesn't exist.
>>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>>
>>>>>>>
>>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>>
>>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>>> enabled for all associations controlled by one socket all the
>>>>>>> time.
>>>>>>>
>>>>>>
>>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>>
>>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>>> (1-2many or 1-1) is
>>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>>
>>>>>>
>>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>>> many
>>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>>> as the dry-event occurs. If you get a dry event on another
>>>>>> association, you can pretty easily ignore it. It might be nice
>>>>>> to have per-association on/off of some events. But I am mixed
>>>>>> on how useful that is.
>>>>>>
>>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>>> route we
>>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>>> then
>>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>>> associations
>>>>>> or the entire socket... vs just changing a single association. =20=

>>>>>> I would
>>>>>> also think we want to make it more extensible and as Kacheong =20
>>>>>> said
>>>>>> just retire the old SCTP_EVENTS... i.e. support for backward =20
>>>>>> compatibility
>>>>>> but move to the new structure for future things..
>>>>>>
>>>>>> But again, is this really worth it? I am not convinced it is =20
>>>>>> yet..
>>>>> There are two points here specific to the DRY event:
>>>>>
>>>>> 1. Performance: I might be interested only in the events for one
>>>>> particular association, but I get them for all. Of course I
>>>>> can ignore them for all associations I'm not interested in,
>>>>> but this means the kernel is going to generate a lot of =20
>>>>> notifications
>>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>>
>>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>>> association
>>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>>> interested
>>>>> in one. Now I enable it. The kernel has to generate N =20
>>>>> notifications
>>>>> instantly. This might be a resource problem (on Mac OS X I ran =20
>>>>> into
>>>>> it), because you need N mbufs at about the same time. There is =20
>>>>> also
>>>>> no "flow control" for notifications.
>>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>>> sockets.
>>>>>
>>>>> But I think we should be more future proof here.
>>>>> I like Kacheongs idea to use the assoc_value structs:
>>>>> 1. This allows it to control it on an association base. No =20
>>>>> limitation
>>>>> here.
>>>>> 2. It can be used with any future notification. It is just =20
>>>>> adding a
>>>>> new constant, not changing a structure which might break ABI =20
>>>>> compatibility.
>>>>> 3. It is simple.
>>>>>
>>>>> I think we should add this.
>>>>
>>>>
>>>> Michael so what you are proposing is that we:
>>>>
>>>> 1) Keep the existing SCTP_EVENT's socket call.
>>> The socket option is called SCTP_EVENTS. I suggest to keep it.
>>
>> Opps.. you are right so I did not go look at the header file :-)
>>
>>>
>>>>
>>>>
>>>>
>>>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>>> sctp_assoc_value structure. Where the assoc-id is the
>>>> assoc you want the notification on. And the value is the
>>>> Notification id. We would type all current notifications
>>>> with constants e.g. SCTP_DRY_NOTIFICATION
>>> What about SCTP_EVENT (no S, so singular)? This would use
>>> struct sctp_assoc_value.
>>
>> Thats fine with me..
>>
>>>
>>>>
>>>>
>>>> 3) I think we would want 0 to be again, future associations
>>>> and non-zero to be specific associations.
>>> Correct. And ignore for 1-to-1 style sockets.
>>
>> Not if you are a listener.. A listening 1-on-1 socket would
>> be setting up for its future "accepted" associations.
> I meant: Ignore the association ID on the 1-to-1 style sockets.
> On a listener, it is for future association, on a non listener,
> it is for the specific one belonging to the socket.
>>
>>
>>>
>>>>
>>>>
>>>>
>>>> Now this would also mean that the existing SCTP_EVENT's would have
>>>> a slight change, which I think is ok. It would now be a short cut
>>> Why do you want to change that? I would suggest to keep it at it is.
>>
>> I guess we could.. but it will really be the first socket
>> option that digs through a 1-M socket and grabs each
>> assoc and applies some settings. Which in my mind kinda makes
>> it inconsistent.
>>
>> The current events are set socket wide.. so at an implementation
>> level we are discussing moving the events onto the actual
>> "assoc structure" not the "socket level structure". Which in my
>> mind changes the semantics of the way the thing is manipulated.
> I see what you mean... However, this means that some applications
> might break since we are changing the semantics. But I think
> it is worth the price.
>
> Anyway: I think the best would be anyway to put a note in the
> text that people should use the new API (SCTP_EVENT) instead
> of the old one (SCTP_EVENTS). This way they can better use
> additional features (Stream Reset comes to my mind...)
>>
>>
>> Inside the API we have been pretty consistent. If its a over-reaching
>> socket level thing it of course effects everything when you change
>> it. However if its something ON an association changes at
>> the socket level effect future associations vs changes on a specific
>> assoc...
>>
>> This concerns me somewhat.. but I guess for compatibility reasons it
>> would be ok...
>>
>> But honestly other than this new sender-dry event of yours most =20
>> everyone
>> I have ever taught the API too or worked with on it sets up the
>> SCTP_EVENTS once and only once.. and then never touches it again.
> I vote for changing the semantic!
>>
>>
>> R
>>
>>>
>>>>
>>>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>>>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>>>
>>>> This is a subtle difference but one we should document well. I =20
>>>> think
>>>> its ok, since most folks using the SCTP_EVENT's do not change
>>>> things in the middle. They basically open a socket, set the events
>>>> they may want... and then never touch it again.
>>>>
>>>> I do agree this would then add a nice extensible mechanism to add
>>>> future events as well.
>>>>
>>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>>> it will at least be useful for the sender-dry-event. Not sure about
>>>> other ones but you never know.
>>>>
>>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>>> changes in BSD and the ID..
>>>>
>>>> R
>>>>
>>>> -----
>>>> Randall Stewart
>>>> [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> -----
>> Randall Stewart
>> [e-mail]
>>
>>
>>
>>
>>
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B343A6ACA for <[e-mail]>; Wed, 25 Feb 2009 06:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.22
X-Spam-Level: 
X-Spam-Status: No, score=-105.22 tagged_above=-999 required=5 tests=[AWL=1.379, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 asOb6SQ+HkL2 for <[e-mail]>; Wed, 25 Feb 2009 06:42:47 -0800 (PST)
Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id C99B03A6841 for <[e-mail]>; Wed, 25 Feb 2009 06:42:47 -0800 (PST)
Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 94408384B1; Wed, 25 Feb 2009 14:43:07 +0000 (UTC)
Received: from [192.168.98.100] (pool-70-20-48-153.man.east.myfairpoint.net [70.20.48.153]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id B8B1610005; Wed, 25 Feb 2009 14:43:06 +0000 (UTC)
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2009 09:43:05 -0500
From: Vlad Yasevich <[e-mail]>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Randy Stewart <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 14:42:49 -0000

Randy Stewart wrote:
> 
> On Feb 25, 2009, at 4:35 AM, Michael Tüxen wrote:
> 
>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>
>>>
>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>
>>>> Michael Tüxen wrote:
>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>> ...
>>>>>> Hmm..  That's an interesting question.  Is it a possible scenario
>>>>>> where
>>>>>> an application decides to change event subscription of an
>>>>>> association after
>>>>>> it's established?  I can't see a reason right now, but that
>>>>>> doesn't mean it
>>>>>> doesn't exist.
>>>>> We do this for the DRY event since we are only interested in it
>>>>> during some specific states in DTLS (during renegotiations).
>>>>
>>>>
>>>> If we want to explore this, I'd suggest we retire (just keep
>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>> subscribe/unsubscribe each event one by one.
>>>>
>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>> enabled for all associations controlled by one socket all the
>>>> time.
>>>>
>>>
>>> Hmm so let me summarize what I think we have agreed to so far
>>>
>>> 1) We will add support for using the sctp_assoc_value structure
>>>  to turn on/off EEOR mode on a per assoc basis.
>>> 2) If the value of the assoc is 0, then the entire socket (1-2many or
>>> 1-1) is
>>>  set to EEOR mode this includes future and all existing sockets.
>>>
>>>
>>> On the events... I am not convinced a per-assoc subscription is
>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-many
>>> socket .. you know if you are sending and can turn it off as soon
>>> as the dry-event occurs. If you get a dry event on another
>>> association, you can pretty easily ignore it. It might be nice
>>> to have per-association on/off of some events. But I am mixed
>>> on how useful that is.
>>>
>>> I do agree with Kacheong here though, if we have to go this route we
>>> need a new structure.. i.e. one that includes an assoc id.. and then
>>> do the thing that says if the assoc-id==0 its to future associations
>>> or the entire socket... vs just changing a single association. I would
>>> also think we want to make it more extensible and as Kacheong said
>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>> compatibility
>>> but move to the new structure for future things..
>>>
>>> But again, is this really worth it? I am not convinced it is yet..
>> There are two points here specific to the DRY event:
>>
>> 1. Performance: I might be interested only in the events for one
>>   particular association, but I get them for all. Of course I
>>   can ignore them for all associations I'm not interested in,
>>   but this means the kernel is going to generate a lot of notifications
>>   I'm not interested in. This is just waisted cycles and mbufs.
>>
>> 2. The DRY event is generated when it is enabled and the the association
>>   is dry.  So assume I have N associations (being dry), I'm interested
>>   in one. Now I enable it. The kernel has to generate N notifications
>>   instantly. This might be a resource problem (on Mac OS X I ran into
>>   it), because you need N mbufs at about the same time. There is also
>>   no "flow control" for notifications.
>>   That is why I implemented this currently only for 1-to-1 style sockets.
>>
>> But I think we should be more future proof here.
>> I like Kacheongs idea to use the assoc_value structs:
>> 1. This allows it to control it on an association base. No limitation
>>   here.
>> 2. It can be used with any future notification. It is just adding a
>>   new constant, not changing a structure which might break ABI
>> compatibility.
>> 3. It is simple.
>>
>> I think we should add this.
> 
> 
> Michael so what you are proposing is that we:
> 
> 1) Keep the existing SCTP_EVENT's socket call.
> 
> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>    sctp_assoc_value structure. Where the assoc-id is the
>    assoc you want the notification on. And the value is the
>    Notification id. We would type all current notifications
>    with constants e.g. SCTP_DRY_NOTIFICATION

So, this option could only be used to turn something on, not turn
it off?  Seems one-sided. :)

> 
> 3) I think we would want 0 to be again, future associations
>    and non-zero to be specific associations.
> 
> 
> Now this would also mean that the existing SCTP_EVENT's would have
> a slight change, which I think is ok. It would now be a short cut
> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
> 
> This is a subtle difference but one we should document well. I think
> its ok, since most folks using the SCTP_EVENT's do not change
> things in the middle. They basically open a socket, set the events
> they may want... and then never touch it again.
> 
> I do agree this would then add a nice extensible mechanism to add
> future events as well.
> 

Yes, this is something that would be good to have.  It also gives
applications a very fine control over what they can request and that's
generally a good thing.

-vlad

> As long as Kacheong and Vlad are ok with this I am too... I can see
> it will at least be useful for the sender-dry-event. Not sure about
> other ones but you never know.
> 
> Kacheong, Vlad, -- thoughts.. if you agree I will start making
> changes in BSD and the ID..
> 
> R
> 
> -----
> Randall Stewart
> [e-mail]
> 
> 
> 
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0EB3A6963 for <[e-mail]>; Wed, 25 Feb 2009 07:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599]
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 tqiFzc78ffqA for <[e-mail]>; Wed, 25 Feb 2009 07:09:23 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by core3.amsl.com (Postfix) with ESMTP id 780653A68E4 for <[e-mail]>; Wed, 25 Feb 2009 07:09:22 -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 n1PF9mTe052095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Feb 2009 10:09:48 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Randy Stewart <[e-mail]>
To: Vlad Yasevich <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 10:09:38 -0500
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 15:09:24 -0000

On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote:

> Randy Stewart wrote:
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario
>>>>>>> where
>>>>>>> an application decides to change event subscription of an
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or
>>>> 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>>  particular association, but I get them for all. Of course I
>>>  can ignore them for all associations I'm not interested in,
>>>  but this means the kernel is going to generate a lot of =20
>>> notifications
>>>  I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>>  is dry.  So assume I have N associations (being dry), I'm =20
>>> interested
>>>  in one. Now I enable it. The kernel has to generate N notifications
>>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>>  it), because you need N mbufs at about the same time. There is also
>>>  no "flow control" for notifications.
>>>  That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>>  here.
>>> 2. It can be used with any future notification. It is just adding a
>>>  new constant, not changing a structure which might break ABI
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
>> Michael so what you are proposing is that we:
>>
>> 1) Keep the existing SCTP_EVENT's socket call.
>>
>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>   sctp_assoc_value structure. Where the assoc-id is the
>>   assoc you want the notification on. And the value is the
>>   Notification id. We would type all current notifications
>>   with constants e.g. SCTP_DRY_NOTIFICATION
>
> So, this option could only be used to turn something on, not turn
> it off?  Seems one-sided. :)


Hmm.. yeah you are right here. You would have to define two contants
I guess..

SCTP_DRY_NOTIFICATION_ON
SCTP_DRY_NOTIFICATION_OFF

Since its a 32 bit number space in the value it would probably be =20
extensible
enough (2 billion possibilities) :-)

>
>
>>
>> 3) I think we would want 0 to be again, future associations
>>   and non-zero to be specific associations.
>>
>>
>> Now this would also mean that the existing SCTP_EVENT's would have
>> a slight change, which I think is ok. It would now be a short cut
>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>
>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>
> Yes, this is something that would be good to have.  It also gives
> applications a very fine control over what they can request and that's
> generally a good thing.

True

R
>
>
> -vlad
>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [e-mail]
>>
>>
>>
>>
>

-----
Randall Stewart
[e-mail]






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55FF3A6870 for <[e-mail]>; Wed, 25 Feb 2009 07:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.697
X-Spam-Level: ****
X-Spam-Status: No, score=4.697 tagged_above=-999 required=5 tests=[AWL=-1.329,  BAYES_00=-2.599, FRT_STOCK2=3.988, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 gFUBBm0ZZYtE for <[e-mail]>; Wed, 25 Feb 2009 07:18:45 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9114C3A686D for <[e-mail]>; Wed, 25 Feb 2009 07:18:44 -0800 (PST)
Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 723481C0E9633; Wed, 25 Feb 2009 16:19:02 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: Vlad Yasevich <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 16:19:01 +0100
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>, Randy Stewart <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 15:18:46 -0000

On Feb 25, 2009, at 3:43 PM, Vlad Yasevich wrote:

> Randy Stewart wrote:
>>
>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>
>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>
>>>>
>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>
>>>>> Michael T=FCxen wrote:
>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>> ...
>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>> scenario
>>>>>>> where
>>>>>>> an application decides to change event subscription of an
>>>>>>> association after
>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>> doesn't mean it
>>>>>>> doesn't exist.
>>>>>> We do this for the DRY event since we are only interested in it
>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>
>>>>>
>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>> subscribe/unsubscribe each event one by one.
>>>>>
>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>> enabled for all associations controlled by one socket all the
>>>>> time.
>>>>>
>>>>
>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>
>>>> 1) We will add support for using the sctp_assoc_value structure
>>>> to turn on/off EEOR mode on a per assoc basis.
>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>> (1-2many or
>>>> 1-1) is
>>>> set to EEOR mode this includes future and all existing sockets.
>>>>
>>>>
>>>> On the events... I am not convinced a per-assoc subscription is
>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20
>>>> many
>>>> socket .. you know if you are sending and can turn it off as soon
>>>> as the dry-event occurs. If you get a dry event on another
>>>> association, you can pretty easily ignore it. It might be nice
>>>> to have per-association on/off of some events. But I am mixed
>>>> on how useful that is.
>>>>
>>>> I do agree with Kacheong here though, if we have to go this route =20=

>>>> we
>>>> need a new structure.. i.e. one that includes an assoc id.. and =20
>>>> then
>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>> associations
>>>> or the entire socket... vs just changing a single association. I =20=

>>>> would
>>>> also think we want to make it more extensible and as Kacheong said
>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>> compatibility
>>>> but move to the new structure for future things..
>>>>
>>>> But again, is this really worth it? I am not convinced it is yet..
>>> There are two points here specific to the DRY event:
>>>
>>> 1. Performance: I might be interested only in the events for one
>>>  particular association, but I get them for all. Of course I
>>>  can ignore them for all associations I'm not interested in,
>>>  but this means the kernel is going to generate a lot of =20
>>> notifications
>>>  I'm not interested in. This is just waisted cycles and mbufs.
>>>
>>> 2. The DRY event is generated when it is enabled and the the =20
>>> association
>>>  is dry.  So assume I have N associations (being dry), I'm =20
>>> interested
>>>  in one. Now I enable it. The kernel has to generate N notifications
>>>  instantly. This might be a resource problem (on Mac OS X I ran into
>>>  it), because you need N mbufs at about the same time. There is also
>>>  no "flow control" for notifications.
>>>  That is why I implemented this currently only for 1-to-1 style =20
>>> sockets.
>>>
>>> But I think we should be more future proof here.
>>> I like Kacheongs idea to use the assoc_value structs:
>>> 1. This allows it to control it on an association base. No =20
>>> limitation
>>>  here.
>>> 2. It can be used with any future notification. It is just adding a
>>>  new constant, not changing a structure which might break ABI
>>> compatibility.
>>> 3. It is simple.
>>>
>>> I think we should add this.
>>
>>
>> Michael so what you are proposing is that we:
>>
>> 1) Keep the existing SCTP_EVENT's socket call.
>>
>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>   sctp_assoc_value structure. Where the assoc-id is the
>>   assoc you want the notification on. And the value is the
>>   Notification id. We would type all current notifications
>>   with constants e.g. SCTP_DRY_NOTIFICATION
>
> So, this option could only be used to turn something on, not turn
> it off?  Seems one-sided. :)
Good point.
So I think we need something like
struct sctp_event {
	sctp_assoc_t assoc_id;
	uint32_t event;
	uint8_t enable;
}
Using enable!=3D0, you can enable it, using enable=3D0, you can disable =
it =20
when
you use setsockopt().

For getsockopt(), you provie the assoc_id and the event and get back =20
whether it
is enabled or not.
>
>
>>
>> 3) I think we would want 0 to be again, future associations
>>   and non-zero to be specific associations.
>>
>>
>> Now this would also mean that the existing SCTP_EVENT's would have
>> a slight change, which I think is ok. It would now be a short cut
>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>
>> This is a subtle difference but one we should document well. I think
>> its ok, since most folks using the SCTP_EVENT's do not change
>> things in the middle. They basically open a socket, set the events
>> they may want... and then never touch it again.
>>
>> I do agree this would then add a nice extensible mechanism to add
>> future events as well.
>>
>
> Yes, this is something that would be good to have.  It also gives
> applications a very fine control over what they can request and that's
> generally a good thing.
>
> -vlad
>
>> As long as Kacheong and Vlad are ok with this I am too... I can see
>> it will at least be useful for the sender-dry-event. Not sure about
>> other ones but you never know.
>>
>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>> changes in BSD and the ID..
>>
>> R
>>
>> -----
>> Randall Stewart
>> [e-mail]
>>
>>
>>
>>
>
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CECA3A694F for <[e-mail]>; Wed, 25 Feb 2009 07:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.893
X-Spam-Level: **
X-Spam-Status: No, score=2.893 tagged_above=-999 required=5 tests=[AWL=0.855,  BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311,  MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 pjnGlLU-I-qQ for <[e-mail]>; Wed, 25 Feb 2009 07:19:41 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id B25573A6866 for <[e-mail]>; Wed, 25 Feb 2009 07:19:40 -0800 (PST)
Received: from [192.168.1.193] (p508FDC70.dip.t-dialin.net [80.143.220.112]) by mail-n.franken.de (Postfix) with ESMTP id 8C6371C0E9633; Wed, 25 Feb 2009 16:19:58 +0100 (CET)
Message-Id: <[e-mail]>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <[e-mail]>
To: Randy Stewart <[e-mail]>
In-Reply-To: <[e-mail]>
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: Wed, 25 Feb 2009 16:19:56 +0100
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: Vlad Yasevich <[e-mail]>, Kacheong Poon <[e-mail]>, tsvwg <[e-mail]>
Subject: Re: [Tsvwg] Event Notifications
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 15:19:42 -0000

On Feb 25, 2009, at 4:09 PM, Randy Stewart wrote:

>
> On Feb 25, 2009, at 9:43 AM, Vlad Yasevich wrote:
>
>> Randy Stewart wrote:
>>>
>>> On Feb 25, 2009, at 4:35 AM, Michael T=FCxen wrote:
>>>
>>>> On Feb 25, 2009, at 9:32 AM, Randy Stewart wrote:
>>>>
>>>>>
>>>>> On Feb 24, 2009, at 10:46 PM, Kacheong Poon wrote:
>>>>>
>>>>>> Michael T=FCxen wrote:
>>>>>>> On Feb 24, 2009, at 7:29 PM, Vlad Yasevich wrote:
>>>>>> ...
>>>>>>>> Hmm..  That's an interesting question.  Is it a possible =20
>>>>>>>> scenario
>>>>>>>> where
>>>>>>>> an application decides to change event subscription of an
>>>>>>>> association after
>>>>>>>> it's established?  I can't see a reason right now, but that
>>>>>>>> doesn't mean it
>>>>>>>> doesn't exist.
>>>>>>> We do this for the DRY event since we are only interested in it
>>>>>>> during some specific states in DTLS (during renegotiations).
>>>>>>
>>>>>>
>>>>>> If we want to explore this, I'd suggest we retire (just keep
>>>>>> it there for backward compatibility) the sctp_event_subscribe.
>>>>>> It is not extensible.  Just use sctp_assoc_value.  An app can
>>>>>> subscribe/unsubscribe each event one by one.
>>>>>>
>>>>>> BTW, I guess it should not cause a problem if the DRY event is
>>>>>> enabled for all associations controlled by one socket all the
>>>>>> time.
>>>>>>
>>>>>
>>>>> Hmm so let me summarize what I think we have agreed to so far
>>>>>
>>>>> 1) We will add support for using the sctp_assoc_value structure
>>>>> to turn on/off EEOR mode on a per assoc basis.
>>>>> 2) If the value of the assoc is 0, then the entire socket =20
>>>>> (1-2many or
>>>>> 1-1) is
>>>>> set to EEOR mode this includes future and all existing sockets.
>>>>>
>>>>>
>>>>> On the events... I am not convinced a per-assoc subscription is
>>>>> needed. Going to Michael's sender-dry for DTLS.. even on a 1-to-=20=

>>>>> many
>>>>> socket .. you know if you are sending and can turn it off as soon
>>>>> as the dry-event occurs. If you get a dry event on another
>>>>> association, you can pretty easily ignore it. It might be nice
>>>>> to have per-association on/off of some events. But I am mixed
>>>>> on how useful that is.
>>>>>
>>>>> I do agree with Kacheong here though, if we have to go this =20
>>>>> route we
>>>>> need a new structure.. i.e. one that includes an assoc id.. and =20=

>>>>> then
>>>>> do the thing that says if the assoc-id=3D=3D0 its to future =20
>>>>> associations
>>>>> or the entire socket... vs just changing a single association. I =20=

>>>>> would
>>>>> also think we want to make it more extensible and as Kacheong said
>>>>> just retire the old SCTP_EVENTS... i.e. support for backward
>>>>> compatibility
>>>>> but move to the new structure for future things..
>>>>>
>>>>> But again, is this really worth it? I am not convinced it is yet..
>>>> There are two points here specific to the DRY event:
>>>>
>>>> 1. Performance: I might be interested only in the events for one
>>>> particular association, but I get them for all. Of course I
>>>> can ignore them for all associations I'm not interested in,
>>>> but this means the kernel is going to generate a lot of =20
>>>> notifications
>>>> I'm not interested in. This is just waisted cycles and mbufs.
>>>>
>>>> 2. The DRY event is generated when it is enabled and the the =20
>>>> association
>>>> is dry.  So assume I have N associations (being dry), I'm =20
>>>> interested
>>>> in one. Now I enable it. The kernel has to generate N notifications
>>>> instantly. This might be a resource problem (on Mac OS X I ran into
>>>> it), because you need N mbufs at about the same time. There is also
>>>> no "flow control" for notifications.
>>>> That is why I implemented this currently only for 1-to-1 style =20
>>>> sockets.
>>>>
>>>> But I think we should be more future proof here.
>>>> I like Kacheongs idea to use the assoc_value structs:
>>>> 1. This allows it to control it on an association base. No =20
>>>> limitation
>>>> here.
>>>> 2. It can be used with any future notification. It is just adding a
>>>> new constant, not changing a structure which might break ABI
>>>> compatibility.
>>>> 3. It is simple.
>>>>
>>>> I think we should add this.
>>>
>>>
>>> Michael so what you are proposing is that we:
>>>
>>> 1) Keep the existing SCTP_EVENT's socket call.
>>>
>>> 2) Add a new SCTP_SPECIFIC_EVENT socket call which takes a
>>>  sctp_assoc_value structure. Where the assoc-id is the
>>>  assoc you want the notification on. And the value is the
>>>  Notification id. We would type all current notifications
>>>  with constants e.g. SCTP_DRY_NOTIFICATION
>>
>> So, this option could only be used to turn something on, not turn
>> it off?  Seems one-sided. :)
>
>
> Hmm.. yeah you are right here. You would have to define two contants
> I guess..
>
> SCTP_DRY_NOTIFICATION_ON
> SCTP_DRY_NOTIFICATION_OFF
This does not help for getsockopt()... Se my suggestion in my previous =20=

mail.
>
>
> Since its a 32 bit number space in the value it would probably be =20
> extensible
> enough (2 billion possibilities) :-)
>
>>
>>
>>>
>>> 3) I think we would want 0 to be again, future associations
>>>  and non-zero to be specific associations.
>>>
>>>
>>> Now this would also mean that the existing SCTP_EVENT's would have
>>> a slight change, which I think is ok. It would now be a short cut
>>> equivalent to call 9 or so individual SCTP_SPECIFIC_EVENT with
>>> the assoc-id set to 0. I.e. it would ONLY effect future assoc's.
>>>
>>> This is a subtle difference but one we should document well. I think
>>> its ok, since most folks using the SCTP_EVENT's do not change
>>> things in the middle. They basically open a socket, set the events
>>> they may want... and then never touch it again.
>>>
>>> I do agree this would then add a nice extensible mechanism to add
>>> future events as well.
>>>
>>
>> Yes, this is something that would be good to have.  It also gives
>> applications a very fine control over what they can request and =20
>> that's
>> generally a good thing.
>
> True
>
> R
>>
>>
>> -vlad
>>
>>> As long as Kacheong and Vlad are ok with this I am too... I can see
>>> it will at least be useful for the sender-dry-event. Not sure about
>>> other ones but you never know.
>>>
>>> Kacheong, Vlad, -- thoughts.. if you agree I will start making
>>> changes in BSD and the ID..
>>>
>>> R
>>>
>>> -----
>>> Randall Stewart
>>> [e-mail]
>>>
>>>
>>>
>>>
>>
>
> -----
> Randall Stewart
> [e-mail]
>
>
>
>
>