From tsvwg-bounces@ietf.org Sun Apr 01 08:07:54 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXypQ-0001TJ-IG; Sun, 01 Apr 2007 08:06:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXypP-0001TB-Ou
	for tsvwg@ietf.org; Sun, 01 Apr 2007 08:06:35 -0400
Received: from [2001:240:585:2:203:6dff:fe1a:4ddc] (helo=lakerest.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXypI-00088z-Tg
	for tsvwg@ietf.org; Sun, 01 Apr 2007 08:06:35 -0400
Received: from [10.1.1.11] (ibmlap [10.1.1.11])
	by lakerest.net (8.13.8/8.13.8) with ESMTP id l31C67eL010724;
	Sun, 1 Apr 2007 08:06:08 -0400 (EDT)
	(envelope-from randall@lakerest.net)
Message-ID: <460FA0E2.9080309@lakerest.net>
Date: Sun, 01 Apr 2007 08:09:06 -0400
From: Randall Stewart <randall@lakerest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: "Sirigiri, Anil Kumar Reddy (STSD)" <sakreddy@hp.com>
Subject: Re: [Tsvwg] Socket API draft
References: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>
In-Reply-To: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Sirigiri, Anil Kumar Reddy (STSD) wrote:
> Hi,
> 
> Can someone please clarify my following doubts about socket API draft:
> 
> 1/ Should there be a bind() prior to sctp_bindx() ? -- I see it
> mentioned in one of tsvwg's mails, in the past, but couldn't find an
> answer.

In theory you should be able to use sctp_bindx instead of bind().

> 
> 2/ What is the use of sctp_opt_info() to have assoc_id as the parameter
> ? I see that all sctp_opt_info() options are having the assoc_id in the
> option argument structures. Though, there is no harm in having it, I
> just have this question out of curiosity to know the reason behind it.

sctp_opt_info() was created for O/S's that cannot pass information
in on a getsockopt() call. You want to pass info in when you are
explicitly getting information on an association. In BSD land
either sctp_opt_info or getsockopt() will work.. in fact sctp_opt_info
just calls a getsockopt()... since BSD allows the passing of
information in to the getsockopt call.

Other o/s's .. for example solaris .. use a streams based stack
which is pretty strict on not allowing data coming in to a
getsockopt call.. at least thats what I have been told.

Hope that helps..

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)




From tsvwg-bounces@ietf.org Sun Apr 01 09:12:45 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HXzqD-0003CW-LG; Sun, 01 Apr 2007 09:11:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzqC-00035t-3L
	for tsvwg@ietf.org; Sun, 01 Apr 2007 09:11:28 -0400
Received: from gw.openss7.com ([142.179.199.224])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzqA-0004P4-GD
	for tsvwg@ietf.org; Sun, 01 Apr 2007 09:11:28 -0400
Received: from ns.pigworks.openss7.net
	(IDENT:2/wmpWOvE4ESD788o5fItY77eoEnaByb@ns1.evil.openss7.net
	[192.168.9.1])
	by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l31DBKs06616;
	Sun, 1 Apr 2007 07:11:20 -0600
Received: (from brian@localhost)
	by ns.pigworks.openss7.net (8.11.6/8.11.6) id l31DBJt24267;
	Sun, 1 Apr 2007 07:11:19 -0600
Date: Sun, 1 Apr 2007 07:11:19 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Randall Stewart <randall@lakerest.net>
Subject: Re: [Tsvwg] Socket API draft
Message-ID: <20070401071119.A24116@openss7.org>
Mail-Followup-To: Randall Stewart <randall@lakerest.net>,
	"Sirigiri, Anil Kumar Reddy (STSD)" <sakreddy@hp.com>,
	tsvwg@ietf.org
References: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>
	<460FA0E2.9080309@lakerest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <460FA0E2.9080309@lakerest.net>;
	from randall@lakerest.net on Sun, Apr 01, 2007 at 08:09:06AM -0400
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall,

Randall Stewart wrote:                        (Sun, 01 Apr 2007 08:09:06)
> 
> sctp_opt_info() was created for O/S's that cannot pass information
> in on a getsockopt() call. You want to pass info in when you are
> explicitly getting information on an association. In BSD land
> either sctp_opt_info or getsockopt() will work.. in fact sctp_opt_info
> just calls a getsockopt()... since BSD allows the passing of
> information in to the getsockopt call.
> 
> Other o/s's .. for example solaris .. use a streams based stack
> which is pretty strict on not allowing data coming in to a
> getsockopt call.. at least thats what I have been told.

STREAMS XTI/TPI supports both getsockopt() and setsockopt() through
a single options management request interface.  Information is both
transferred in and transferred out in the same call.  So, not only
can options mangement pass information with a get operation, it can
retrieve information with a set operation.

 http://www.openss7.org/man2html?3+t_optmgmt
 http://www.openss7.org/man2html?7+T_OPTMGMT_REQ
 http://www.openss7.org/man2html?7+T_OPTMGMT_ACK

Any limitation is certainly not the fault of the TPI interface.

--brian

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/




From tsvwg-bounces@ietf.org Mon Apr 02 12:38:31 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYPXQ-0005Y3-7b; Mon, 02 Apr 2007 12:37:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPXM-0005Vc-Cg
	for tsvwg@ietf.org; Mon, 02 Apr 2007 12:37:44 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPXJ-0003SG-PN
	for tsvwg@ietf.org; Mon, 02 Apr 2007 12:37:44 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l32GbHfw015375; Mon, 2 Apr 2007 19:37:33 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 19:37:28 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 2 Apr 2007 19:37:28 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by
	esebh101.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 19:37:28 +0300
Received: from [172.21.34.205] (esdhcp034205.research.nokia.com
	[172.21.34.205])
	by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l32GbQtg014793; Mon, 2 Apr 2007 19:37:26 +0300
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0C961E0B@is0004avexu1.global.avaya.com>
References: <XFE-SJC-2116KZmcK8r0000385d@xfe-sjc-211.amer.cisco.com>
	<DD8C1057-395E-46AE-BF5A-CE39E58E5563@nokia.com>
	<AAB4B3D3CF0F454F98272CBE187FDE2F0C961E0B@is0004avexu1.global.avaya.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--343852764;
	protocol="application/pkcs7-signature"
Message-Id: <D3C4D21E-212B-4707-BBAA-40F3FA39E45D@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg] TSVWG
	meeting"hum" confirmations with the list)
Date: Mon, 2 Apr 2007 19:37:22 +0300
To: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 02 Apr 2007 16:37:28.0685 (UTC)
	FILETIME=[33DFD9D0:01C77545]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070402193733-3AD24BB0-3270C887/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: "ext James M. Polk" <jmpolk@cisco.com>, tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-22--343852764
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 2007-3-29, at 13:12, ext Romascanu, Dan (Dan) wrote:
>> From: Lars Eggert [mailto:lars.eggert@nokia.com]
>> Now, the issue seems to be that if you throw flows of
>> different media types into that traffic class - even if their
>> aggregate bandwidth use is within capacity - this can result
>> in unacceptable media quality in some (many?) scenarios.
>
> Why that? Assuming that the capacity threshold according to which the
> admission happens is computed correctly, why should unacceptable media
> result for traffic admitted within limits.

As I understand it - and someone needs to really jump in here and  
tell me whether I've understood it - is that jitter gets sufficiently  
bad to really affect voice quality, even under low loss. Remember  
that this is for interactive traffic.

>> What worries me is that I see no indication that two DSCPs is
>> all that will be needed. The current deployment interest
>> seems to be in mixing CAC voice and video, but will we need
>> to allocate additional DSCPs when deployments want to
>> capacity-admit additional types of traffic? How many?
>
> This argument seems to me valid. Actually I doubt that mixing CAC  
> voice
> and video is a good thing in many real scenarios as bandwidth, traffic
> profile and QoS metrics largely differ for voice-only and
> voice-and-video applications.

I don't follow, can you clarify? Your first sentence agrees with the  
argument (that we're on a slippery slope towards per-media-type  
DSCPs, which I find worrying), but then you say one shouldn't mix  
traffic types, which seems to argue _for_ per-media-type DSCPs.

>> DiffServ wasn't meant to eliminate the need for some degree
>> of over- provisioning, and it seems that if the admission
>> controller would keep utilization of the capacity for
>> capacity-admitted traffic below some threshold, media quality
>> would remain acceptable, and only a single DSCP would be
>> needed. Is that not sufficient?
>
> IMHO the proposal brings a relative optimization that would help in  
> many
> scenarios. Yes, it does not scale infinitely in what concerns the  
> number
> of media types / traffic classes, yet if aggregation is used so that
> balance is kept between the number of classes and the types of  
> media and
> applications that are supported such an optimization seems to help.

I'd be happier if we could draw a boundary between these two kinds of  
traffic that aren't based on media types, because that'd give me some  
reassurance that we're not setting ourselves up for many more future  
registrations.

Idea: can we reclassify "capacity admitted voice" as "capacity  
admitted low-jitter" traffic, and "capacity-admitted video" as  
"capacity admitted high-bandwidth", and argue that the former should  
have precedence over the latter? (Or something like this; my proposal  
may be naive.)

Lars

PS: all hats off

--Apple-Mail-22--343852764
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDIxNjM3MjNaMCMGCSqGSIb3DQEJBDEWBBQjh5NwoII3BohV
fnWlr+vj1o1MmzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAC1dXNwwEwkdtsbTAd8SeTUy2mr5BaFIG/rI5+E7Sef4UfHQWrJ0j
zHqc7gww7JsKe7CuAsAYHdA7qZTyElkclcXL5Zm+KxZVvlo3hhWpznTy7WoLGy8Hiz0rMWhQY6qg
gvbi3Iml9kVLdTa81Yub6aJ+0YbpNvJSuiXmXuggpxT1XdPTf5p+0Y2uSqshh5iRshjS8jfrdmiC
w/Rc586mPzD8yaoHGSN9UueZvAqYFDcdaMvRtRAtJYnoc3ouL/+uIvvQCuz928wTjWD/MpLnm4pE
9mncWWlZD/F+84IZotYoB1jw4Knax/Rs+sujT+s/ACLpvVohZRJ6JQRLOVPpgQAAAAAAAA==

--Apple-Mail-22--343852764--




From tsvwg-bounces@ietf.org Tue Apr 03 06:09:58 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYfwp-0008Ba-2N; Tue, 03 Apr 2007 06:09:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfwn-0008AJ-Aj
	for tsvwg@ietf.org; Tue, 03 Apr 2007 06:09:05 -0400
Received: from ccerelbas02.cce.hp.com ([161.114.21.105])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfwi-0002SX-1z
	for tsvwg@ietf.org; Tue, 03 Apr 2007 06:09:05 -0400
Received: from G3W0059.americas.hpqcorp.net (g3w0059.americas.hpqcorp.net
	[16.232.1.16])
	by ccerelbas02.cce.hp.com (Postfix) with ESMTP id 287DF341CB;
	Tue,  3 Apr 2007 05:08:55 -0500 (CDT)
Received: from G3W0067.americas.hpqcorp.net ([16.232.1.13]) by
	G3W0059.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 10:08:08 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] Socket API draft
Date: Tue, 3 Apr 2007 10:04:31 -0000
Message-ID: <9F1C5E38B812894EBC31973D010273CB019D1347@G3W0067.americas.hpqcorp.net>
In-Reply-To: <460FA0E2.9080309@lakerest.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tsvwg] Socket API draft
Thread-Index: Acd0VihLF94j3E/STKyp1QIbzxY/tQAx1cPA
References: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>
	<460FA0E2.9080309@lakerest.net>
From: "Sirigiri, Anil Kumar Reddy (STSD)" <sakreddy@hp.com>
To: "Randall Stewart" <randall@lakerest.net>
X-OriginalArrivalTime: 03 Apr 2007 10:08:08.0620 (UTC)
	FILETIME=[FA9A8EC0:01C775D7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


: > 2/ What is the use of sctp_opt_info() to have assoc_id as the=20
: > parameter ? I see that all sctp_opt_info() options are having the=20
: > assoc_id in the option argument structures. Though, there=20
: is no harm=20
: > in having it, I just have this question out of curiosity to=20
: know the reason behind it.
:=20
: sctp_opt_info() was created for O/S's that cannot pass=20
: information in on a getsockopt() call. You want to pass info=20
: in when you are explicitly getting information on an=20
: association. In BSD land either sctp_opt_info or getsockopt()=20
: will work.. in fact sctp_opt_info just calls a=20
: getsockopt()... since BSD allows the passing of information=20
: in to the getsockopt call.

Thanks for clarifying this. Yes, I got this point from the draft -- I do
not have any questions on the 'need' of it. My question is related to
the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
my previous mail. Considering the following API syntax:

	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
socklen_t *size);

Here, why do we have 'id' (association id) as the parameter when we
already have this as a member in all opt's "arg" structures applicable
to sctp_opt_info() ?=20

--
Anil





From tsvwg-bounces@ietf.org Tue Apr 03 08:17:31 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYhvY-0008NR-Nd; Tue, 03 Apr 2007 08:15:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhvX-0008NJ-7i
	for tsvwg@ietf.org; Tue, 03 Apr 2007 08:15:55 -0400
Received: from [2001:240:585:2:203:6dff:fe1a:4ddc] (helo=lakerest.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhvV-0008GJ-77
	for tsvwg@ietf.org; Tue, 03 Apr 2007 08:15:55 -0400
Received: from [10.1.1.11] (ibmlap [10.1.1.11])
	by lakerest.net (8.13.8/8.13.8) with ESMTP id l33CFal6027305;
	Tue, 3 Apr 2007 08:15:36 -0400 (EDT)
	(envelope-from randall@lakerest.net)
Message-ID: <46124618.3010601@lakerest.net>
Date: Tue, 03 Apr 2007 08:18:32 -0400
From: Randall Stewart <randall@lakerest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: "Sirigiri, Anil Kumar Reddy (STSD)" <sakreddy@hp.com>
Subject: Re: [Tsvwg] Socket API draft
References: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>	<460FA0E2.9080309@lakerest.net>
	<9F1C5E38B812894EBC31973D010273CB019D1347@G3W0067.americas.hpqcorp.net>
In-Reply-To: <9F1C5E38B812894EBC31973D010273CB019D1347@G3W0067.americas.hpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Sirigiri, Anil Kumar Reddy (STSD) wrote:
> : > 2/ What is the use of sctp_opt_info() to have assoc_id as the 
> : > parameter ? I see that all sctp_opt_info() options are having the 
> : > assoc_id in the option argument structures. Though, there 
> : is no harm 
> : > in having it, I just have this question out of curiosity to 
> : know the reason behind it.
> : 
> : sctp_opt_info() was created for O/S's that cannot pass 
> : information in on a getsockopt() call. You want to pass info 
> : in when you are explicitly getting information on an 
> : association. In BSD land either sctp_opt_info or getsockopt() 
> : will work.. in fact sctp_opt_info just calls a 
> : getsockopt()... since BSD allows the passing of information 
> : in to the getsockopt call.
> 
> Thanks for clarifying this. Yes, I got this point from the draft -- I do
> not have any questions on the 'need' of it. My question is related to
> the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
> my previous mail. Considering the following API syntax:
> 
> 	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
> socklen_t *size);
> 
> Here, why do we have 'id' (association id) as the parameter when we
> already have this as a member in all opt's "arg" structures applicable
> to sctp_opt_info() ? 
> 
I believe it would probably be for the same reason that
Kacheong sites that we have the call in the first place...

Kacheong? Is that why :-D?

R


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)




From tsvwg-bounces@ietf.org Tue Apr 03 18:42:15 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYrgO-0003pM-Ve; Tue, 03 Apr 2007 18:40:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrgN-0003l5-P8
	for tsvwg@ietf.org; Tue, 03 Apr 2007 18:40:55 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYrgM-00007N-Gg
	for tsvwg@ietf.org; Tue, 03 Apr 2007 18:40:55 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2007 18:40:54 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l33MesE9002966
	for <tsvwg@ietf.org>; Tue, 3 Apr 2007 18:40:54 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33MemGl005905
	for <tsvwg@ietf.org>; Tue, 3 Apr 2007 22:40:54 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 18:40:52 -0400
Received: from jmpolk-wxp.cisco.com ([10.82.216.233]) by
	xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Apr 2007 18:40:51 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 03 Apr 2007 17:40:50 -0500
To: tsvwg <tsvwg@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <XFE-RTP-201CHPbZEzu000035b4@xfe-rtp-201.amer.cisco.com>
X-OriginalArrivalTime: 03 Apr 2007 22:40:52.0186 (UTC)
	FILETIME=[222FD3A0:01C77641]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=328; t=1175640054;
	x=1176504054; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jmpolk@cisco.com;
	z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com>
	|Subject:=20*Draft*=20meeting=20minutes=20from=20Prague=20now=20available
	|Sender:=20 |To:=20tsvwg=20<tsvwg@ietf.org>;
	bh=QJHS66DPdeXcxBpxV1flkKJv85kH6dPyRdOV1mZU+zE=;
	b=MarIbMyfAEC//G6ZXJbjBR6Fz3dSX8pX+2lH9iz4u6fymi2797X3/zCBmWHyjGVQ0nYm0AQP
	Ec724+DoIeTtG0pV/7thg+C+9oDnczVSwcIoy1ZS/TJdGELXWaOHTPt8;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Subject: [Tsvwg] *Draft* meeting minutes from Prague now available
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

These are the *draft* TSVWG minutes from our Prague meetings.

         http://www3.ietf.org/proceedings/07mar/minutes/tsvwg.txt

Comments and corrections are welcome


Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"




From tsvwg-bounces@ietf.org Tue Apr 03 18:57:04 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HYrvd-0007Jk-1x; Tue, 03 Apr 2007 18:56:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrvc-0007Jf-3y
	for tsvwg@ietf.org; Tue, 03 Apr 2007 18:56:40 -0400
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYrva-0005Py-NP
	for tsvwg@ietf.org; Tue, 03 Apr 2007 18:56:40 -0400
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com
	[47.129.230.97])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l33MuYx18378; Tue, 3 Apr 2007 22:56:35 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg] TSVWG
	meeting"hum" confirmations with the list)
Date: Tue, 3 Apr 2007 18:56:03 -0400
Message-ID: <9671A92C3C8B5744BC97F855F7CB64650F887471@zcarhxm1.corp.nortel.com>
In-Reply-To: <D3C4D21E-212B-4707-BBAA-40F3FA39E45D@nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg] TSVWG
	meeting"hum" confirmations with the list)
Thread-Index: Acd1RZY94CmR99K+R7Gy/TCc2f4YlwA+4cqQ
From: "Jozef Babiarz" <babiarz@nortel.com>
To: "Lars Eggert" <lars.eggert@nokia.com>,
	"ext Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: "ext James M. Polk" <jmpolk@cisco.com>, tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On April 2, 2007 Lars Eggert wrote:
>I'd be happier if we could draw a boundary between these two kinds of =20
>traffic that aren't based on media types, because that'd give me some =20
>reassurance that we're not setting ourselves up for many more future =20
>registrations.
>
>Idea: can we reclassify "capacity admitted voice" as "capacity =20
>admitted low-jitter" traffic, and "capacity-admitted video" as =20
>"capacity admitted high-bandwidth", and argue that the former should =20
>have precedence over the latter? (Or something like this; my proposal =20
>may be naive.)
I'm OK with classify it for "capacity admitted low-jitter" traffic. I
believe that voice was only an example as it will mostly be the first
use case. Same for "capacity admitted high-bandwidth", MPEG4 video flows
would be an example of traffic that would use this DSCP. My view is that
any flow that fits the defined characteristics and performance
requirements can use this capability and is not limited to voice or
video flows.=20

Regards, Joe
email:babiarz@nortel.com
Telephone:613-763-6098
-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@nokia.com]=20
Sent: April 2, 2007 12:37 PM
To: ext Romascanu, Dan (Dan)
Cc: ext James M. Polk; tsvwg
Subject: Re: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg]
TSVWG meeting"hum" confirmations with the list)

On 2007-3-29, at 13:12, ext Romascanu, Dan (Dan) wrote:
>> From: Lars Eggert [mailto:lars.eggert@nokia.com]
>> Now, the issue seems to be that if you throw flows of
>> different media types into that traffic class - even if their
>> aggregate bandwidth use is within capacity - this can result
>> in unacceptable media quality in some (many?) scenarios.
>
> Why that? Assuming that the capacity threshold according to which the
> admission happens is computed correctly, why should unacceptable media
> result for traffic admitted within limits.

As I understand it - and someone needs to really jump in here and =20
tell me whether I've understood it - is that jitter gets sufficiently =20
bad to really affect voice quality, even under low loss. Remember =20
that this is for interactive traffic.

>> What worries me is that I see no indication that two DSCPs is
>> all that will be needed. The current deployment interest
>> seems to be in mixing CAC voice and video, but will we need
>> to allocate additional DSCPs when deployments want to
>> capacity-admit additional types of traffic? How many?
>
> This argument seems to me valid. Actually I doubt that mixing CAC =20
> voice
> and video is a good thing in many real scenarios as bandwidth, traffic
> profile and QoS metrics largely differ for voice-only and
> voice-and-video applications.

I don't follow, can you clarify? Your first sentence agrees with the =20
argument (that we're on a slippery slope towards per-media-type =20
DSCPs, which I find worrying), but then you say one shouldn't mix =20
traffic types, which seems to argue _for_ per-media-type DSCPs.

>> DiffServ wasn't meant to eliminate the need for some degree
>> of over- provisioning, and it seems that if the admission
>> controller would keep utilization of the capacity for
>> capacity-admitted traffic below some threshold, media quality
>> would remain acceptable, and only a single DSCP would be
>> needed. Is that not sufficient?
>
> IMHO the proposal brings a relative optimization that would help in =20
> many
> scenarios. Yes, it does not scale infinitely in what concerns the =20
> number
> of media types / traffic classes, yet if aggregation is used so that
> balance is kept between the number of classes and the types of =20
> media and
> applications that are supported such an optimization seems to help.

I'd be happier if we could draw a boundary between these two kinds of =20
traffic that aren't based on media types, because that'd give me some =20
reassurance that we're not setting ourselves up for many more future =20
registrations.

Idea: can we reclassify "capacity admitted voice" as "capacity =20
admitted low-jitter" traffic, and "capacity-admitted video" as =20
"capacity admitted high-bandwidth", and argue that the former should =20
have precedence over the latter? (Or something like this; my proposal =20
may be naive.)

Lars

PS: all hats off




From tsvwg-bounces@ietf.org Wed Apr 04 04:43:29 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ14A-0006dU-Hz; Wed, 04 Apr 2007 04:42:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ149-0006Zr-1u
	for tsvwg@ietf.org; Wed, 04 Apr 2007 04:42:05 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ146-0006e1-KE
	for tsvwg@ietf.org; Wed, 04 Apr 2007 04:42:05 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l348fgQt027482 for <tsvwg@ietf.org>; Wed, 4 Apr 2007 11:41:58 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 11:41:43 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by
	esebh104.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 11:41:43 +0300
Received: from [172.21.34.222] (esdhcp034222.research.nokia.com
	[172.21.34.222])
	by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l348ffjB022530 for <tsvwg@ietf.org>; Wed, 4 Apr 2007 11:41:41 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <802CE23E-2D4E-4B33-8AD6-E9986C1B983C@nokia.com>
References: <4.3.2.7.2.20061013163233.02fd5f08@email.cisco.com>
	<802CE23E-2D4E-4B33-8AD6-E9986C1B983C@nokia.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <09F8B9E7-7ED9-439D-B54D-2D15E30A97EB@nokia.com>
Content-Transfer-Encoding: 7bit
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-2960bis-02 starts NOW
Date: Wed, 4 Apr 2007 11:41:35 +0300
To: tsvwg WG <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 04 Apr 2007 08:41:43.0034 (UTC)
	FILETIME=[122AADA0:01C77695]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070404114158-6B2F2BB0-3CE834AA/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On 2007-3-26, at 18:06, ext Lars Eggert wrote:
>
> Apologies to the authors - we dropped the ball on this one over the  
> holidays. There was significant discussion on -02 that lead to -03  
> being submitted to the secretariat some months ago, but it didn't  
> get published until last week. We're currently trying to find out  
> exactly what went wrong.
>
> In the meantime: Please take a look at -03 and send final WGLC  
> comments until April 8.

Four days left. Current consensus - based on the comments from last  
year - seems to be to request publication. Please speak up if you  
agree or disagree.

Lars






From tsvwg-bounces@ietf.org Wed Apr 04 06:46:32 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ2zO-0008V8-FV; Wed, 04 Apr 2007 06:45:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ2zM-0008SC-PY
	for tsvwg@ietf.org; Wed, 04 Apr 2007 06:45:16 -0400
Received: from sca-ea-mail-1.sun.com ([192.18.43.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ2zI-0006aQ-3l
	for tsvwg@ietf.org; Wed, 04 Apr 2007 06:45:16 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l34AjA8L002483; Wed, 4 Apr 2007 10:45:10 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l34Aj629371057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Apr 2007 03:45:09 -0700 (PDT)
Message-ID: <461381B1.1050409@sun.com>
Date: Wed, 04 Apr 2007 18:45:05 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: "Sirigiri, Anil Kumar Reddy (STSD)" <sakreddy@hp.com>
Subject: Re: [Tsvwg] Socket API draft
References: <9F1C5E38B812894EBC31973D010273CB019859FB@G3W0067.americas.hpqcorp.net>
	<460FA0E2.9080309@lakerest.net>
	<9F1C5E38B812894EBC31973D010273CB019D1347@G3W0067.americas.hpqcorp.net>
In-Reply-To: <9F1C5E38B812894EBC31973D010273CB019D1347@G3W0067.americas.hpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Sirigiri, Anil Kumar Reddy (STSD) wrote:

> Thanks for clarifying this. Yes, I got this point from the draft -- I do
> not have any questions on the 'need' of it. My question is related to
> the argument list of sctp_opt_info() - sorry, if it wasn't very clear in
> my previous mail. Considering the following API syntax:
> 
> 	int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg,
> socklen_t *size);
> 
> Here, why do we have 'id' (association id) as the parameter when we
> already have this as a member in all opt's "arg" structures applicable
> to sctp_opt_info() ? 


My vague memory suggested that that this may an historical
artifact in the merge of 1-1 and 1-N style SCTP socket.  In
the pre-00 version of the draft, I believe there was no
association ID in those socket option structures.  So there
was a need for the ID in the sctp_opt_info().  Then the same
structures were modified to have the association ID.  Since
it is better for both getsockopt() and sctp_opt_info() to use
the same structures and we didn't want to change the function
prototype, it was kept.  Note that this was just from memory...

BTW, in the 00 version of the draft, the text for sctp_opt_info()
was written as

  getsockopt() is read-only, so a new interface is required when
  information must be passed both in to and out of the SCTP stack.

The first part is the reason for the function.  We want to keep
the getsockopt() semantics to be read-only, as applied to all
other types of sockets.  The option value argument will be not
be copyin.  It is not because of an implementation issue.



-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Wed Apr 04 07:58:26 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ477-0006h2-0B; Wed, 04 Apr 2007 07:57:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ475-0006g9-6c
	for tsvwg@ietf.org; Wed, 04 Apr 2007 07:57:19 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZ471-0006IO-Ql
	for tsvwg@ietf.org; Wed, 04 Apr 2007 07:57:19 -0400
Received: from [192.168.1.2] (p508FC99D.dip.t-dialin.net [80.143.201.157])
	by mail-n.franken.de (Postfix) with ESMTP id A22C380000A5;
	Wed,  4 Apr 2007 13:57:05 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <461380FB.6060704@cisco.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Date: Wed, 4 Apr 2007 13:57:02 +0200
To: Randall Stewart <rrs@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
Subject: [Tsvwg] Re: ephemeral ports and bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randy,

I'm not sure if it is a good idea to silently accept things
from the user (x,y) which are wrong without complaining, just
ignoring...

So what about:

1. allow bindx() after bind() or without bind().
2. if in bind() or bindx() any non-zero port number
    is used and checked. This allows explicit binding
    with bind() and bindx(). It required to use the
    same non-zero port number in all bindx() calls.
3. If a zero port number is used the kernel will
    chose an ephemeral one if the socket is unbound
    or will use the already known one if the socket
    is bound.

If something goes wrong, return an error.

Best regards
Michael

On Apr 4, 2007, at 12:42 PM, Randall Stewart wrote:

> Jan:
>
> Well I was wrong..
>
> BSD does NOT act the way you describe that linux does.. and in
> fact what it does seems to make more sense..
>
> What BSD does is explicitly IGNORE the port that is
> present if you are already bound and uses the one
> you are bound to.
>
> So if you send in
>
> bindx(
> addr1: port=0
> addr2: port=x
> addr3: port=y
> )
>
> And you are already bound to say port z, you will
> get addr1, addr2 and addr3 added to the endpoint.
>
> If you were NOT bound, you would get an ephemeral port
> z and be bound to it on addr1, followed by additional
> bindings of z to addr2 and addr3.. the port arguments
> x, y would be ignored.
>
> Hmm.. not sure which is the right way.. but this really
> should be discussed on the tsvwg list (as to text
> changes to the socket-api).
>
> R
>
>
> Randall Stewart wrote:
>> Jan Newmarch wrote:
>>> Hi Randall,
>>>
>>> Sorry, I thought I included a copy of my query - but I am currenty
>>> forced to use one of those web mail systems and it must be doing  
>>> funny
>>> things... Here is my question:
>> I can still subscribe you to the list.. But I will try to
>> answer the question below..
>>>
>>>
>>> I have a query about ephemeral ports and subsetting interfaces in a
>>> bindx call. I understand that
>>> if connect/listen/etc are called before a bind operation is done,  
>>> then
>>> a bind to an ephemeral
>>> port is done with all available interfaces added to the source  
>>> side of
>>> the association. I also
>>> understand that I can call bindx to add add/remove interfaces  
>>> from the
>>> source side of an
>>> association, but that the port in these calls must be the same  
>>> for all
>>> interfaces and be the
>>> same as any existing bound port for the association.
>> Right, and further more once you have bound all.. you really can't
>> unbind all (aka by using bindx.. at least I don't think you can ;D)
>>>
>>> My query concerns binding a subset of interfaces to an ephemeral  
>>> port.
>>> I can ask for ephemeral
>>> port assignment by specifying a port number of zero in a bind of a
>>> single interface - this does
>>> not seem to be documented in the RFCs but follows the TCP practise.
>> Yep that should work. The kernel will pick a random port for
>> you.
>>> The Linux kernel implementation
>>> behaves in thie way.
>> So does BSD.
>> But if I call bindx with more than one interface
>>> all with port set to zero,
>>> the implementation assigns an ephemeral port to the first interface
>>> and then returns an error
>>> condition as the socket is now bound to this ephemeral port and the
>>> later interfaces have port zero,
>>> a different value.
>> Ahh.. this sound like a bug.. and I bet that BSD has the same
>> one. Basically when you call bindx with multiple interfaces
>> it usually is a socket opt (setsockopt()) underneath. Then,
>> after you have bound the port, it calls successively to
>> bindx each additional port. So that what is happening
>> is it sees an error, in that you are using a different
>> port (or trying to).
>> I will check the BSD code.. I bet the same bug
>> exists.. and I will fix it.. Linux, if they have
>> this bug, should do the same..
>>>
>>> Why do this? e.g. laptop with ethernet, wifi and wimax. In Aus,  
>>> wimax
>>> is horribly expensive, so
>>> using this should be avoided by user applications where possible.  
>>> So a
>>> client would only expose
>>> the ethernet and wifi interfaces when connecting to a service if  
>>> possible.
>> Thats find.. it SHOULD work.. I think you have just
>> discovered a bug (and like I said I bet its in my implementation
>> too :-D)
>>>
>>> Workaround: call bind with a single interface to bind to an  
>>> ephemeral
>>> port and then bindx with the
>>> remaining interfaces all set to this port value.
>>>
>>> Specification change? Can I propose the following addition to the  
>>> spec:
>>>
>>> "If bindx is called and all ports are set to zero, then if the  
>>> socket
>>> is currently bound, the ports
>>> will be set to the bound port value. If the socket currently is
>>> unbound, then the socket will be
>>> bound to the same ephemeral value for all the socket addresses."
>> This seems reasonable.. and is a clarification of how it
>> SHOULD be working :-D
>>>
>>> Note 1: This will involve a change to the Linux implementation at
>>> least. But it is a small change.
>> and BSD too I think ..
>>>
>>> Note 2: I ignore the possibility of the bindx call containing a
>>> mixture of zero ports and a single
>>> non-zero value to bind to. This is possible, but just messy.
>> And may fail if the first port is 0, since then you pick
>> a different port than those in the list.
>> R
>>>
>>> Jan
>>> -- 
>>>
>>> On 4/3/07, Randall Stewart <rrs@cisco.com> wrote:
>>>> Jan Newmarch wrote:
>>>> > Hi Randall
>>>> >
>>>> > I've been trynig and failing to join the sctp-impl mailing  
>>>> list - I
>>>> > just get no reply from mailer@cisco.com and can't post. In the
>>>> > meantime, I have a query which maybe you could comment on or  
>>>> perhaps
>>>> > just forward it to the list.
>>>> >
>>>>
>>>>
>>>> Hmm thats strange..
>>>>
>>>> Let me join you.. which email do you want the to or cc?
>>>>
>>>> R
>>>> > Cheers
>>>> >
>>>> > Jan
>>>> > --
>>>>
>>>> Randall Stewart
>>>> NSSTG - Cisco Systems Inc.
>>>> 803-345-0369 <or> 803-317-4952 (cell)
>>>>
>>>
>
>
> -- 
> Randall Stewart
> NSSTG - Cisco Systems Inc.
> 803-345-0369 <or> 803-317-4952 (cell)
>





From tsvwg-bounces@ietf.org Wed Apr 04 08:12:40 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ4LZ-0001Sv-3v; Wed, 04 Apr 2007 08:12:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4LX-0001LT-IV
	for tsvwg@ietf.org; Wed, 04 Apr 2007 08:12:15 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZ4LW-0003tV-7V
	for tsvwg@ietf.org; Wed, 04 Apr 2007 08:12:15 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-1.cisco.com with ESMTP; 04 Apr 2007 05:12:11 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l34CCBLG031078; 
	Wed, 4 Apr 2007 05:12:11 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l34CCBMF010390;
	Wed, 4 Apr 2007 12:12:11 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 05:12:11 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 05:12:10 -0700
Message-ID: <461396B8.4090403@cisco.com>
Date: Wed, 04 Apr 2007 08:14:48 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
In-Reply-To: <B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 12:12:11.0180 (UTC)
	FILETIME=[7920D6C0:01C776B2]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1418; t=1175688731;
	x=1176552731; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=LVq1qxEAr6OMQwsSBmbTz4zqIF3H0/CQ+efgpiAC+SE=;
	b=OWmAN7Q+pD11w9+d6Rp3BEHwtDNIipgUYQWTR608Ful/5cN8AQltmodf37lWwy8rcLOqD/ko
	mHLXw/E9T0js+j5jBVn3L2EIhZmHF2x25Bzba6DIBHixyWsRxcTn+LkP;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
Subject: [Tsvwg] Re: ephemeral ports and bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:
> Randy,
> 
> I'm not sure if it is a good idea to silently accept things
> from the user (x,y) which are wrong without complaining, just
> ignoring...

Yes.. I thought about that.. and it of course
depends... I can see someone really specifying
multiple ports in a bindx and thinking they could
do this.

On the other hand, I can see people just forgetting
to 0 it out.. and leaving garbage in there..

Thus I think we did it that way in the "be liberal
in what you accept tradition".. but it may be wrong :-D
> 
> So what about:
> 
> 1. allow bindx() after bind() or without bind().
ok (we do this today as you know and I think linux does too
     from Kacheong's email Solaris does NOT).

> 2. if in bind() or bindx() any non-zero port number
>    is used and checked. This allows explicit binding
>    with bind() and bindx(). It required to use the
>    same non-zero port number in all bindx() calls.
ok

> 3. If a zero port number is used the kernel will
>    chose an ephemeral one if the socket is unbound
>    or will use the already known one if the socket
>    is bound.

Ok

Kacheong, what do you think?

R

> 
> If something goes wrong, return an error.
> 
> Best regards
> Michael
> 
> On Apr 4, 2007, at 12:42 PM, Randall Stewart wrote:
> 

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 09:19:35 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ5NU-0007mz-IO; Wed, 04 Apr 2007 09:18:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5NS-0007ko-Q2
	for tsvwg@ietf.org; Wed, 04 Apr 2007 09:18:18 -0400
Received: from atlrel7.hp.com ([156.153.255.213])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ5NR-0005d0-HO
	for tsvwg@ietf.org; Wed, 04 Apr 2007 09:18:18 -0400
Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114])
	by atlrel7.hp.com (Postfix) with ESMTP id 9435A35BDC;
	Wed,  4 Apr 2007 09:18:14 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp2.fc.hp.com (Postfix) with ESMTP id C6CDE178F9D;
	Wed,  4 Apr 2007 13:18:13 +0000 (UTC)
Message-ID: <4613A595.6040509@hp.com>
Date: Wed, 04 Apr 2007 09:18:13 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com>
In-Reply-To: <461396B8.4090403@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	jan@newmarch.name, TSWG <tsvwg@ietf.org>
Subject: [Tsvwg] Re: ephemeral ports and bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
>> So what about:
>>
>> 1. allow bindx() after bind() or without bind().
> ok (we do this today as you know and I think linux does too
>     from Kacheong's email Solaris does NOT).

Hmm..  well, linux doesn't do bindx without bind yet.  This was
kicked around a while ago on both lksctp and sctp-impl lists, and I
think the decision was to not allow that particular combination.

I do think that it would be a useful relaxation of the rule.

> 
>> 2. if in bind() or bindx() any non-zero port number
>>    is used and checked. This allows explicit binding
>>    with bind() and bindx(). It required to use the
>>    same non-zero port number in all bindx() calls.
> ok

agree

> 
>> 3. If a zero port number is used the kernel will
>>    chose an ephemeral one if the socket is unbound
>>    or will use the already known one if the socket
>>    is bound.
> 
> Ok

also agree.

-vlad




From tsvwg-bounces@ietf.org Wed Apr 04 09:58:08 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ5zV-0006ks-Kz; Wed, 04 Apr 2007 09:57:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ5zV-0006kn-3s
	for tsvwg@ietf.org; Wed, 04 Apr 2007 09:57:37 -0400
Received: from atlrel9.hp.com ([156.153.255.214])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ5zT-0001Pp-RN
	for tsvwg@ietf.org; Wed, 04 Apr 2007 09:57:37 -0400
Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127])
	by atlrel9.hp.com (Postfix) with ESMTP id B35AC35D4C;
	Wed,  4 Apr 2007 09:57:30 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp1.fc.hp.com (Postfix) with ESMTP id E5758137A48;
	Wed,  4 Apr 2007 13:57:29 +0000 (UTC)
Message-ID: <4613AEC9.6060404@hp.com>
Date: Wed, 04 Apr 2007 09:57:29 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: SCTP Implementors <sctp-impl@external.cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613A595.6040509@hp.com>
In-Reply-To: <4613A595.6040509@hp.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	Randall Stewart <rrs@cisco.com>, jan@newmarch.name, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Vlad Yasevich wrote:
> Randall Stewart wrote:
>>> So what about:
>>>
>>> 1. allow bindx() after bind() or without bind().
>> ok (we do this today as you know and I think linux does too
>>     from Kacheong's email Solaris does NOT).
> 
> Hmm..  well, linux doesn't do bindx without bind yet.  This was
> kicked around a while ago on both lksctp and sctp-impl lists, and I
> think the decision was to not allow that particular combination.
> 
> I do think that it would be a useful relaxation of the rule.

Oops... I looked more closely, and it looks like this was added
after all.

I think some clarifications in the draft would be useful.

-vlad
> 
>>> 2. if in bind() or bindx() any non-zero port number
>>>    is used and checked. This allows explicit binding
>>>    with bind() and bindx(). It required to use the
>>>    same non-zero port number in all bindx() calls.
>> ok
> 
> agree
> 
>>> 3. If a zero port number is used the kernel will
>>>    chose an ephemeral one if the socket is unbound
>>>    or will use the already known one if the socket
>>>    is bound.
>> Ok
> 
> also agree.
> 
> -vlad
> 





From tsvwg-bounces@ietf.org Wed Apr 04 13:00:21 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ8pA-0002kn-Sg; Wed, 04 Apr 2007 12:59:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8p0-0001tu-P9
	for tsvwg@ietf.org; Wed, 04 Apr 2007 12:58:58 -0400
Received: from sca-ea-mail-3.sun.com ([192.18.43.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8mL-0003Z2-5v
	for tsvwg@ietf.org; Wed, 04 Apr 2007 12:56:16 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l34GteoT005602; Wed, 4 Apr 2007 16:55:40 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l34GtZ0R420829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Apr 2007 09:55:39 -0700 (PDT)
Message-ID: <4613D887.1030303@sun.com>
Date: Thu, 05 Apr 2007 00:55:35 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com>
In-Reply-To: <461396B8.4090403@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>, jan@newmarch.name,
	SCTP Implementors <sctp-impl@external.cisco.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> Michael Tuexen wrote:
>> Randy,
>>
>> I'm not sure if it is a good idea to silently accept things
>> from the user (x,y) which are wrong without complaining, just
>> ignoring...
> 
> Yes.. I thought about that.. and it of course
> depends... I can see someone really specifying
> multiple ports in a bindx and thinking they could
> do this.
> 
> On the other hand, I can see people just forgetting
> to 0 it out.. and leaving garbage in there..
> 
> Thus I think we did it that way in the "be liberal
> in what you accept tradition".. but it may be wrong :-D


Thinking as an app writer, I guess it is easier if a field
is not required, then it should be ignored.  What Randy
wrote originally is easier.


>> So what about:
>>
>> 1. allow bindx() after bind() or without bind().
> ok (we do this today as you know and I think linux does too
>     from Kacheong's email Solaris does NOT).


If this is allowed, then I guess the first element of
the sctp_bindx() address array becomes the significant
one.  This needs to be noted.


>> 2. if in bind() or bindx() any non-zero port number
>>    is used and checked. This allows explicit binding
>>    with bind() and bindx(). It required to use the
>>    same non-zero port number in all bindx() calls.
> ok


I assume the last sentence means that the caller can
just use 0 as the port number after the first address
element.  For example, the address array of sctp_bindx()
has two elements.  The first element has port number X.  It
means that the stack will try to bind to X.  The second
element can have a port number 0.  It is not required to
have X also.  This is probably implied in (3) below.


>> 3. If a zero port number is used the kernel will
>>    chose an ephemeral one if the socket is unbound
>>    or will use the already known one if the socket
>>    is bound.
> 
> Ok




-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Wed Apr 04 13:59:12 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZ9kT-0003JW-At; Wed, 04 Apr 2007 13:58:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ9kS-0003Eo-6L
	for tsvwg@ietf.org; Wed, 04 Apr 2007 13:58:20 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ9kQ-0006Br-Ru
	for tsvwg@ietf.org; Wed, 04 Apr 2007 13:58:20 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 04 Apr 2007 10:58:18 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l34HwIPG021616; 
	Wed, 4 Apr 2007 10:58:18 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l34HwIEk009019;
	Wed, 4 Apr 2007 17:58:18 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 10:58:16 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 10:58:14 -0700
Message-ID: <4613E7CE.2020407@cisco.com>
Date: Wed, 04 Apr 2007 14:00:46 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Kacheong Poon <kacheong.poon@sun.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
In-Reply-To: <4613D887.1030303@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 17:58:15.0597 (UTC)
	FILETIME=[D1AF6DD0:01C776E2]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2145; t=1175709498;
	x=1176573498; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=B/ddwTCsO9Jq5ln3v0KqxZN9Ewmr2iBTVvB0lJ+bOWU=;
	b=bN6xKqmv31PqIoQpKoBpPM00jiVmElHuhnNuaQVLOqr6TMA2n225aCyGiGvZC05CMWFwiYQR
	cTxmUeQMwydhlU6FCZJGCxLjRinT59a1PmzWtcwGr0LvMVMSVxunFvOz;
Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>, jan@newmarch.name,
	SCTP Implementors <sctp-impl@external.cisco.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Kacheong Poon wrote:
> Randall Stewart wrote:
>> Michael Tuexen wrote:
>>> Randy,
>>>
>>> I'm not sure if it is a good idea to silently accept things
>>> from the user (x,y) which are wrong without complaining, just
>>> ignoring...
>> Yes.. I thought about that.. and it of course
>> depends... I can see someone really specifying
>> multiple ports in a bindx and thinking they could
>> do this.
>>
>> On the other hand, I can see people just forgetting
>> to 0 it out.. and leaving garbage in there..
>>
>> Thus I think we did it that way in the "be liberal
>> in what you accept tradition".. but it may be wrong :-D
> 
> 
> Thinking as an app writer, I guess it is easier if a field
> is not required, then it should be ignored.  What Randy
> wrote originally is easier.
> 
> 
>>> So what about:
>>>
>>> 1. allow bindx() after bind() or without bind().
>> ok (we do this today as you know and I think linux does too
>>     from Kacheong's email Solaris does NOT).
> 
> 
> If this is allowed, then I guess the first element of
> the sctp_bindx() address array becomes the significant
> one.  This needs to be noted.
> 
> 
>>> 2. if in bind() or bindx() any non-zero port number
>>>    is used and checked. This allows explicit binding
>>>    with bind() and bindx(). It required to use the
>>>    same non-zero port number in all bindx() calls.
>> ok
> 
> 
> I assume the last sentence means that the caller can
> just use 0 as the port number after the first address
> element.  For example, the address array of sctp_bindx()
> has two elements.  The first element has port number X.  It
> means that the stack will try to bind to X.  The second
> element can have a port number 0.  It is not required to
> have X also.  This is probably implied in (3) below.
> 

Yep.. exactly..

R
> 
>>> 3. If a zero port number is used the kernel will
>>>    chose an ephemeral one if the socket is unbound
>>>    or will use the already known one if the socket
>>>    is bound.
>> Ok
> 
> 
> 
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 14:56:43 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZAe2-0003eR-So; Wed, 04 Apr 2007 14:55:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZAe1-0003cn-CC
	for tsvwg@ietf.org; Wed, 04 Apr 2007 14:55:45 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZAdz-0006tr-Hk
	for tsvwg@ietf.org; Wed, 04 Apr 2007 14:55:45 -0400
Received: from [192.168.1.2] (p508FC99D.dip.t-dialin.net [80.143.201.157])
	by mail-n.franken.de (Postfix) with ESMTP id 5C25D80000B9;
	Wed,  4 Apr 2007 20:55:35 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <4613E7CE.2020407@cisco.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Wed, 4 Apr 2007 20:55:33 +0200
To: Randall Stewart <rrs@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randy,

a comment in-line.

Best regards
Michael

On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:

> Kacheong Poon wrote:
>> Randall Stewart wrote:
>>> Michael Tuexen wrote:
>>>> Randy,
>>>>
>>>> I'm not sure if it is a good idea to silently accept things
>>>> from the user (x,y) which are wrong without complaining, just
>>>> ignoring...
>>> Yes.. I thought about that.. and it of course
>>> depends... I can see someone really specifying
>>> multiple ports in a bindx and thinking they could
>>> do this.
>>>
>>> On the other hand, I can see people just forgetting
>>> to 0 it out.. and leaving garbage in there..
which also applies to the family field or length field...
This might result in a bug which sometimes has effects and
sometimes not. So I would like to provide the app writer
the information that he did something wrong...
>>>
>>> Thus I think we did it that way in the "be liberal
>>> in what you accept tradition".. but it may be wrong :-D
I like that tradition, but I think "we work around your bug
most of the time" is not that helpful.

If we would say, that we ignore the the port numbers in the
bindx() at all, that might be OK...

On the other hand people are used to use port number 0 as
chose what you want, port number != 0 as use this one.
That was the reasoning to suggest the three rules...
>> Thinking as an app writer, I guess it is easier if a field
>> is not required, then it should be ignored.  What Randy
>> wrote originally is easier.
>>>> So what about:
>>>>
>>>> 1. allow bindx() after bind() or without bind().
>>> ok (we do this today as you know and I think linux does too
>>>     from Kacheong's email Solaris does NOT).
>> If this is allowed, then I guess the first element of
>> the sctp_bindx() address array becomes the significant
>> one.  This needs to be noted.
>>>> 2. if in bind() or bindx() any non-zero port number
>>>>    is used and checked. This allows explicit binding
>>>>    with bind() and bindx(). It required to use the
>>>>    same non-zero port number in all bindx() calls.
>>> ok
>> I assume the last sentence means that the caller can
>> just use 0 as the port number after the first address
>> element.  For example, the address array of sctp_bindx()
>> has two elements.  The first element has port number X.  It
>> means that the stack will try to bind to X.  The second
>> element can have a port number 0.  It is not required to
>> have X also.  This is probably implied in (3) below.
>
> Yep.. exactly..
Yes. You can have (only the port numbers are written):
0, 0, 0, 0, 0, 0 -> OK.
p, 0, p, 0, p, 0 -> OK.
p, p, p, p, p, p -> OK.
p, q (with p > 0, p!=q) -> not OK.
I would always fail the call for
0, p (p > 0)
even if the kernel choses by random the port number p...
>
> R
>>>> 3. If a zero port number is used the kernel will
>>>>    chose an ephemeral one if the socket is unbound
>>>>    or will use the already known one if the socket
>>>>    is bound.
>>> Ok
>
>
> -- 
> Randall Stewart
> NSSTG - Cisco Systems Inc.
> 803-345-0369 <or> 803-317-4952 (cell)
>





From tsvwg-bounces@ietf.org Wed Apr 04 15:23:38 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZB4k-00064z-OE; Wed, 04 Apr 2007 15:23:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZB4j-00064u-Tc
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:23:21 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZB4g-00045v-ET
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:23:21 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-1.cisco.com with ESMTP; 04 Apr 2007 12:23:18 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l34JNHUH025820; 
	Wed, 4 Apr 2007 12:23:17 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l34JMwZb005744;
	Wed, 4 Apr 2007 19:23:17 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 12:23:05 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 12:23:05 -0700
Message-ID: <4613FBC7.3070406@cisco.com>
Date: Wed, 04 Apr 2007 15:25:59 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
In-Reply-To: <AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 19:23:05.0337 (UTC)
	FILETIME=[AB681E90:01C776EE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3448; t=1175714597;
	x=1176578597; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=5HhxXZhIRhlD8eL/D4xyr2tx5kMIpZxr60u32Uw7nXU=;
	b=hPJJXL/rQo/JsKfzLMQJ90nsHqx11aOmFIh/Mhr1wjFjJArNpagISOBByQGQoMhKST7iwG6t
	kawnYnDkyssE57BB/A6Xoxudp9R02Ho2zLHocoHhYh54QrwXfpxuIP9a;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


Michael:

I am fine with that.. as long as Kacheong and Vlad agree :-D

R

Michael Tuexen wrote:
> Randy,
> 
> a comment in-line.
> 
> Best regards
> Michael
> 
> On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:
> 
>> Kacheong Poon wrote:
>>> Randall Stewart wrote:
>>>> Michael Tuexen wrote:
>>>>> Randy,
>>>>>
>>>>> I'm not sure if it is a good idea to silently accept things
>>>>> from the user (x,y) which are wrong without complaining, just
>>>>> ignoring...
>>>> Yes.. I thought about that.. and it of course
>>>> depends... I can see someone really specifying
>>>> multiple ports in a bindx and thinking they could
>>>> do this.
>>>>
>>>> On the other hand, I can see people just forgetting
>>>> to 0 it out.. and leaving garbage in there..
> which also applies to the family field or length field...
> This might result in a bug which sometimes has effects and
> sometimes not. So I would like to provide the app writer
> the information that he did something wrong...
>>>>
>>>> Thus I think we did it that way in the "be liberal
>>>> in what you accept tradition".. but it may be wrong :-D
> I like that tradition, but I think "we work around your bug
> most of the time" is not that helpful.
> 
> If we would say, that we ignore the the port numbers in the
> bindx() at all, that might be OK...
> 
> On the other hand people are used to use port number 0 as
> chose what you want, port number != 0 as use this one.
> That was the reasoning to suggest the three rules...
>>> Thinking as an app writer, I guess it is easier if a field
>>> is not required, then it should be ignored.  What Randy
>>> wrote originally is easier.
>>>>> So what about:
>>>>>
>>>>> 1. allow bindx() after bind() or without bind().
>>>> ok (we do this today as you know and I think linux does too
>>>>     from Kacheong's email Solaris does NOT).
>>> If this is allowed, then I guess the first element of
>>> the sctp_bindx() address array becomes the significant
>>> one.  This needs to be noted.
>>>>> 2. if in bind() or bindx() any non-zero port number
>>>>>    is used and checked. This allows explicit binding
>>>>>    with bind() and bindx(). It required to use the
>>>>>    same non-zero port number in all bindx() calls.
>>>> ok
>>> I assume the last sentence means that the caller can
>>> just use 0 as the port number after the first address
>>> element.  For example, the address array of sctp_bindx()
>>> has two elements.  The first element has port number X.  It
>>> means that the stack will try to bind to X.  The second
>>> element can have a port number 0.  It is not required to
>>> have X also.  This is probably implied in (3) below.
>>
>> Yep.. exactly..
> Yes. You can have (only the port numbers are written):
> 0, 0, 0, 0, 0, 0 -> OK.
> p, 0, p, 0, p, 0 -> OK.
> p, p, p, p, p, p -> OK.
> p, q (with p > 0, p!=q) -> not OK.
> I would always fail the call for
> 0, p (p > 0)
> even if the kernel choses by random the port number p...
>>
>> R
>>>>> 3. If a zero port number is used the kernel will
>>>>>    chose an ephemeral one if the socket is unbound
>>>>>    or will use the already known one if the socket
>>>>>    is bound.
>>>> Ok
>>
>>
>> -- 
>> Randall Stewart
>> NSSTG - Cisco Systems Inc.
>> 803-345-0369 <or> 803-317-4952 (cell)
>>
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 15:33:31 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZBEC-0007AV-SO; Wed, 04 Apr 2007 15:33:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBEB-0007AK-A6
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:33:07 -0400
Received: from atlrel7.hp.com ([156.153.255.213])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBE9-0005vu-Sc
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:33:07 -0400
Received: from smtp2.fc.hp.com (smtp.fc.hp.com [15.11.136.114])
	by atlrel7.hp.com (Postfix) with ESMTP id C573234811;
	Wed,  4 Apr 2007 15:33:02 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp2.fc.hp.com (Postfix) with ESMTP id D18BD17913F;
	Wed,  4 Apr 2007 19:33:01 +0000 (UTC)
Message-ID: <4613FD6D.7040908@hp.com>
Date: Wed, 04 Apr 2007 15:33:01 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com>
In-Reply-To: <4613FBC7.3070406@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> 
> Michael:
> 
> I am fine with that.. as long as Kacheong and Vlad agree :-D

Yes, I agree as well.

-vlad

> 
> R
> 
> Michael Tuexen wrote:
>> Randy,
>>
>> a comment in-line.
>>
>> Best regards
>> Michael
>>
>> On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:
>>
>>> Kacheong Poon wrote:
>>>> Randall Stewart wrote:
>>>>> Michael Tuexen wrote:
>>>>>> Randy,
>>>>>>
>>>>>> I'm not sure if it is a good idea to silently accept things
>>>>>> from the user (x,y) which are wrong without complaining, just
>>>>>> ignoring...
>>>>> Yes.. I thought about that.. and it of course
>>>>> depends... I can see someone really specifying
>>>>> multiple ports in a bindx and thinking they could
>>>>> do this.
>>>>>
>>>>> On the other hand, I can see people just forgetting
>>>>> to 0 it out.. and leaving garbage in there..
>> which also applies to the family field or length field...
>> This might result in a bug which sometimes has effects and
>> sometimes not. So I would like to provide the app writer
>> the information that he did something wrong...
>>>>>
>>>>> Thus I think we did it that way in the "be liberal
>>>>> in what you accept tradition".. but it may be wrong :-D
>> I like that tradition, but I think "we work around your bug
>> most of the time" is not that helpful.
>>
>> If we would say, that we ignore the the port numbers in the
>> bindx() at all, that might be OK...
>>
>> On the other hand people are used to use port number 0 as
>> chose what you want, port number != 0 as use this one.
>> That was the reasoning to suggest the three rules...
>>>> Thinking as an app writer, I guess it is easier if a field
>>>> is not required, then it should be ignored.  What Randy
>>>> wrote originally is easier.
>>>>>> So what about:
>>>>>>
>>>>>> 1. allow bindx() after bind() or without bind().
>>>>> ok (we do this today as you know and I think linux does too
>>>>>     from Kacheong's email Solaris does NOT).
>>>> If this is allowed, then I guess the first element of
>>>> the sctp_bindx() address array becomes the significant
>>>> one.  This needs to be noted.
>>>>>> 2. if in bind() or bindx() any non-zero port number
>>>>>>    is used and checked. This allows explicit binding
>>>>>>    with bind() and bindx(). It required to use the
>>>>>>    same non-zero port number in all bindx() calls.
>>>>> ok
>>>> I assume the last sentence means that the caller can
>>>> just use 0 as the port number after the first address
>>>> element.  For example, the address array of sctp_bindx()
>>>> has two elements.  The first element has port number X.  It
>>>> means that the stack will try to bind to X.  The second
>>>> element can have a port number 0.  It is not required to
>>>> have X also.  This is probably implied in (3) below.
>>>
>>> Yep.. exactly..
>> Yes. You can have (only the port numbers are written):
>> 0, 0, 0, 0, 0, 0 -> OK.
>> p, 0, p, 0, p, 0 -> OK.
>> p, p, p, p, p, p -> OK.
>> p, q (with p > 0, p!=q) -> not OK.
>> I would always fail the call for
>> 0, p (p > 0)
>> even if the kernel choses by random the port number p...
>>>
>>> R
>>>>>> 3. If a zero port number is used the kernel will
>>>>>>    chose an ephemeral one if the socket is unbound
>>>>>>    or will use the already known one if the socket
>>>>>>    is bound.
>>>>> Ok
>>>
>>>
>>> -- 
>>> Randall Stewart
>>> NSSTG - Cisco Systems Inc.
>>> 803-345-0369 <or> 803-317-4952 (cell)
>>>
>>
> 
> 





From tsvwg-bounces@ietf.org Wed Apr 04 15:43:35 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZBNk-0004uh-7V; Wed, 04 Apr 2007 15:43:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBNi-0004ts-7R
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:42:58 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBKj-00079a-8e
	for tsvwg@ietf.org; Wed, 04 Apr 2007 15:39:54 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 04 Apr 2007 12:39:52 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l34Jdqbn016699; 
	Wed, 4 Apr 2007 12:39:52 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l34JdpEm021745;
	Wed, 4 Apr 2007 19:39:52 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 12:39:51 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 12:39:51 -0700
Message-ID: <4613FFB5.1060800@cisco.com>
Date: Wed, 04 Apr 2007 15:42:45 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Vlad Yasevich <vladislav.yasevich@hp.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
In-Reply-To: <4613FD6D.7040908@hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 19:39:51.0400 (UTC)
	FILETIME=[03112680:01C776F1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4124; t=1175715592;
	x=1176579592; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=DT/zlr5utVuxccUmkfA7jsCWHt3yyalImME4IzPfvpI=;
	b=r+HiB7VYpZB/R5un+01BRB1sq6QVSgAObhhvZ0+b532jvRJVy4VOhfyZQfzRhhXkPPMeqpWq
	G+YRwD3aWlaN6gTj0qyLtDdUWsQQo36Lsu2I6+ISy0vr1yqT1q+RFeZNm8JQiKHop48QDph+GM
	7EqFpr9Pfpq4fpkYw4JW9FDvw=;
Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

One other question..

Should we change it to use a true array
of

union struct sctp_sockstore's

Or whatever we call them?

I did teach a class on the socket api and this was
a complaint .. the students would rather have a
array of something like this union type..  Its smaller
and more compact...

Or do we just try to do something more like Kacheong is
proposing.. and get a generic bindx/connectx?

R

Vlad Yasevich wrote:
> Randall Stewart wrote:
>> Michael:
>>
>> I am fine with that.. as long as Kacheong and Vlad agree :-D
> 
> Yes, I agree as well.
> 
> -vlad
> 
>> R
>>
>> Michael Tuexen wrote:
>>> Randy,
>>>
>>> a comment in-line.
>>>
>>> Best regards
>>> Michael
>>>
>>> On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:
>>>
>>>> Kacheong Poon wrote:
>>>>> Randall Stewart wrote:
>>>>>> Michael Tuexen wrote:
>>>>>>> Randy,
>>>>>>>
>>>>>>> I'm not sure if it is a good idea to silently accept things
>>>>>>> from the user (x,y) which are wrong without complaining, just
>>>>>>> ignoring...
>>>>>> Yes.. I thought about that.. and it of course
>>>>>> depends... I can see someone really specifying
>>>>>> multiple ports in a bindx and thinking they could
>>>>>> do this.
>>>>>>
>>>>>> On the other hand, I can see people just forgetting
>>>>>> to 0 it out.. and leaving garbage in there..
>>> which also applies to the family field or length field...
>>> This might result in a bug which sometimes has effects and
>>> sometimes not. So I would like to provide the app writer
>>> the information that he did something wrong...
>>>>>> Thus I think we did it that way in the "be liberal
>>>>>> in what you accept tradition".. but it may be wrong :-D
>>> I like that tradition, but I think "we work around your bug
>>> most of the time" is not that helpful.
>>>
>>> If we would say, that we ignore the the port numbers in the
>>> bindx() at all, that might be OK...
>>>
>>> On the other hand people are used to use port number 0 as
>>> chose what you want, port number != 0 as use this one.
>>> That was the reasoning to suggest the three rules...
>>>>> Thinking as an app writer, I guess it is easier if a field
>>>>> is not required, then it should be ignored.  What Randy
>>>>> wrote originally is easier.
>>>>>>> So what about:
>>>>>>>
>>>>>>> 1. allow bindx() after bind() or without bind().
>>>>>> ok (we do this today as you know and I think linux does too
>>>>>>     from Kacheong's email Solaris does NOT).
>>>>> If this is allowed, then I guess the first element of
>>>>> the sctp_bindx() address array becomes the significant
>>>>> one.  This needs to be noted.
>>>>>>> 2. if in bind() or bindx() any non-zero port number
>>>>>>>    is used and checked. This allows explicit binding
>>>>>>>    with bind() and bindx(). It required to use the
>>>>>>>    same non-zero port number in all bindx() calls.
>>>>>> ok
>>>>> I assume the last sentence means that the caller can
>>>>> just use 0 as the port number after the first address
>>>>> element.  For example, the address array of sctp_bindx()
>>>>> has two elements.  The first element has port number X.  It
>>>>> means that the stack will try to bind to X.  The second
>>>>> element can have a port number 0.  It is not required to
>>>>> have X also.  This is probably implied in (3) below.
>>>> Yep.. exactly..
>>> Yes. You can have (only the port numbers are written):
>>> 0, 0, 0, 0, 0, 0 -> OK.
>>> p, 0, p, 0, p, 0 -> OK.
>>> p, p, p, p, p, p -> OK.
>>> p, q (with p > 0, p!=q) -> not OK.
>>> I would always fail the call for
>>> 0, p (p > 0)
>>> even if the kernel choses by random the port number p...
>>>> R
>>>>>>> 3. If a zero port number is used the kernel will
>>>>>>>    chose an ephemeral one if the socket is unbound
>>>>>>>    or will use the already known one if the socket
>>>>>>>    is bound.
>>>>>> Ok
>>>>
>>>> -- 
>>>> Randall Stewart
>>>> NSSTG - Cisco Systems Inc.
>>>> 803-345-0369 <or> 803-317-4952 (cell)
>>>>
>>
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 16:17:14 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZBtp-0000KY-Bn; Wed, 04 Apr 2007 16:16:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBtn-0000Jg-ES
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:16:07 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZBtk-0006yO-Nz
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:16:07 -0400
Received: from [192.168.1.2] (p508FC99D.dip.t-dialin.net [80.143.201.157])
	by mail-n.franken.de (Postfix) with ESMTP id E21E88006D8C;
	Wed,  4 Apr 2007 22:15:58 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <46140324.8090609@hp.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Wed, 4 Apr 2007 22:15:56 +0200
To: Vlad Yasevich <vladislav.yasevich@hp.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Randall Stewart <rrs@cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On Apr 4, 2007, at 9:57 PM, Vlad Yasevich wrote:

> Randall Stewart wrote:
>> One other question..
>>
>> Should we change it to use a true array
>> of
>>
>> union struct sctp_sockstore's
>>
>> Or whatever we call them?
>>
>> I did teach a class on the socket api and this was
>> a complaint .. the students would rather have a
>> array of something like this union type..  Its smaller
>> and more compact...
>>
>> Or do we just try to do something more like Kacheong is
>> proposing.. and get a generic bindx/connectx?
>
> I think changing this API is a bit late.  It would be really hard
> to update everyone in a backward compatible way.
>
> Also, I don't think the union is more compact.  For a purely
> IPv4 usage, it would waste space.  Having a union simply makes
> it easily addressable array vs. a list (really) built as contiguous
> memory array.
I agree. Currently we use something like a "packed array". Any
"non-packed" array will be larger...

I understand the students: they want to write a simple loop,
not looking at the size of each element...
If they want, they can this right now by using mapped IPv4 addresses.
>
> At this point, I think perusing a generic standard bindx() is a
> better option, but that will probably have to deal with some
> specific sockaddr structures as well.
So you are suggesting new (different names) bindx() and connectx()  
calls or
what do you mean by "generic standard"?
>
> -vlad
>
>
>>
>> R
>>
>> Vlad Yasevich wrote:
>>> Randall Stewart wrote:
>>>> Michael:
>>>>
>>>> I am fine with that.. as long as Kacheong and Vlad agree :-D
>>>
>>> Yes, I agree as well.
>>>
>>> -vlad
>>>
>>>> R
>>>>
>>>> Michael Tuexen wrote:
>>>>> Randy,
>>>>>
>>>>> a comment in-line.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>
>>>>> On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:
>>>>>
>>>>>> Kacheong Poon wrote:
>>>>>>> Randall Stewart wrote:
>>>>>>>> Michael Tuexen wrote:
>>>>>>>>> Randy,
>>>>>>>>>
>>>>>>>>> I'm not sure if it is a good idea to silently accept things
>>>>>>>>> from the user (x,y) which are wrong without complaining, just
>>>>>>>>> ignoring...
>>>>>>>> Yes.. I thought about that.. and it of course
>>>>>>>> depends... I can see someone really specifying
>>>>>>>> multiple ports in a bindx and thinking they could
>>>>>>>> do this.
>>>>>>>>
>>>>>>>> On the other hand, I can see people just forgetting
>>>>>>>> to 0 it out.. and leaving garbage in there..
>>>>> which also applies to the family field or length field...
>>>>> This might result in a bug which sometimes has effects and
>>>>> sometimes not. So I would like to provide the app writer
>>>>> the information that he did something wrong...
>>>>>>>> Thus I think we did it that way in the "be liberal
>>>>>>>> in what you accept tradition".. but it may be wrong :-D
>>>>> I like that tradition, but I think "we work around your bug
>>>>> most of the time" is not that helpful.
>>>>>
>>>>> If we would say, that we ignore the the port numbers in the
>>>>> bindx() at all, that might be OK...
>>>>>
>>>>> On the other hand people are used to use port number 0 as
>>>>> chose what you want, port number != 0 as use this one.
>>>>> That was the reasoning to suggest the three rules...
>>>>>>> Thinking as an app writer, I guess it is easier if a field
>>>>>>> is not required, then it should be ignored.  What Randy
>>>>>>> wrote originally is easier.
>>>>>>>>> So what about:
>>>>>>>>>
>>>>>>>>> 1. allow bindx() after bind() or without bind().
>>>>>>>> ok (we do this today as you know and I think linux does too
>>>>>>>>     from Kacheong's email Solaris does NOT).
>>>>>>> If this is allowed, then I guess the first element of
>>>>>>> the sctp_bindx() address array becomes the significant
>>>>>>> one.  This needs to be noted.
>>>>>>>>> 2. if in bind() or bindx() any non-zero port number
>>>>>>>>>    is used and checked. This allows explicit binding
>>>>>>>>>    with bind() and bindx(). It required to use the
>>>>>>>>>    same non-zero port number in all bindx() calls.
>>>>>>>> ok
>>>>>>> I assume the last sentence means that the caller can
>>>>>>> just use 0 as the port number after the first address
>>>>>>> element.  For example, the address array of sctp_bindx()
>>>>>>> has two elements.  The first element has port number X.  It
>>>>>>> means that the stack will try to bind to X.  The second
>>>>>>> element can have a port number 0.  It is not required to
>>>>>>> have X also.  This is probably implied in (3) below.
>>>>>> Yep.. exactly..
>>>>> Yes. You can have (only the port numbers are written):
>>>>> 0, 0, 0, 0, 0, 0 -> OK.
>>>>> p, 0, p, 0, p, 0 -> OK.
>>>>> p, p, p, p, p, p -> OK.
>>>>> p, q (with p > 0, p!=q) -> not OK.
>>>>> I would always fail the call for
>>>>> 0, p (p > 0)
>>>>> even if the kernel choses by random the port number p...
>>>>>> R
>>>>>>>>> 3. If a zero port number is used the kernel will
>>>>>>>>>    chose an ephemeral one if the socket is unbound
>>>>>>>>>    or will use the already known one if the socket
>>>>>>>>>    is bound.
>>>>>>>> Ok
>>>>>>
>>>>>> -- 
>>>>>> Randall Stewart
>>>>>> NSSTG - Cisco Systems Inc.
>>>>>> 803-345-0369 <or> 803-317-4952 (cell)
>>>>>>
>>>>
>>>
>>
>>
>
>





From tsvwg-bounces@ietf.org Wed Apr 04 16:21:03 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZByP-0001cx-1b; Wed, 04 Apr 2007 16:20:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZByN-0001cT-Gi
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:20:51 -0400
Received: from atlrel7.hp.com ([156.153.255.213])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZByL-0000Du-JD
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:20:51 -0400
Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.15.136.127])
	by atlrel7.hp.com (Postfix) with ESMTP id 08DA634435;
	Wed,  4 Apr 2007 15:57:25 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp1.fc.hp.com (Postfix) with ESMTP id 0999E1377E1;
	Wed,  4 Apr 2007 19:57:24 +0000 (UTC)
Message-ID: <46140324.8090609@hp.com>
Date: Wed, 04 Apr 2007 15:57:24 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com>
In-Reply-To: <4613FFB5.1060800@cisco.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> One other question..
> 
> Should we change it to use a true array
> of
> 
> union struct sctp_sockstore's
> 
> Or whatever we call them?
> 
> I did teach a class on the socket api and this was
> a complaint .. the students would rather have a
> array of something like this union type..  Its smaller
> and more compact...
> 
> Or do we just try to do something more like Kacheong is
> proposing.. and get a generic bindx/connectx?

I think changing this API is a bit late.  It would be really hard
to update everyone in a backward compatible way.

Also, I don't think the union is more compact.  For a purely
IPv4 usage, it would waste space.  Having a union simply makes
it easily addressable array vs. a list (really) built as contiguous
memory array.

At this point, I think perusing a generic standard bindx() is a
better option, but that will probably have to deal with some
specific sockaddr structures as well.

-vlad


> 
> R
> 
> Vlad Yasevich wrote:
>> Randall Stewart wrote:
>>> Michael:
>>>
>>> I am fine with that.. as long as Kacheong and Vlad agree :-D
>>
>> Yes, I agree as well.
>>
>> -vlad
>>
>>> R
>>>
>>> Michael Tuexen wrote:
>>>> Randy,
>>>>
>>>> a comment in-line.
>>>>
>>>> Best regards
>>>> Michael
>>>>
>>>> On Apr 4, 2007, at 8:00 PM, Randall Stewart wrote:
>>>>
>>>>> Kacheong Poon wrote:
>>>>>> Randall Stewart wrote:
>>>>>>> Michael Tuexen wrote:
>>>>>>>> Randy,
>>>>>>>>
>>>>>>>> I'm not sure if it is a good idea to silently accept things
>>>>>>>> from the user (x,y) which are wrong without complaining, just
>>>>>>>> ignoring...
>>>>>>> Yes.. I thought about that.. and it of course
>>>>>>> depends... I can see someone really specifying
>>>>>>> multiple ports in a bindx and thinking they could
>>>>>>> do this.
>>>>>>>
>>>>>>> On the other hand, I can see people just forgetting
>>>>>>> to 0 it out.. and leaving garbage in there..
>>>> which also applies to the family field or length field...
>>>> This might result in a bug which sometimes has effects and
>>>> sometimes not. So I would like to provide the app writer
>>>> the information that he did something wrong...
>>>>>>> Thus I think we did it that way in the "be liberal
>>>>>>> in what you accept tradition".. but it may be wrong :-D
>>>> I like that tradition, but I think "we work around your bug
>>>> most of the time" is not that helpful.
>>>>
>>>> If we would say, that we ignore the the port numbers in the
>>>> bindx() at all, that might be OK...
>>>>
>>>> On the other hand people are used to use port number 0 as
>>>> chose what you want, port number != 0 as use this one.
>>>> That was the reasoning to suggest the three rules...
>>>>>> Thinking as an app writer, I guess it is easier if a field
>>>>>> is not required, then it should be ignored.  What Randy
>>>>>> wrote originally is easier.
>>>>>>>> So what about:
>>>>>>>>
>>>>>>>> 1. allow bindx() after bind() or without bind().
>>>>>>> ok (we do this today as you know and I think linux does too
>>>>>>>     from Kacheong's email Solaris does NOT).
>>>>>> If this is allowed, then I guess the first element of
>>>>>> the sctp_bindx() address array becomes the significant
>>>>>> one.  This needs to be noted.
>>>>>>>> 2. if in bind() or bindx() any non-zero port number
>>>>>>>>    is used and checked. This allows explicit binding
>>>>>>>>    with bind() and bindx(). It required to use the
>>>>>>>>    same non-zero port number in all bindx() calls.
>>>>>>> ok
>>>>>> I assume the last sentence means that the caller can
>>>>>> just use 0 as the port number after the first address
>>>>>> element.  For example, the address array of sctp_bindx()
>>>>>> has two elements.  The first element has port number X.  It
>>>>>> means that the stack will try to bind to X.  The second
>>>>>> element can have a port number 0.  It is not required to
>>>>>> have X also.  This is probably implied in (3) below.
>>>>> Yep.. exactly..
>>>> Yes. You can have (only the port numbers are written):
>>>> 0, 0, 0, 0, 0, 0 -> OK.
>>>> p, 0, p, 0, p, 0 -> OK.
>>>> p, p, p, p, p, p -> OK.
>>>> p, q (with p > 0, p!=q) -> not OK.
>>>> I would always fail the call for
>>>> 0, p (p > 0)
>>>> even if the kernel choses by random the port number p...
>>>>> R
>>>>>>>> 3. If a zero port number is used the kernel will
>>>>>>>>    chose an ephemeral one if the socket is unbound
>>>>>>>>    or will use the already known one if the socket
>>>>>>>>    is bound.
>>>>>>> Ok
>>>>>
>>>>> -- 
>>>>> Randall Stewart
>>>>> NSSTG - Cisco Systems Inc.
>>>>> 803-345-0369 <or> 803-317-4952 (cell)
>>>>>
>>>
>>
> 
> 





From tsvwg-bounces@ietf.org Wed Apr 04 16:22:27 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZBzl-00023Z-2V; Wed, 04 Apr 2007 16:22:17 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBzi-00022p-VS
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:22:14 -0400
Received: from atlrel9.hp.com ([156.153.255.214])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZBzh-0006oz-Fo
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:22:14 -0400
Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114])
	by atlrel9.hp.com (Postfix) with ESMTP id C5598345E8;
	Wed,  4 Apr 2007 16:22:10 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp2.fc.hp.com (Postfix) with ESMTP id DCD251791D6;
	Wed,  4 Apr 2007 20:22:09 +0000 (UTC)
Message-ID: <461408F1.8080500@hp.com>
Date: Wed, 04 Apr 2007 16:22:09 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
In-Reply-To: <40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Randall Stewart <rrs@cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:
>>
>> At this point, I think perusing a generic standard bindx() is a
>> better option, but that will probably have to deal with some
>> specific sockaddr structures as well.
> So you are suggesting new (different names) bindx() and connectx() calls or
> what do you mean by "generic standard"?

I think Kacheong's idea of proposing a bindx() and connectx() API
for other socket types, not just SCTP, has merit, and I would
support that work faster then any changes to the sctp_bindx() or
sctp_connectx() api.

-vlad




From tsvwg-bounces@ietf.org Wed Apr 04 16:44:08 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZCKK-0007SA-NF; Wed, 04 Apr 2007 16:43:32 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCKJ-0007S5-Fj
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:43:31 -0400
Received: from atlrel7.hp.com ([156.153.255.213])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZCKI-0001Kc-3t
	for tsvwg@ietf.org; Wed, 04 Apr 2007 16:43:31 -0400
Received: from smtp1.fc.hp.com (smtp.fc.hp.com [15.15.136.127])
	by atlrel7.hp.com (Postfix) with ESMTP id E6F52342B6;
	Wed,  4 Apr 2007 16:43:28 -0400 (EDT)
Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226])
	by smtp1.fc.hp.com (Postfix) with ESMTP id 061661379E1;
	Wed,  4 Apr 2007 20:43:27 +0000 (UTC)
Message-ID: <46140DEF.7030302@hp.com>
Date: Wed, 04 Apr 2007 16:43:27 -0400
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
In-Reply-To: <AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Randall Stewart <rrs@cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:
> Which protocol could use connnectx()? Doesn't it require
> a transport protocol supporting multihoming. This would
> limit it to SCTP. bindx() however, could be used also by
> TCP and/or UDP.

I think the idea is to move the connect loop from the user app
into the API.  You pass the connectx() api a list of addresses
and it tries to connect to all the addresses you passed in.

This is just one scenario I can thing off.

-vlad

> 
> Best regards
> Michael
> 
> On Apr 4, 2007, at 10:22 PM, Vlad Yasevich wrote:
> 
>> Michael Tuexen wrote:
>>>>
>>>> At this point, I think perusing a generic standard bindx() is a
>>>> better option, but that will probably have to deal with some
>>>> specific sockaddr structures as well.
>>> So you are suggesting new (different names) bindx() and connectx()
>>> calls or
>>> what do you mean by "generic standard"?
>>
>> I think Kacheong's idea of proposing a bindx() and connectx() API
>> for other socket types, not just SCTP, has merit, and I would
>> support that work faster then any changes to the sctp_bindx() or
>> sctp_connectx() api.
>>
>> -vlad
>>
> 





From tsvwg-bounces@ietf.org Wed Apr 04 17:30:36 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZD2g-0004s4-IX; Wed, 04 Apr 2007 17:29:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD2e-0004ry-Q0
	for tsvwg@ietf.org; Wed, 04 Apr 2007 17:29:20 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZD2d-0008Uc-7w
	for tsvwg@ietf.org; Wed, 04 Apr 2007 17:29:20 -0400
Received: from [192.168.1.2] (p508FC99D.dip.t-dialin.net [80.143.201.157])
	by mail-n.franken.de (Postfix) with ESMTP id AA8CE808AB9F;
	Wed,  4 Apr 2007 22:30:38 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <461408F1.8080500@hp.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Wed, 4 Apr 2007 22:30:34 +0200
To: Vlad Yasevich <vladislav.yasevich@hp.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Randall Stewart <rrs@cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Which protocol could use connnectx()? Doesn't it require
a transport protocol supporting multihoming. This would
limit it to SCTP. bindx() however, could be used also by
TCP and/or UDP.

Best regards
Michael

On Apr 4, 2007, at 10:22 PM, Vlad Yasevich wrote:

> Michael Tuexen wrote:
>>>
>>> At this point, I think perusing a generic standard bindx() is a
>>> better option, but that will probably have to deal with some
>>> specific sockaddr structures as well.
>> So you are suggesting new (different names) bindx() and connectx()  
>> calls or
>> what do you mean by "generic standard"?
>
> I think Kacheong's idea of proposing a bindx() and connectx() API
> for other socket types, not just SCTP, has merit, and I would
> support that work faster then any changes to the sctp_bindx() or
> sctp_connectx() api.
>
> -vlad
>





From tsvwg-bounces@ietf.org Wed Apr 04 17:43:08 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZDFl-0007H1-Gt; Wed, 04 Apr 2007 17:42:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDFj-0007FG-Ia
	for tsvwg@ietf.org; Wed, 04 Apr 2007 17:42:51 -0400
Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDFg-0003XB-1j
	for tsvwg@ietf.org; Wed, 04 Apr 2007 17:42:51 -0400
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144])
	by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l34LfcR9009080;
	Wed, 4 Apr 2007 14:41:38 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by
	ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 14:41:38 -0700
Received: from [192.168.117.80] ([192.168.117.80]) by
	ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 14:41:38 -0700
In-Reply-To: <AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6EF1DC22-143D-4201-B957-A2AA18736960@windriver.com>
Content-Transfer-Encoding: 7bit
From: David Borman <david.borman@windriver.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Wed, 4 Apr 2007 16:41:37 -0500
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 04 Apr 2007 21:41:38.0169 (UTC)
	FILETIME=[063D9E90:01C77702]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: TSWG <tsvwg@ietf.org>, jan@newmarch.name,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

It depends on what semantics are assigned to it.  For example, as was  
stated, it could be used for TCP to have a series of choices for how  
to connect to the remote host, rather than doing a loop in user space  
trying to connect to each address one at a time.  I could even see it  
being an optimization for connection time, where a SYN gets sent to  
all the addresses at the same time; the first SYN/ACK back wins, and  
a RST is sent in response to any additional SYN/ACKs that come back.  
And if the list is only 1 long, then it should be obvious what TCP  
should do.

connectx() is for connecting to a multi-homed host, and it can make  
sense for initiating a TCP connection, just not in the same way as SCTP.

			-David Borman

On Apr 4, 2007, at 3:30 PM, Michael Tuexen wrote:

> Which protocol could use connnectx()? Doesn't it require
> a transport protocol supporting multihoming. This would
> limit it to SCTP. bindx() however, could be used also by
> TCP and/or UDP.
>
> Best regards
> Michael
>
> On Apr 4, 2007, at 10:22 PM, Vlad Yasevich wrote:
>
>> Michael Tuexen wrote:
>>>>
>>>> At this point, I think perusing a generic standard bindx() is a
>>>> better option, but that will probably have to deal with some
>>>> specific sockaddr structures as well.
>>> So you are suggesting new (different names) bindx() and connectx 
>>> () calls or
>>> what do you mean by "generic standard"?
>>
>> I think Kacheong's idea of proposing a bindx() and connectx() API
>> for other socket types, not just SCTP, has merit, and I would
>> support that work faster then any changes to the sctp_bindx() or
>> sctp_connectx() api.
>>
>> -vlad
>>
>





From tsvwg-bounces@ietf.org Wed Apr 04 19:38:33 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZF2P-0008OT-NQ; Wed, 04 Apr 2007 19:37:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZF2O-0008OI-5B
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:37:12 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZF2M-0001SB-4z
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:37:12 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 04 Apr 2007 16:37:09 -0700
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l34Nb97C007348; 
	Wed, 4 Apr 2007 16:37:09 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l34Nb6AA013807;
	Wed, 4 Apr 2007 23:37:07 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 16:37:06 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 16:37:05 -0700
Message-ID: <4614374F.8030607@cisco.com>
Date: Wed, 04 Apr 2007 19:39:59 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Vlad Yasevich <vladislav.yasevich@hp.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
In-Reply-To: <461408F1.8080500@hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 23:37:06.0134 (UTC)
	FILETIME=[27A12F60:01C77712]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=763; t=1175729829;
	x=1176593829; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=No+dB9mIFqImmOaz6v87wX4KtH1qHLFtcM2ZCSmNIe8=;
	b=ml8mkcOkyUWQcJ6hh5uBR8Fa36pZtVhF4OQZmmgBeRBlKPwoXsKIazb2/uNG0TmFcG6k18Vn
	VfcqGqQLzhHr05SbSsNWry1ZonaUiQWg1OsncPCqFkQpMlXdKjXmfh5N;
Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Vlad Yasevich wrote:
> Michael Tuexen wrote:
>>> At this point, I think perusing a generic standard bindx() is a
>>> better option, but that will probably have to deal with some
>>> specific sockaddr structures as well.
>> So you are suggesting new (different names) bindx() and connectx() calls or
>> what do you mean by "generic standard"?
> 
> I think Kacheong's idea of proposing a bindx() and connectx() API
> for other socket types, not just SCTP, has merit, and I would
> support that work faster then any changes to the sctp_bindx() or
> sctp_connectx() api.

I agree other than the 3 point clarification Michael made earlier

R
> 
> -vlad
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 19:38:42 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZF3q-0000XJ-T5; Wed, 04 Apr 2007 19:38:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZF3p-0000X8-8C
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:38:41 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZF3i-00026z-71
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:38:41 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 16:38:34 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l34NcX0V020231; 
	Wed, 4 Apr 2007 16:38:33 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l34NcKwx016913;
	Wed, 4 Apr 2007 23:38:33 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 16:38:30 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Apr 2007 16:38:30 -0700
Message-ID: <461437A3.9050309@cisco.com>
Date: Wed, 04 Apr 2007 19:41:23 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
In-Reply-To: <AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Apr 2007 23:38:30.0540 (UTC)
	FILETIME=[59F084C0:01C77712]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=633; t=1175729913;
	x=1176593913; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=gvNrebrAor3NRVmSe997KJcCjfL64w2p6Sd3g1bPnPs=;
	b=Stwhg5lR/SzjQKHs47oDnasVVY7phtsbRJcgNh2bpnDKZu/CWYnWdolj9biOWKODIm24UPT9
	LNx/nP9y0mhLNmby7qG0WnDEKu3J83M7HvoyR5IPKHcWIWAbdlSwMMIC;
Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:
> Which protocol could use connnectx()? Doesn't it require
> a transport protocol supporting multihoming. This would
> limit it to SCTP. bindx() however, could be used also by
> TCP and/or UDP.
> 

Actually TCP could use it.. imagine I get back
a list of IP addresses from DNS. I do a TCP
connectx().

Then when the SYN times out multiple times
I can try an alternate. I only keep the single
IP address that gets connected.. but it saves
some.

There was some talk about this on TSV a while ago.

R


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 04 19:49:19 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZFDs-0000Xc-JF; Wed, 04 Apr 2007 19:49:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFDQ-0000BB-7r
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:48:36 -0400
Received: from palrel10.hp.com ([156.153.255.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZF9Z-0005Ua-Jc
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:44:38 -0400
Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.56.217])
	by palrel10.hp.com (Postfix) with ESMTP id 43AF3343A5;
	Wed,  4 Apr 2007 16:44:36 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id
	QAA18768; Wed, 4 Apr 2007 16:44:35 -0700 (PDT)
Message-ID: <46143862.8080201@hp.com>
Date: Wed, 04 Apr 2007 16:44:34 -0700
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US;
	rv:1.7.13) Gecko/20060601
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613D887.1030303@sun.com>	<4613E7CE.2020407@cisco.com>	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>	<4613FBC7.3070406@cisco.com>
	<4613FD6D.7040908@hp.com>	<4613FFB5.1060800@cisco.com>
	<46140324.8090609@hp.com>	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>	<461408F1.8080500@hp.com>	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com>
In-Reply-To: <461437A3.9050309@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>,
	Michael Tuexen <Michael.Tuexen@micmac.franken.de>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> Michael Tuexen wrote:
> 
>> Which protocol could use connnectx()? Doesn't it require
>> a transport protocol supporting multihoming. This would
>> limit it to SCTP. bindx() however, could be used also by
>> TCP and/or UDP.
>>
> 
> Actually TCP could use it.. imagine I get back
> a list of IP addresses from DNS. I do a TCP
> connectx().
> 
> Then when the SYN times out multiple times
> I can try an alternate. I only keep the single
> IP address that gets connected.. but it saves
> some.

A leeeetle bit of application programming, but not really all that much? 
And if the application wanted to re-establish a session after a TCP 
connection failure, it would still want that initial list of IP's no?

Heck, if you are going to go ahead and give connectx() a list of IPs for 
TCP to try, why not just give it the hostname...

rick jones
mpg member of the peanut gallery




From tsvwg-bounces@ietf.org Wed Apr 04 19:58:46 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZFMq-0004bL-0U; Wed, 04 Apr 2007 19:58:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFMo-0004aY-L9
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:58:18 -0400
Received: from sccrmhc14.comcast.net ([63.240.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZFMl-0001lU-OO
	for tsvwg@ietf.org; Wed, 04 Apr 2007 19:58:18 -0400
Received: from [192.168.1.2]
	(c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72])
	by comcast.net (sccrmhc14) with SMTP
	id <200704042358140140028h8ge>; Wed, 4 Apr 2007 23:58:14 +0000
In-Reply-To: <OF2E61F8A8.969F7BBF-ON852572AB.005504C6-852572AC.0068C25D@csc.com>
References: <OF2E61F8A8.969F7BBF-ON852572AB.005504C6-852572AC.0068C25D@csc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-5--144603517
Message-Id: <FC50BC44-BDC9-4676-8941-5F379C618151@g11.org.uk>
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
Date: Wed, 4 Apr 2007 19:58:11 -0400
To: Janet P Gunn <jgunn6@csc.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-5--144603517
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

My apologies for the tardy response

> Just for the record,  I'd like to repeat a couple of my previous  
> comments, plus a couple of new ones.
>
> This ID discusses the relationship with the "higher level/  
> application level" SIP  protocol in call admission (especially in  
> relation to  the Resource Priority Header- RFC 4412).  I would like  
> to see a similar reference to the relationship to the new proposed  
> DSCP, EF-ADMIT (draft-ietf-tsvwg-admitted-realtime-dscp-00) .  As  
> calls admitted through the processes described in this ID WOULD be  
> subject to "strict CAC", they would be entitled to use of the EF- 
> ADMIT code point.  However, I understand that, since EF-ADMIT is  
> not yet an RFC, it is difficult to reference it directly.  It is  
> certainly not worth delaying this ID to wait for EF-ADMIT.  But if,  
> by some chance, EF-ADMIT reaches RFC status before this document,  
> perhaps a reference could be added. Or perhaps simply a reference  
> to the possibility of different DSCPs being used as a matter of  
> policy.

we have discussed this before on the list and I don't see anything  
that has changed.  we discuss a relationship with an upper layer  
protocol because of the information that can be extracted and placed  
in the policy element.  EF-Admit, or any other diff-serv code point,  
layered relationship and so should be out of scope of this draft.  In  
fact the recent change of the EF-Admit draft, the subsequent comments  
(with presumably more comments to come), keeps it as a moving target,  
and our draft is hopefully progressing to the next stage.  As before,  
I would suggest taking this request the authors of EF-admit and  
seeing if they would add it to their draft, or to come up with a  
separate draft.

> I am the one who suggested the Priority Bypass model.  But it is  
> really just a special case of the Russian Dolls model, with a very  
> big "outside" doll, so I would have no objections if someone wants  
> to remove it (no objections to leaving it, either).

more than one person has suggested the Priority Bypass Model, and  
since it is also distinctly different from the other models described  
in the appendix, we would prefer to keep it in.

> Some of the people who will be interested in the mechanisms  
> described here have a strong aversion to anything involving  
> preemption.  Therefore I would prefer to see a stronger distinction  
> between the preemption related mechanisms and the non-preemption  
> mechanisms.

I don't mean to be difficult, but I just don't see the same problem.   
I look at the places where we mention the word preemption and feel  
that the context is well stated.  I have asked someone else to review  
the draft and hope to hear another opinion from him about this  
matter.  Francois may want to put in his two cents as well.

> For instance, at the end of section 3.1 it says "The Admission  
> Priority and Preemption
>    Priority are handled by LPDPs and PEPs as orthogonal and  
> independent
>    mechanisms. "
> This is a bit of a cop out, as admission policy and preemption  
> policy cannot, in practice, be completely independent.  You can  
> have preemption without separate priority admission.  You can have  
> priority admission without preemption.

you've just lost me because as I read your last two sentences, they  
appear to contract your statement that they cannot be independent.

> But if you have both priority  admission, and preemption, you have  
> to define the interaction, if only which one is applied first.  
> (Appendix B, in fact, describes cases in which admission priority  
> is applied first, and preemption is only applied if admission  
> priority fails.  But other interactions are possible.)  Therefore  
> it would be more realistic to say that, if both are used, the  
> interaction is defined "by local policy, outside the scope of this  
> document".

what we can do in Appendix B is add that other interactions are  
possible.

> Nit-
> In 3.1.1, I don't quite understand what is meant by "Take priority  
> of highest QoS".  It seems to me that the set of all possible QoS  
> specifications is  a partially ordered set (POSET) rather than a  
> fully ordered set.  For instance,  QoS "A" may have stringent  
> requirements for packet dropping, but weak requirements for delay  
> and jitter.  But QoS "B" may have stringent requirements for delay  
> and jitter, but weaker requirements for packet dropping.  It is not  
> immediately obvious to me whether A or B is the "highest QoS".
>
> But the "Highest QoS"  concept is certainly not central to this  
> document, and perhaps it is addressed in detail somewhere else that  
> I have not come across.

Um, you are talking about two different Flowspecs to the degree of  
comparing apples and oranges....which would not be merged.

> Typo?-
> In the last paragraph of 3.2.1 it says:
> "A given ALRP MUST NOT appear more than
>        once. In other words, the outgoing ALRP List is the reunion of
>        the incoming ARLP Lists that are merged."
>
> I suspect that "reunion" is really supposed to be "union".
> I suspect "ARLP" is supposed to be "ALRP"
>
> There is also another place in 3.2 where it says "ARLP", but I  
> think it is supposed to be "ALRP".

thanks, that will be corrected.

> Appendix A
>
> This text appears a couple of times in Appendix A
> "In that case additional priority sessions could not be accepted. Note
>    that this does not mean that such calls are dropped altogether:  
> they
>    may be handled by mechanisms, which are beyond the scope of this
>    particular document (such as establishment through preemption of
>    existing non-priority sessions, or such as queuing of new priority
>    session requests until capacity becomes available again for  
> priority
>    traffic)."
>
> It seems to me that, in most cases, preemption is applied by one  
> priority call to OTHER priority calls (which have lower preemption  
> priority), rather than to "non-priority" calls.
>
> Conversely, since priority admission and preemption are "orthogonal  
> and independent", it might be that some of the calls which are "non- 
> priority calls" from an "admission priority" perspective could be  
> "high priority calls" form a "preemption " perspective.  Therefore  
> it would probably be better to say
> "(such as establishment through preemption of existing  sessions,...)"

well, the term "such as" was really meant to convey an example.  we  
can probably clear up the matter by switching "such as" with "for  
example", and state that other variations could exist.

> Appendix B
>
> grammar nit-
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and ensures  
> that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls::"
> is not quite grammatically correct.
>  It needs to be (Changes in CAPS)
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and WHICH  
> ensures that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls:"
> or
> "If one wants to implement an emergency service based on Call  
> Queueing,
>    on "prioritized access to network layer resources", and ENSURE   
> that
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions,  
> but
>    non-emergency sessions are not affected by preemption, one can do
>    that by signaling emergency calls:"

I'm sorry, but I don't see the difference nor the significance of  
capitalizing "ensure" in comparison to the original text.

> Choice of terms-
> Because the use of preemption is politically sensitive in a  
> significant part of the ETS community, I am quite uncomfortable  
> with the example of  "..an emergency service based on Call Queueing,
>    on "prioritized access to network layer resources", and ensure that
>    "emergency" sessions can preempt regular sessions,..."

just for future reference, but it would be helpful to identify the  
section/paragraph when you are taking selected quotes.  The text you  
refer to is Appendix B, 3'rd paragraph of page 27.

> Can we please call it something other than "an emergency service"?
> Otherwise I can see myself, over the next 10 years, having to  
> repeatedly explain that "No, the IETF is NOT saying that an  
> Emergency Service should use preemption".  I know it is only an  
> academic example, but it is going to make things a lot simpler, and  
> be a lot more understandable to that community, it the example is  
> called something else - possibly "a priority service" or   "a  
> precedence service".
>
>  Even if you decide you need to call it "an emergency service" for  
> reasons of consistency, just changing the name in the Preemption  
> Policy Element from "Emergency -1" and "Emergency-2" to something  
> else, such as "Preemption-1" and "Preemption-2" would make it  
> clearer, and help avoid such misunderstanding.

Again, I don't agree.  What you are asking is to cherry pick  
(selectively pick out) based on the constraints of one organization.   
And more importantly, you are speaking of the appendix, which is  
outside the main body of the document.  This document needs to be  
broader in perspective, otherwise it turns into an individually  
submitted draft for organization X.

About a year ago, the appendix was part of the main body, but under  
the suggestion of Allyson Mankin and agreed upon by consensus at one  
of the meetings, we agreed to keep the text (which is only  
informative in nature), and move it to the appendix....which has  
significance in RFCs.

I hope to hear from another reviewer about this.....um, Lou? :-)

-ken



--Apple-Mail-5--144603517
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">My apologies for the tardy =
response<DIV><BR><DIV><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">Just for the record, =A0I'd like to repeat a couple =
of my previous comments, plus a couple of new ones.</FONT> <BR> =
<BR><FONT size=3D"2" face=3D"sans-serif">This ID discusses the =
relationship with the "higher level/ application level" SIP =A0protocol =
in call admission (especially in relation to =A0the Resource Priority =
Header- RFC 4412). =A0I would like to see a similar reference to the =
relationship to the new proposed DSCP, EF-ADMIT =
(draft-ietf-tsvwg-admitted-realtime-dscp-00) . =A0As calls admitted =
through the processes described in this ID WOULD be subject to "strict =
CAC", they would be entitled to use of the EF-ADMIT code point. =
=A0However, I understand that, since EF-ADMIT is not yet an RFC, it is =
difficult to reference it directly. =A0It is certainly not worth =
delaying this ID to wait for EF-ADMIT. =A0But if, by some chance, =
EF-ADMIT reaches RFC status before this document, perhaps a reference =
could be added. Or perhaps simply a reference to the possibility of =
different DSCPs being used as a matter of policy.</FONT> =
<BR></BLOCKQUOTE><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>we =
have discussed this before on the list and I don't see anything that has =
changed.=A0 we discuss a relationship with an upper layer protocol =
because of the information that can be extracted and placed in the =
policy element.=A0 EF-Admit, or any other diff-serv code point, layered =
relationship and so should be out of scope of this draft.=A0 In fact the =
recent change of the EF-Admit draft, the subsequent comments (with =
presumably more comments to come), keeps it as a moving target, and our =
draft is hopefully progressing to the next stage.=A0 As before, I would =
suggest taking this request the authors of EF-admit and seeing if they =
would add it to their draft, or to come up with a separate =
draft.</DIV><BR><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">I am the one who suggested the Priority Bypass =
model. =A0But it is really just a special case of the Russian Dolls =
model, with a very big "outside" doll, so I would have no objections if =
someone wants to remove it (no objections to leaving it, =
either).</FONT>=A0<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>more than one person has =
suggested the Priority Bypass Model, and since it is also distinctly =
different from the other models described in the appendix, we would =
prefer to keep it in.</DIV><BR><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">Some of the people who will be interested in the =
mechanisms described here have a strong aversion to anything involving =
preemption. =A0Therefore I would prefer to see a stronger distinction =
between the preemption related mechanisms and the non-preemption =
mechanisms. =A0</FONT>=A0<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I don't mean to be =
difficult, but I just don't see the same problem.=A0 I look at the =
places where we mention the word preemption and feel that the context is =
well stated.=A0 I have asked someone else to review the draft and hope =
to hear another opinion from him about this matter.=A0 Francois may want =
to put in his two cents as well.</DIV><BR><BLOCKQUOTE type=3D"cite"><FONT =
size=3D"2" face=3D"sans-serif">For instance, at the end of section 3.1 =
it says "The Admission Priority and Preemption </FONT> <BR><FONT =
size=3D"2" face=3D"sans-serif">=A0 =A0Priority are handled by LPDPs and =
PEPs as orthogonal and independent </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0mechanisms. "</FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">This is a bit of a cop out, as admission policy and =
preemption policy cannot, in practice, be completely independent. =A0You =
can have preemption without separate priority admission. =A0You can have =
priority admission without preemption. =A0<BR></FONT></BLOCKQUOTE><DIV><BR=
 class=3D"khtml-block-placeholder"></DIV><DIV>you've just lost me =
because as I read your last two sentences, they appear to contract your =
statement that they cannot be independent.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><FONT size=3D"2" face=3D"sans-serif">But if you have both =
priority =A0admission, and preemption, you have to define the =
interaction, if only which one is applied first. (Appendix B, in fact, =
describes cases in which admission priority is applied first, and =
preemption is only applied if admission priority fails. =A0But other =
interactions are possible.) =A0Therefore it would be more realistic to =
say that, if both are used, the interaction is defined "by local policy, =
outside the scope of this document".</FONT><BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>what we can do in Appendix =
B is add that other interactions are possible.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><FONT size=3D"2" face=3D"sans-serif">Nit-</FONT> <BR><FONT =
size=3D"2" face=3D"sans-serif">In 3.1.1, I don't quite understand what =
is meant by "Take priority of highest QoS". =A0It seems to me that the =
set of all possible QoS specifications is =A0a partially ordered set =
(POSET) rather than a fully ordered set. =A0For instance, =A0QoS "A" may =
have stringent requirements for packet dropping, but weak requirements =
for delay and jitter. =A0But QoS "B" may have stringent requirements for =
delay and jitter, but weaker requirements for packet dropping. =A0It is =
not immediately obvious to me whether A or B is the "highest QoS". =
=A0</FONT> <BR> <BR><FONT size=3D"2" face=3D"sans-serif">But the =
"Highest QoS" =A0concept is certainly not central to this document, and =
perhaps it is addressed in detail somewhere else that I have not come =
across.</FONT> <BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Um, you are talking about =
two different Flowspecs to the degree of comparing apples and =
oranges....which would not be merged.</DIV><BR><BLOCKQUOTE =
type=3D"cite"><FONT size=3D"2" face=3D"sans-serif">Typo?-</FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">In the last paragraph of 3.2.1 =
it says:</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">"A given ALRP =
MUST NOT appear more than </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0 =A0 =A0once. In other words, the outgoing =
ALRP List is the reunion of </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0 =A0 =A0the incoming ARLP Lists that are =
merged."</FONT> <BR> <BR><FONT size=3D"2" face=3D"sans-serif">I suspect =
that "reunion" is really supposed to be "union".</FONT> <BR><FONT =
size=3D"2" face=3D"sans-serif">I suspect "ARLP" is supposed to be =
"ALRP"</FONT> <BR> <BR><FONT size=3D"2" face=3D"sans-serif">There is =
also another place in 3.2 where it says "ARLP", but I think it is =
supposed to be "ALRP".</FONT>=A0<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>thanks, that will be =
corrected.</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">Appendix A</FONT> <BR> <BR><FONT size=3D"2" =
face=3D"sans-serif">This text appears a couple of times in Appendix =
A</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">"In that case =
additional priority sessions could not be accepted. Note </FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0that this does not mean =
that such calls are dropped altogether: they </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0may be handled by mechanisms, which are =
beyond the scope of this </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0particular document (such as establishment =
through preemption of </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0=
 =A0existing non-priority sessions, or such as queuing of new priority =
</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0session requests =
until capacity becomes available again for priority </FONT> <BR><FONT =
size=3D"2" face=3D"sans-serif">=A0 =A0traffic)."</FONT> <BR> <BR><FONT =
size=3D"2" face=3D"sans-serif">It seems to me that, in most cases, =
preemption is applied by one priority call to OTHER priority calls =
(which have lower preemption priority), rather than to "non-priority" =
calls.</FONT> <BR> <BR><FONT size=3D"2" face=3D"sans-serif">Conversely, =
since priority admission and preemption are "orthogonal and =
independent", it might be that some of the calls which are "non-priority =
calls" from an "admission priority" perspective could be "high priority =
calls" form a "preemption " perspective. =A0Therefore it would probably =
be better to say </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">"(such =
as establishment through preemption of existing =
=A0sessions,...)"</FONT>=A0<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>well, the term "such as" was =
really meant to convey an example.=A0 we can probably clear up the =
matter by switching "such as" with "for example", and state that other =
variations could exist.</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><FONT =
size=3D"2" face=3D"sans-serif">Appendix B</FONT> <BR> <BR><FONT size=3D"2"=
 face=3D"sans-serif">grammar nit-</FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">"If one wants to implement an emergency service =
based on Call Queueing, </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0=
 =A0on "prioritized access to network layer resources", and ensures that =
</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0(say) =
"Emergency-1" sessions can preempt "Emergency-2" sessions, but </FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0non-emergency sessions =
are not affected by preemption, one can do </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0that by signaling emergency calls::"</FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">is not quite grammatically =
correct. </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0It needs to =
be (Changes in CAPS)</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">"If =
one wants to implement an emergency service based on Call Queueing, =
</FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0on "prioritized =
access to network layer resources", and WHICH ensures that </FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0(say) "Emergency-1" =
sessions can preempt "Emergency-2" sessions, but </FONT> <BR><FONT =
size=3D"2" face=3D"sans-serif">=A0 =A0non-emergency sessions are not =
affected by preemption, one can do </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0that by signaling emergency calls:"</FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">or </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">"If one wants to implement an emergency service =
based on Call Queueing, </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0=
 =A0on "prioritized access to network layer resources", and ENSURE =A0that=
 </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0(say) =
"Emergency-1" sessions can preempt "Emergency-2" sessions, but </FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0non-emergency sessions =
are not affected by preemption, one can do </FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">=A0 =A0that by signaling emergency calls:"</FONT> =
<BR></BLOCKQUOTE><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>I'm=
 sorry, but I don't see the difference nor the significance of =
capitalizing "ensure" in comparison to the original =
text.</DIV><BR><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">Choice of terms-</FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">Because the use of preemption is politically =
sensitive in a significant part of the ETS community, I am quite =
uncomfortable with the example of =A0"..an emergency service based on =
Call Queueing, </FONT> <BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0on =
"prioritized access to network layer resources", and ensure that </FONT> =
<BR><FONT size=3D"2" face=3D"sans-serif">=A0 =A0"emergency" sessions can =
preempt regular sessions,..." =A0</FONT>=A0<BR></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>just for future reference, =
but it would be helpful to identify the section/paragraph when you are =
taking selected quotes.=A0 The text you refer to is Appendix B, 3'rd =
paragraph of page 27.</DIV><BR><BLOCKQUOTE type=3D"cite"><FONT size=3D"2" =
face=3D"sans-serif">Can we please call it something other than "an =
emergency service"? =A0</FONT> <BR><FONT size=3D"2" =
face=3D"sans-serif">Otherwise I can see myself, over the next 10 years, =
having to repeatedly explain that "No, the IETF is NOT saying that an =
Emergency Service should use preemption". =A0I know it is only an =
academic example, but it is going to make things a lot simpler, and be a =
lot more understandable to that community, it the example is called =
something else - possibly "a priority service" or =A0 "a precedence =
service". </FONT> <BR> <BR><FONT size=3D"2" face=3D"sans-serif">=A0Even =
if you decide you need to call it "an emergency service" for reasons of =
consistency, just changing the name in the Preemption Policy Element =
from "Emergency -1" and "Emergency-2" to something else, such as =
"Preemption-1" and "Preemption-2" would make it clearer, and help avoid =
such misunderstanding.</FONT>=A0<BR =
class=3D"khtml-block-placeholder"></BLOCKQUOTE><BR></DIV><DIV>Again, I =
don't agree.=A0 What you are asking is to cherry pick (selectively pick =
out) based on the constraints of one organization.=A0 And more =
importantly, you are speaking of the appendix, which is outside the main =
body of the document.=A0 This document needs to be broader in =
perspective, otherwise it turns into an individually submitted draft for =
organization X.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>About a year ago, the =
appendix was part of the main body, but under the suggestion of Allyson =
Mankin and agreed upon by consensus at one of the meetings, we agreed to =
keep the text (which is only informative in nature), and move it to the =
appendix....which has significance in RFCs.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I hope to hear from another =
reviewer about this.....um, Lou? :-)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>-ken</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-5--144603517--




From tsvwg-bounces@ietf.org Wed Apr 04 21:04:16 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZGNT-00050n-H4; Wed, 04 Apr 2007 21:03:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGNS-00050i-PH
	for tsvwg@ietf.org; Wed, 04 Apr 2007 21:03:02 -0400
Received: from amer-mta07.csc.com ([20.137.52.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGNS-0000DM-9v
	for tsvwg@ietf.org; Wed, 04 Apr 2007 21:03:02 -0400
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	l3512lAE015646; Wed, 4 Apr 2007 21:02:56 -0400 (EDT)
In-Reply-To: <FC50BC44-BDC9-4676-8941-5F379C618151@g11.org.uk>
To: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF70F734C1.557420EE-ON852572B4.0004D8D5-852572B4.0005C17E@csc.com>
Date: Wed, 4 Apr 2007 21:02:50 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF16|January 29, 2007) at 04/04/2007 09:01:41 PM,
	Serialize complete at 04/04/2007 09:01:41 PM
Content-Type: multipart/alternative;
	boundary="=_alternative 0005C0AD852572B4_="
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is a multipart message in MIME format.
--=_alternative 0005C0AD852572B4_=
Content-Type: text/plain; charset="US-ASCII"

In line.


ken carlberg <carlberg@g11.org.uk> wrote on 04/04/2007 07:58:11 PM:

> My apologies for the tardy response
> 
> 
> For instance, at the end of section 3.1 it says "The Admission 
> Priority and Preemption 
>    Priority are handled by LPDPs and PEPs as orthogonal and independent 
>    mechanisms. " 
> This is a bit of a cop out, as admission policy and preemption 
> policy cannot, in practice, be completely independent.  You can have
> preemption without separate priority admission.  You can have 
> priority admission without preemption.  
> 
> you've just lost me because as I read your last two sentences, they 
> appear to contract your statement that they cannot be independent.
> 

I guess I wasn't clear enough. 

They ARE independent in the sense that you can have one without.

But they are NOT independent in the sense that, if you have both, there is 
an interaction between them (for instance which is applied first).

> But if you have both priority  admission, and preemption, you have 
> to define the interaction, if only which one is applied first. 
> (Appendix B, in fact, describes cases in which admission priority is
> applied first, and preemption is only applied if admission priority 
> fails.  But other interactions are possible.)  Therefore it would be
> more realistic to say that, if both are used, the interaction is 
> defined "by local policy, outside the scope of this document".
> 
> what we can do in Appendix B is add that other interactions are 
possible.
> 
Works for me.
> 
> Appendix A 
> 
> This text appears a couple of times in Appendix A 
> "In that case additional priority sessions could not be accepted. Note 
>    that this does not mean that such calls are dropped altogether: they 
>    may be handled by mechanisms, which are beyond the scope of this 
>    particular document (such as establishment through preemption of 
>    existing non-priority sessions, or such as queuing of new priority 
>    session requests until capacity becomes available again for priority 
>    traffic)." 
> 
> It seems to me that, in most cases, preemption is applied by one 
> priority call to OTHER priority calls (which have lower preemption 
> priority), rather than to "non-priority" calls. 
> 
> Conversely, since priority admission and preemption are "orthogonal 
> and independent", it might be that some of the calls which are "non-
> priority calls" from an "admission priority" perspective could be 
> "high priority calls" form a "preemption " perspective.  Therefore 
> it would probably be better to say 
> "(such as establishment through preemption of existing  sessions,...)" 
> 
> well, the term "such as" was really meant to convey an example.  we 
> can probably clear up the matter by switching "such as" with "for 
> example", and state that other variations could exist.
> 
Works for me

> Appendix B 
> 
> grammar nit- 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and ensures that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 
>    non-emergency sessions are not affected by preemption, one can do 
>    that by signaling emergency calls::" 
> is not quite grammatically correct. 
>  It needs to be (Changes in CAPS) 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and WHICH ensures 
that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 
>    non-emergency sessions are not affected by preemption, one can do 
>    that by signaling emergency calls:" 
> or 
> "If one wants to implement an emergency service based on Call Queueing, 
>    on "prioritized access to network layer resources", and ENSURE  that 
>    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 
>    non-emergency sessions are not affected by preemption, one can do 
>    that by signaling emergency calls:" 
> 
> I'm sorry, but I don't see the difference nor the significance of 
> capitalizing "ensure" in comparison to the original text.

Again, I wasn't clear.  It is simply a question of subject - verb 
agreement
"If one wants to ... ensure"
not 
"If one wants to ... ensures"

> 
> -ken

The rest of your responses are fine with me.

Janet
--=_alternative 0005C0AD852572B4_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
<br>
In line.<br>
</font>
<br>
<br><font size=2><tt>ken carlberg &lt;carlberg@g11.org.uk&gt; wrote on
04/04/2007 07:58:11 PM:<br>
<br>
&gt; My apologies for the tardy response</tt></font>
<br><font size=2><tt>&gt; &nbsp;</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; For instance, at the end of section 3.1 it says &quot;The Admission
<br>
&gt; Priority and Preemption <br>
&gt; &nbsp; &nbsp;Priority are handled by LPDPs and PEPs as orthogonal
and independent <br>
&gt; &nbsp; &nbsp;mechanisms. &quot; <br>
&gt; This is a bit of a cop out, as admission policy and preemption <br>
&gt; policy cannot, in practice, be completely independent. &nbsp;You can
have<br>
&gt; preemption without separate priority admission. &nbsp;You can have
<br>
&gt; priority admission without preemption. &nbsp;</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; you've just lost me because as I read your last two sentences, they
<br>
&gt; appear to contract your statement that they cannot be independent.</tt></font>
<br><font size=2><tt>&gt; </tt></font>
<br>
<br><font size=2><tt>I guess I wasn't clear enough. &nbsp;</tt></font>
<br>
<br><font size=2><tt>They ARE independent in the sense that you can have
one without.</tt></font>
<br>
<br><font size=2><tt>But they are NOT independent in the sense that, if
you have both, there is an interaction between them (for instance which
is applied first).</tt></font>
<br><font size=2><tt><br>
&gt; But if you have both priority &nbsp;admission, and preemption, you
have <br>
&gt; to define the interaction, if only which one is applied first. <br>
&gt; (Appendix B, in fact, describes cases in which admission priority
is<br>
&gt; applied first, and preemption is only applied if admission priority
<br>
&gt; fails. &nbsp;But other interactions are possible.) &nbsp;Therefore
it would be<br>
&gt; more realistic to say that, if both are used, the interaction is <br>
&gt; defined &quot;by local policy, outside the scope of this document&quot;.</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; what we can do in Appendix B is add that other interactions are possible.</tt></font>
<br><font size=2><tt>&gt; </tt></font>
<br><font size=2><tt>Works for me.</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Appendix A <br>
&gt; <br>
&gt; This text appears a couple of times in Appendix A <br>
&gt; &quot;In that case additional priority sessions could not be accepted.
Note <br>
&gt; &nbsp; &nbsp;that this does not mean that such calls are dropped altogether:
they <br>
&gt; &nbsp; &nbsp;may be handled by mechanisms, which are beyond the scope
of this <br>
&gt; &nbsp; &nbsp;particular document (such as establishment through preemption
of <br>
&gt; &nbsp; &nbsp;existing non-priority sessions, or such as queuing of
new priority <br>
&gt; &nbsp; &nbsp;session requests until capacity becomes available again
for priority <br>
&gt; &nbsp; &nbsp;traffic).&quot; <br>
&gt; <br>
&gt; It seems to me that, in most cases, preemption is applied by one <br>
&gt; priority call to OTHER priority calls (which have lower preemption
<br>
&gt; priority), rather than to &quot;non-priority&quot; calls. <br>
&gt; <br>
&gt; Conversely, since priority admission and preemption are &quot;orthogonal
<br>
&gt; and independent&quot;, it might be that some of the calls which are
&quot;non-<br>
&gt; priority calls&quot; from an &quot;admission priority&quot; perspective
could be <br>
&gt; &quot;high priority calls&quot; form a &quot;preemption &quot; perspective.
&nbsp;Therefore <br>
&gt; it would probably be better to say <br>
&gt; &quot;(such as establishment through preemption of existing &nbsp;sessions,...)&quot;&nbsp;</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; well, the term &quot;such as&quot; was really meant to convey an example.&nbsp;
we <br>
&gt; can probably clear up the matter by switching &quot;such as&quot;
with &quot;for <br>
&gt; example&quot;, and state that other variations could exist.</tt></font>
<br><font size=2><tt>&gt; </tt></font>
<br><font size=2><tt>Works for me</tt></font>
<br><font size=2><tt><br>
&gt; Appendix B <br>
&gt; <br>
&gt; grammar nit- <br>
&gt; &quot;If one wants to implement an emergency service based on Call
Queueing, <br>
&gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and ensures that <br>
&gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt &quot;Emergency-2&quot;
sessions, but <br>
&gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &nbsp; &nbsp;that by signaling emergency calls::&quot; <br>
&gt; is not quite grammatically correct. <br>
&gt; &nbsp;It needs to be (Changes in CAPS) <br>
&gt; &quot;If one wants to implement an emergency service based on Call
Queueing, <br>
&gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and WHICH ensures that <br>
&gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt &quot;Emergency-2&quot;
sessions, but <br>
&gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &nbsp; &nbsp;that by signaling emergency calls:&quot; <br>
&gt; or <br>
&gt; &quot;If one wants to implement an emergency service based on Call
Queueing, <br>
&gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and ENSURE &nbsp;that <br>
&gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt &quot;Emergency-2&quot;
sessions, but <br>
&gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &nbsp; &nbsp;that by signaling emergency calls:&quot; </tt></font>
<br><font size=2><tt>&gt; <br>
&gt; I'm sorry, but I don't see the difference nor the significance of
<br>
&gt; capitalizing &quot;ensure&quot; in comparison to the original text.</tt></font>
<br>
<br><font size=2><tt>Again, I wasn't clear. &nbsp;It is simply a question
of subject - verb agreement</tt></font>
<br><font size=2><tt>&quot;If one wants to ... ensure&quot;</tt></font>
<br><font size=2><tt>not </tt></font>
<br><font size=2><tt>&quot;If one wants to ... ensures&quot;</tt></font>
<br>
<br><font size=2><tt>&gt; <br>
&gt; -ken</tt></font>
<br>
<br><font size=2><tt>The rest of your responses are fine with me.</tt></font>
<br>
<br><font size=2><tt>Janet</tt></font>
--=_alternative 0005C0AD852572B4_=--




From tsvwg-bounces@ietf.org Wed Apr 04 21:13:32 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZGXN-00084k-Dq; Wed, 04 Apr 2007 21:13:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGXM-00084f-UQ
	for tsvwg@ietf.org; Wed, 04 Apr 2007 21:13:16 -0400
Received: from smtp109.sbc.mail.re2.yahoo.com ([68.142.229.96])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZGXK-0001Tv-Lw
	for tsvwg@ietf.org; Wed, 04 Apr 2007 21:13:16 -0400
Received: (qmail 78273 invoked from network); 5 Apr 2007 01:13:14 -0000
Received: from unknown (HELO ?192.168.1.7?)
	(janaiyengar@sbcglobal.net@76.210.250.225 with plain)
	by smtp109.sbc.mail.re2.yahoo.com with SMTP; 5 Apr 2007 01:13:14 -0000
X-YMail-OSG: aAnanHwVM1momVOwFjSXLa2MCFu9u0phXYMibX0klH5L6W5B2auXuKPeYTAnQD9YYbDc0.kw9hck7Uv7UjoteVGSZCmd3oXkRJXqa9e2A0bERZ379Lc-
Message-ID: <46144D27.7040603@mail.eecis.udel.edu>
Date: Wed, 04 Apr 2007 21:13:11 -0400
From: Janardhan Iyengar <iyengar@mail.eecis.udel.edu>
Organization: University of Delaware
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613D887.1030303@sun.com>	<4613E7CE.2020407@cisco.com>	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>	<4613FBC7.3070406@cisco.com>
	<4613FD6D.7040908@hp.com>	<4613FFB5.1060800@cisco.com>
	<46140324.8090609@hp.com>	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>	<461408F1.8080500@hp.com>	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com>
In-Reply-To: <461437A3.9050309@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>,
	Michael Tuexen <Michael.Tuexen@micmac.franken.de>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iyengar@cis.udel.edu
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

bindx() seems to make sense in the TCP/UDP context. I am still not sure 
about connectx() for TCP, but I know DCCP supports multihoming to some 
extent. Can connectx() be used for DCCP?

- jana

Randall Stewart wrote:
> Michael Tuexen wrote:
>> Which protocol could use connnectx()? Doesn't it require
>> a transport protocol supporting multihoming. This would
>> limit it to SCTP. bindx() however, could be used also by
>> TCP and/or UDP.
>>
> 
> Actually TCP could use it.. imagine I get back
> a list of IP addresses from DNS. I do a TCP
> connectx().
> 
> Then when the SYN times out multiple times
> I can try an alternate. I only keep the single
> IP address that gets connected.. but it saves
> some.
> 
> There was some talk about this on TSV a while ago.
> 
> R
> 
> 

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/




From tsvwg-bounces@ietf.org Thu Apr 05 03:54:25 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZMly-00033r-Bi; Thu, 05 Apr 2007 03:52:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMlx-00033i-Tx
	for tsvwg@ietf.org; Thu, 05 Apr 2007 03:52:45 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZMlw-00026D-BX
	for tsvwg@ietf.org; Thu, 05 Apr 2007 03:52:45 -0400
Received: from [192.168.1.2] (p508ff164.dip.t-dialin.net [80.143.241.100])
	by mail-n.franken.de (Postfix) with ESMTP id 0358B8000094;
	Thu,  5 Apr 2007 09:52:15 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <46143862.8080201@hp.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613D887.1030303@sun.com>	<4613E7CE.2020407@cisco.com>	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>	<4613FBC7.3070406@cisco.com>
	<4613FD6D.7040908@hp.com>	<4613FFB5.1060800@cisco.com>
	<46140324.8090609@hp.com>	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>	<461408F1.8080500@hp.com>	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Thu, 5 Apr 2007 09:52:12 +0200
To: Rick Jones <rick.jones2@hp.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: TSWG <tsvwg@ietf.org>, jan@newmarch.name,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On Apr 5, 2007, at 1:44 AM, Rick Jones wrote:

> Randall Stewart wrote:
>> Michael Tuexen wrote:
>>> Which protocol could use connnectx()? Doesn't it require
>>> a transport protocol supporting multihoming. This would
>>> limit it to SCTP. bindx() however, could be used also by
>>> TCP and/or UDP.
>>>
>> Actually TCP could use it.. imagine I get back
>> a list of IP addresses from DNS. I do a TCP
>> connectx().
>> Then when the SYN times out multiple times
>> I can try an alternate. I only keep the single
>> IP address that gets connected.. but it saves
>> some.
>
> A leeeetle bit of application programming, but not really all that  
> much? And if the application wanted to re-establish a session after  
> a TCP connection failure, it would still want that initial list of  
> IP's no?
>
> Heck, if you are going to go ahead and give connectx() a list of  
> IPs for TCP to try, why not just give it the hostname...
The problem with hostname is that you have no indication in the DNS  
whether the IP addresses
belong to the same host or not. For SCTP this is crucial, all  
addresses must belong to the
same host.

So one one has to restrict the list of IP-addresses to belong to the  
same host.
Assume that you send out two SYSs, one to address A, one to address  
B. Now you
get back a RST from A. Do you fail the connectx() call?
>
> rick jones
> mpg member of the peanut gallery
>





From tsvwg-bounces@ietf.org Thu Apr 05 05:00:35 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZNoP-0005y4-0y; Thu, 05 Apr 2007 04:59:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNoN-0005wm-JR
	for tsvwg@ietf.org; Thu, 05 Apr 2007 04:59:19 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZNoK-0000jB-2N
	for tsvwg@ietf.org; Thu, 05 Apr 2007 04:59:19 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 05 Apr 2007 10:59:16 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l358xFjx011680; 
	Thu, 5 Apr 2007 10:59:15 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com
	[144.254.231.87])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l358wsll022104; 
	Thu, 5 Apr 2007 08:59:11 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by
	xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 10:59:01 +0200
Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 10:58:57 +0200
In-Reply-To: <5o6afq$43psnc@sj-inbound-e.cisco.com>
References: <5o6afq$43psnc@sj-inbound-e.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <212318B4-4ABB-489B-A0B7-4794F2A97340@cisco.com>
Content-Transfer-Encoding: 7bit
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Date: Thu, 5 Apr 2007 10:56:40 +0200
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 05 Apr 2007 08:58:57.0863 (UTC)
	FILETIME=[A562CD70:01C77760]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4269; t=1175763555;
	x=1176627555; c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=flefauch@cisco.com;
	z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco.com>
	|Subject:=20Re=3A=20some=20comments=20on=20draft-ietf-tsvwg-rsvp-proxy-ap
	proaches-00.txt=20 |Sender:=20;
	bh=sREvPDIivlRv/IvZ9bN/Xhv7qrFsAMuCxdQljPSZc7o=;
	b=idt/YXnRVYCskN8WLvBb12TBldixmJT+jnvRmlR6x+dPPFfDsu8gF8FWRjcVG5NsNUnic+6M
	A+O4WxWCsvqo+JAtTw5+NNc53xu5WUd2XjYRU3UVG1EYa0ScBQNBJX7G;
Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: allan.guillou@neufcegetl.fr, jmanner@cs.helsinki.fi, dwing@cisco.com,
	tsvwg@ietf.org
Subject: [Tsvwg] Re: some comments on
	draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hello Lou,

I agree with all your points.

To reflect those in the next rev, I would propose that:
	* we use your diagram below instead of the current diagrams in 4.5  
(ie show "App Signaling entity" instead of "SIP/SBE" + formalize the  
Proxy control interface)
	* we describe the case where the "App entity" is colocated with the  
"RSVP Proxy" (what was illustrated  in Figure 9) only as a  
"particular case" of the more general case. Today we first talk about  
the particular case and then describe the more general case.
	* we add some words about the App Sig<-->RSVP-Proxy interface and  
what example protocols could be used (as you do below) and state  
definition of that interface is outside the scope of this document.  
(we could progress this separately though).
	* we move back into 4.5 the case currently described in 4.6 and  
describe it as another particular case of the more general case where  
the "App-Sig<-->RSVP-Proxy" interface happens to be "RSVP over GRE"

Does that work?
If yes, i'll try draft some text for review.

Thanks

Francois

On 30 Mar 2007, at 21:47, Lou Berger wrote:

> Francois, Jukka, Dan, Allan,
>
> I think there is an additional scenario that you probably intend to  
> allow, but isn't explicitly covered in the document.  The scenario  
> is similar to what is presented in section  4.4, 4.5, and 4.6 but  
> differs in a few of the specifics. I think the scenario could be  
> integrated into the existing sections or added as it's own.
>
> The scenario can be represented by the following:
>
>
>                     |-------------|      |-------------|
>                     | Application |      | Application |
>                 ____| Signaling   |______| Signaling   |__
>                /    | Entity      |      | Entity      |  \
>               /     |-------------|      |-------------|   \
>              /        //                       \\           \
>             /        //                         \\           \
>            /        //                           \\           \
>           /        //                             \\           \
>          /        //                               \\           \
>         /        //                                 \\           \
>        /    |--------|                         |--------|         \
>   |----|    | RSVP   |   ***    ***     ***    | RSVP   |         
> |----|
>   | S  |----| Sender |---*r*----*r*-----*r*----|Receiver|--------|  
> R  |
>   |----|    | Proxy  |   ***    ***     ***    | Proxy  |         
> |----|
>             |--------|                         |--------|
>
>
>      ****************************************************************>
>
>                       =========RSVP============>
>
>
>   |----|                  |----|               ***
>   | S  | Sender           | R  | Receiver      *r* regular RSVP
>   |----|                  |----|               *** router
>
>   <***> media flow
>
>   ==>  segment of flow path protected by RSVP reservation
>        in forward direction
>
>   /    Application level signaling
>
>   //   RSVP proxy control signaling
>
>
> The differences are small from the existing scenarios, but they are:
>
> 1) The scenario isn't SIP specific (diff from Section 4.4)
> 2) Formalizes the separation of application layer entities and RSVP  
> signaling entities (diff from section 4.5 and 4.6)
> 3) Highlights separation of sender proxy control and receiver proxy  
> control (as is already shown in figure 9, but not in the same  
> combination)
>
> I think point 2 is really the most interesting.  The separation is  
> represented in the above figure as "RSVP proxy control signaling".   
> I really consider this type of control signalling as a type of  
> policy control (or management) interface.  That said, I'm agnostic  
> on the protocol to use to support this interface.  It could be  
> Fred's old RSVP MIB, COPS-PR, QPIM (rfc3644), XML+??? or anything  
> else for that matter.
>
> I look forward to your response.
>
> Lou
>
> PS In the second draft, draft-ietf-tsvwg-rsvp-proxy-proto, you might
> consider allowing use of the Path_State_Removed flag [RFC3473].




From tsvwg-bounces@ietf.org Thu Apr 05 05:45:01 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZOVy-0004Rf-Fj; Thu, 05 Apr 2007 05:44:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZOVx-0004Ra-DU
	for tsvwg@ietf.org; Thu, 05 Apr 2007 05:44:21 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZOVw-0000GX-2y
	for tsvwg@ietf.org; Thu, 05 Apr 2007 05:44:21 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 05 Apr 2007 02:44:20 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l359iJQ0023800; 
	Thu, 5 Apr 2007 02:44:19 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l359iJMF025104;
	Thu, 5 Apr 2007 09:44:19 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 02:44:18 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 02:44:18 -0700
Message-ID: <4614C59F.8000900@cisco.com>
Date: Thu, 05 Apr 2007 05:47:11 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613D887.1030303@sun.com>	<4613E7CE.2020407@cisco.com>	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>	<4613FBC7.3070406@cisco.com>
	<4613FD6D.7040908@hp.com>	<4613FFB5.1060800@cisco.com>
	<46140324.8090609@hp.com>	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>	<461408F1.8080500@hp.com>	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
In-Reply-To: <B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Apr 2007 09:44:18.0350 (UTC)
	FILETIME=[FAEC2CE0:01C77766]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1914; t=1175766259;
	x=1176630259; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=T/Ar5GhsA5iFv/D1enonbszJ6GDNMzL6F2+xNG9foOQ=;
	b=bEvB5MIGsSvvU1q7iNSQNg4LN3KmtcF28TsZ7crNxkYX4shq3RJLNJb4lOv+30n7ro8WRNPS
	Oy4aTOqzoDR36j/7KCDBWW9cxT02C2Jm9UKFaWikYw3wWZ9Tpt9U5zYe;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: TSWG <tsvwg@ietf.org>, jan@newmarch.name,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Rick Jones <rick.jones2@hp.com>, Kacheong Poon <kacheong.poon@sun.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:
> On Apr 5, 2007, at 1:44 AM, Rick Jones wrote:
> 
>> Randall Stewart wrote:
>>> Michael Tuexen wrote:
>>>> Which protocol could use connnectx()? Doesn't it require
>>>> a transport protocol supporting multihoming. This would
>>>> limit it to SCTP. bindx() however, could be used also by
>>>> TCP and/or UDP.
>>>>
>>> Actually TCP could use it.. imagine I get back
>>> a list of IP addresses from DNS. I do a TCP
>>> connectx().
>>> Then when the SYN times out multiple times
>>> I can try an alternate. I only keep the single
>>> IP address that gets connected.. but it saves
>>> some.
>>
>> A leeeetle bit of application programming, but not really all that 
>> much? And if the application wanted to re-establish a session after a 
>> TCP connection failure, it would still want that initial list of IP's no?
>>
>> Heck, if you are going to go ahead and give connectx() a list of IPs 
>> for TCP to try, why not just give it the hostname...
> The problem with hostname is that you have no indication in the DNS 
> whether the IP addresses
> belong to the same host or not. For SCTP this is crucial, all addresses 
> must belong to the
> same host.
> 
> So one one has to restrict the list of IP-addresses to belong to the 
> same host.
> Assume that you send out two SYSs, one to address A, one to address B. 
> Now you
> get back a RST from A. Do you fail the connectx() call?
>>
>> rick jones
>> mpg member of the peanut gallery
>>
> 
Another problem with host names is the same one that has
made it so no one implements the "host name address" option
in SCTP. It is a pain to get the kernel to do a DNS resolution
from in the kernel since you end up doing a down up down
sort of dependency.

DNS is better left out of things like this IMO :-0

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Thu Apr 05 07:35:24 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZQEU-0006dK-4W; Thu, 05 Apr 2007 07:34:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQES-0006XO-1O
	for tsvwg@ietf.org; Thu, 05 Apr 2007 07:34:24 -0400
Received: from smtp01.bis.na.blackberry.com ([216.9.248.48])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZQEQ-0006Yn-Np
	for tsvwg@ietf.org; Thu, 05 Apr 2007 07:34:24 -0400
Message-ID: <246413649-1175772856-cardhu_blackberry.rim.net-1019399646-@bwe047-cell00.bisx.prod.on.blackberry>
Content-Transfer-Encoding: base64
References: <5o6afq$43psnc@sj-inbound-e.cisco.com>
	<212318B4-4ABB-489B-A0B7-4794F2A97340@cisco.com>
In-Reply-To: <212318B4-4ABB-489B-A0B7-4794F2A97340@cisco.com>
Sensitivity: Normal
Importance: Normal
To: "Francois Le Faucheur IMAP" <flefauch@cisco.com>,
	"Lou Berger" <lberger@labn.net>
From: "=?UTF-8?B?TG91IEJlcmdlcg==?=" <lberger@labn.net>
Date: Thu, 5 Apr 2007 11:34:03 +0000
Content-type: text/plain
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: allan.guillou@neufcegetl.fr, jmanner@cs.helsinki.fi, dwing@cisco.com,
	tsvwg@ietf.org
Subject: [Tsvwg] Re: some comments on
	draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lberger@labn.net
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

RnJhbmNvaXMsDQoNClNvdW5kcyBsaWtlIGEgcmVhc29uYWJsZSBwbGFuLiBJIGxvb2sgZm9yd2Fy
ZCB0byBzZWUgdGhlIG5leHQgcmV2LiANCg0KQnR3IFdoaWxlIHRoZSBBcHAgU2lnPC0tPlJTVlAt
UHJveHkgaW50ZXJmYWNlIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudCwgSSB0aGlu
ayBpdCdzIHN0aWxsIHdvcnRoIHB1cnN1aW5nLg0KDQpNdWNoIHRoYW5rcywNCkxvdQ0KICANCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVyIElN
QVAgPGZsZWZhdWNoQGNpc2NvLmNvbT4NCkRhdGU6IFRodSwgNSBBcHIgMjAwNyAxMDo1Njo0MCAN
ClRvOkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpDYzpGcmFuY29pcyBMZSBGYXVjaGV1
ciBJTUFQIDxmbGVmYXVjaEBjaXNjby5jb20+LCBqbWFubmVyQGNzLmhlbHNpbmtpLmZpLCAgICAg
ICBkd2luZ0BjaXNjby5jb20sIGFsbGFuLmd1aWxsb3VAbmV1ZmNlZ2V0bC5mciwgdHN2d2dAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBzb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHN2d2ctcnN2
cC1wcm94eS1hcHByb2FjaGVzLTAwLnR4dA0KDQpIZWxsbyBMb3UsDQoNCkkgYWdyZWUgd2l0aCBh
bGwgeW91ciBwb2ludHMuDQoNClRvIHJlZmxlY3QgdGhvc2UgaW4gdGhlIG5leHQgcmV2LCBJIHdv
dWxkIHByb3Bvc2UgdGhhdDoNCgkqIHdlIHVzZSB5b3VyIGRpYWdyYW0gYmVsb3cgaW5zdGVhZCBv
ZiB0aGUgY3VycmVudCBkaWFncmFtcyBpbiA0LjUgIA0KKGllIHNob3cgIkFwcCBTaWduYWxpbmcg
ZW50aXR5IiBpbnN0ZWFkIG9mICJTSVAvU0JFIiArIGZvcm1hbGl6ZSB0aGUgIA0KUHJveHkgY29u
dHJvbCBpbnRlcmZhY2UpDQoJKiB3ZSBkZXNjcmliZSB0aGUgY2FzZSB3aGVyZSB0aGUgIkFwcCBl
bnRpdHkiIGlzIGNvbG9jYXRlZCB3aXRoIHRoZSAgDQoiUlNWUCBQcm94eSIgKHdoYXQgd2FzIGls
bHVzdHJhdGVkICBpbiBGaWd1cmUgOSkgb25seSBhcyBhICANCiJwYXJ0aWN1bGFyIGNhc2UiIG9m
IHRoZSBtb3JlIGdlbmVyYWwgY2FzZS4gVG9kYXkgd2UgZmlyc3QgdGFsayBhYm91dCAgDQp0aGUg
cGFydGljdWxhciBjYXNlIGFuZCB0aGVuIGRlc2NyaWJlIHRoZSBtb3JlIGdlbmVyYWwgY2FzZS4N
CgkqIHdlIGFkZCBzb21lIHdvcmRzIGFib3V0IHRoZSBBcHAgU2lnPC0tPlJTVlAtUHJveHkgaW50
ZXJmYWNlIGFuZCAgDQp3aGF0IGV4YW1wbGUgcHJvdG9jb2xzIGNvdWxkIGJlIHVzZWQgKGFzIHlv
dSBkbyBiZWxvdykgYW5kIHN0YXRlICANCmRlZmluaXRpb24gb2YgdGhhdCBpbnRlcmZhY2UgaXMg
b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIA0KKHdlIGNvdWxkIHByb2dyZXNz
IHRoaXMgc2VwYXJhdGVseSB0aG91Z2gpLg0KCSogd2UgbW92ZSBiYWNrIGludG8gNC41IHRoZSBj
YXNlIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gNC42IGFuZCAgDQpkZXNjcmliZSBpdCBhcyBhbm90
aGVyIHBhcnRpY3VsYXIgY2FzZSBvZiB0aGUgbW9yZSBnZW5lcmFsIGNhc2Ugd2hlcmUgIA0KdGhl
ICJBcHAtU2lnPC0tPlJTVlAtUHJveHkiIGludGVyZmFjZSBoYXBwZW5zIHRvIGJlICJSU1ZQIG92
ZXIgR1JFIg0KDQpEb2VzIHRoYXQgd29yaz8NCklmIHllcywgaSdsbCB0cnkgZHJhZnQgc29tZSB0
ZXh0IGZvciByZXZpZXcuDQoNClRoYW5rcw0KDQpGcmFuY29pcw0KDQpPbiAzMCBNYXIgMjAwNywg
YXQgMjE6NDcsIExvdSBCZXJnZXIgd3JvdGU6DQoNCj4gRnJhbmNvaXMsIEp1a2thLCBEYW4sIEFs
bGFuLA0KPg0KPiBJIHRoaW5rIHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgc2NlbmFyaW8gdGhhdCB5
b3UgcHJvYmFibHkgaW50ZW5kIHRvICANCj4gYWxsb3csIGJ1dCBpc24ndCBleHBsaWNpdGx5IGNv
dmVyZWQgaW4gdGhlIGRvY3VtZW50LiAgVGhlIHNjZW5hcmlvICANCj4gaXMgc2ltaWxhciB0byB3
aGF0IGlzIHByZXNlbnRlZCBpbiBzZWN0aW9uICA0LjQsIDQuNSwgYW5kIDQuNiBidXQgIA0KPiBk
aWZmZXJzIGluIGEgZmV3IG9mIHRoZSBzcGVjaWZpY3MuIEkgdGhpbmsgdGhlIHNjZW5hcmlvIGNv
dWxkIGJlICANCj4gaW50ZWdyYXRlZCBpbnRvIHRoZSBleGlzdGluZyBzZWN0aW9ucyBvciBhZGRl
ZCBhcyBpdCdzIG93bi4NCj4NCj4gVGhlIHNjZW5hcmlvIGNhbiBiZSByZXByZXNlbnRlZCBieSB0
aGUgZm9sbG93aW5nOg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0t
fCAgICAgIHwtLS0tLS0tLS0tLS0tfA0KPiAgICAgICAgICAgICAgICAgICAgIHwgQXBwbGljYXRp
b24gfCAgICAgIHwgQXBwbGljYXRpb24gfA0KPiAgICAgICAgICAgICAgICAgX19fX3wgU2lnbmFs
aW5nICAgfF9fX19fX3wgU2lnbmFsaW5nICAgfF9fDQo+ICAgICAgICAgICAgICAgIC8gICAgfCBF
bnRpdHkgICAgICB8ICAgICAgfCBFbnRpdHkgICAgICB8ICBcDQo+ICAgICAgICAgICAgICAgLyAg
ICAgfC0tLS0tLS0tLS0tLS18ICAgICAgfC0tLS0tLS0tLS0tLS18ICAgXA0KPiAgICAgICAgICAg
ICAgLyAgICAgICAgLy8gICAgICAgICAgICAgICAgICAgICAgIFxcICAgICAgICAgICBcDQo+ICAg
ICAgICAgICAgIC8gICAgICAgIC8vICAgICAgICAgICAgICAgICAgICAgICAgIFxcICAgICAgICAg
ICBcDQo+ICAgICAgICAgICAgLyAgICAgICAgLy8gICAgICAgICAgICAgICAgICAgICAgICAgICBc
XCAgICAgICAgICAgXA0KPiAgICAgICAgICAgLyAgICAgICAgLy8gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFxcICAgICAgICAgICBcDQo+ICAgICAgICAgIC8gICAgICAgIC8vICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFxcICAgICAgICAgICBcDQo+ICAgICAgICAgLyAgICAgICAg
Ly8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcXCAgICAgICAgICAgXA0KPiAgICAg
ICAgLyAgICB8LS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLXwgICAg
ICAgICBcDQo+ICAgfC0tLS18ICAgIHwgUlNWUCAgIHwgICAqKiogICAgKioqICAgICAqKiogICAg
fCBSU1ZQICAgfCAgICAgICAgIA0KPiB8LS0tLXwNCj4gICB8IFMgIHwtLS0tfCBTZW5kZXIgfC0t
LSpyKi0tLS0qciotLS0tLSpyKi0tLS18UmVjZWl2ZXJ8LS0tLS0tLS18ICANCj4gUiAgfA0KPiAg
IHwtLS0tfCAgICB8IFByb3h5ICB8ICAgKioqICAgICoqKiAgICAgKioqICAgIHwgUHJveHkgIHwg
ICAgICAgICANCj4gfC0tLS18DQo+ICAgICAgICAgICAgIHwtLS0tLS0tLXwgICAgICAgICAgICAg
ICAgICAgICAgICAgfC0tLS0tLS0tfA0KPg0KPg0KPiAgICAgICoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio+DQo+DQo+ICAgICAg
ICAgICAgICAgICAgICAgICA9PT09PT09PT1SU1ZQPT09PT09PT09PT09Pg0KPg0KPg0KPiAgIHwt
LS0tfCAgICAgICAgICAgICAgICAgIHwtLS0tfCAgICAgICAgICAgICAgICoqKg0KPiAgIHwgUyAg
fCBTZW5kZXIgICAgICAgICAgIHwgUiAgfCBSZWNlaXZlciAgICAgICpyKiByZWd1bGFyIFJTVlAN
Cj4gICB8LS0tLXwgICAgICAgICAgICAgICAgICB8LS0tLXwgICAgICAgICAgICAgICAqKiogcm91
dGVyDQo+DQo+ICAgPCoqKj4gbWVkaWEgZmxvdw0KPg0KPiAgID09PiAgc2VnbWVudCBvZiBmbG93
IHBhdGggcHJvdGVjdGVkIGJ5IFJTVlAgcmVzZXJ2YXRpb24NCj4gICAgICAgIGluIGZvcndhcmQg
ZGlyZWN0aW9uDQo+DQo+ICAgLyAgICBBcHBsaWNhdGlvbiBsZXZlbCBzaWduYWxpbmcNCj4NCj4g
ICAvLyAgIFJTVlAgcHJveHkgY29udHJvbCBzaWduYWxpbmcNCj4NCj4NCj4gVGhlIGRpZmZlcmVu
Y2VzIGFyZSBzbWFsbCBmcm9tIHRoZSBleGlzdGluZyBzY2VuYXJpb3MsIGJ1dCB0aGV5IGFyZToN
Cj4NCj4gMSkgVGhlIHNjZW5hcmlvIGlzbid0IFNJUCBzcGVjaWZpYyAoZGlmZiBmcm9tIFNlY3Rp
b24gNC40KQ0KPiAyKSBGb3JtYWxpemVzIHRoZSBzZXBhcmF0aW9uIG9mIGFwcGxpY2F0aW9uIGxh
eWVyIGVudGl0aWVzIGFuZCBSU1ZQICANCj4gc2lnbmFsaW5nIGVudGl0aWVzIChkaWZmIGZyb20g
c2VjdGlvbiA0LjUgYW5kIDQuNikNCj4gMykgSGlnaGxpZ2h0cyBzZXBhcmF0aW9uIG9mIHNlbmRl
ciBwcm94eSBjb250cm9sIGFuZCByZWNlaXZlciBwcm94eSAgDQo+IGNvbnRyb2wgKGFzIGlzIGFs
cmVhZHkgc2hvd24gaW4gZmlndXJlIDksIGJ1dCBub3QgaW4gdGhlIHNhbWUgIA0KPiBjb21iaW5h
dGlvbikNCj4NCj4gSSB0aGluayBwb2ludCAyIGlzIHJlYWxseSB0aGUgbW9zdCBpbnRlcmVzdGlu
Zy4gIFRoZSBzZXBhcmF0aW9uIGlzICANCj4gcmVwcmVzZW50ZWQgaW4gdGhlIGFib3ZlIGZpZ3Vy
ZSBhcyAiUlNWUCBwcm94eSBjb250cm9sIHNpZ25hbGluZyIuICAgDQo+IEkgcmVhbGx5IGNvbnNp
ZGVyIHRoaXMgdHlwZSBvZiBjb250cm9sIHNpZ25hbGxpbmcgYXMgYSB0eXBlIG9mICANCj4gcG9s
aWN5IGNvbnRyb2wgKG9yIG1hbmFnZW1lbnQpIGludGVyZmFjZS4gIFRoYXQgc2FpZCwgSSdtIGFn
bm9zdGljICANCj4gb24gdGhlIHByb3RvY29sIHRvIHVzZSB0byBzdXBwb3J0IHRoaXMgaW50ZXJm
YWNlLiAgSXQgY291bGQgYmUgIA0KPiBGcmVkJ3Mgb2xkIFJTVlAgTUlCLCBDT1BTLVBSLCBRUElN
IChyZmMzNjQ0KSwgWE1MKz8/PyBvciBhbnl0aGluZyAgDQo+IGVsc2UgZm9yIHRoYXQgbWF0dGVy
Lg0KPg0KPiBJIGxvb2sgZm9yd2FyZCB0byB5b3VyIHJlc3BvbnNlLg0KPg0KPiBMb3UNCj4NCj4g
UFMgSW4gdGhlIHNlY29uZCBkcmFmdCwgZHJhZnQtaWV0Zi10c3Z3Zy1yc3ZwLXByb3h5LXByb3Rv
LCB5b3UgbWlnaHQNCj4gY29uc2lkZXIgYWxsb3dpbmcgdXNlIG9mIHRoZSBQYXRoX1N0YXRlX1Jl
bW92ZWQgZmxhZyBbUkZDMzQ3M10uDQo=





From tsvwg-bounces@ietf.org Thu Apr 05 07:36:11 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZQGB-0007iz-PK; Thu, 05 Apr 2007 07:36:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQGA-0007it-Mn
	for tsvwg@ietf.org; Thu, 05 Apr 2007 07:36:10 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZQG8-0006qq-Sf
	for tsvwg@ietf.org; Thu, 05 Apr 2007 07:36:10 -0400
Received: from [192.168.1.2] (p508ff164.dip.t-dialin.net [80.143.241.100])
	by mail-n.franken.de (Postfix) with ESMTP id 07A72800009F;
	Thu,  5 Apr 2007 13:35:50 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <4614C59F.8000900@cisco.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>	<46123559.20906@cisco.com>	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>	<46137F67.7080504@cisco.com>
	<461380FB.6060704@cisco.com>	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>	<461396B8.4090403@cisco.com>
	<4613D887.1030303@sun.com>	<4613E7CE.2020407@cisco.com>	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>	<4613FBC7.3070406@cisco.com>
	<4613FD6D.7040908@hp.com>	<4613FFB5.1060800@cisco.com>
	<46140324.8090609@hp.com>	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>	<461408F1.8080500@hp.com>	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Thu, 5 Apr 2007 13:35:47 +0200
To: Randall Stewart <rrs@cisco.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: TSWG <tsvwg@ietf.org>, jan@newmarch.name,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Rick Jones <rick.jones2@hp.com>, Kacheong Poon <kacheong.poon@sun.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randy,

yes, you are right.

But we stil have a semantic question:

Do the addresses listed in a connectx() call belong to the same host?

If yes, how do you react to a received RST segment in the TCP case.
For SCTP, we fail the sctp_connectx() call on reception of an ABORT.
This is due to the fact that in the SCTP case the host wants to
use *all* addresses of the peer. For TCP this is not possible, it
wants to use *one* of the addresses. It could even continue trying
addresses after for one of the addresses a RST segment has been
received. Therefore the restriction of all addresses belong to one
host is also not necessary for TCP... Haven't thought about
security implications for the TCP case.

Best regards
Michael

On Apr 5, 2007, at 11:47 AM, Randall Stewart wrote:

> Michael Tuexen wrote:
>> On Apr 5, 2007, at 1:44 AM, Rick Jones wrote:
>>> Randall Stewart wrote:
>>>> Michael Tuexen wrote:
>>>>> Which protocol could use connnectx()? Doesn't it require
>>>>> a transport protocol supporting multihoming. This would
>>>>> limit it to SCTP. bindx() however, could be used also by
>>>>> TCP and/or UDP.
>>>>>
>>>> Actually TCP could use it.. imagine I get back
>>>> a list of IP addresses from DNS. I do a TCP
>>>> connectx().
>>>> Then when the SYN times out multiple times
>>>> I can try an alternate. I only keep the single
>>>> IP address that gets connected.. but it saves
>>>> some.
>>>
>>> A leeeetle bit of application programming, but not really all  
>>> that much? And if the application wanted to re-establish a  
>>> session after a TCP connection failure, it would still want that  
>>> initial list of IP's no?
>>>
>>> Heck, if you are going to go ahead and give connectx() a list of  
>>> IPs for TCP to try, why not just give it the hostname...
>> The problem with hostname is that you have no indication in the  
>> DNS whether the IP addresses
>> belong to the same host or not. For SCTP this is crucial, all  
>> addresses must belong to the
>> same host.
>> So one one has to restrict the list of IP-addresses to belong to  
>> the same host.
>> Assume that you send out two SYSs, one to address A, one to  
>> address B. Now you
>> get back a RST from A. Do you fail the connectx() call?
>>>
>>> rick jones
>>> mpg member of the peanut gallery
>>>
> Another problem with host names is the same one that has
> made it so no one implements the "host name address" option
> in SCTP. It is a pain to get the kernel to do a DNS resolution
> from in the kernel since you end up doing a down up down
> sort of dependency.
>
> DNS is better left out of things like this IMO :-0
>
> R
>
> -- 
> Randall Stewart
> NSSTG - Cisco Systems Inc.
> 803-345-0369 <or> 803-317-4952 (cell)
>





From tsvwg-bounces@ietf.org Thu Apr 05 08:55:34 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZRUD-00043Z-PK; Thu, 05 Apr 2007 08:54:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRUD-00043U-9b
	for tsvwg@ietf.org; Thu, 05 Apr 2007 08:54:45 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRUB-0002Dz-9j
	for tsvwg@ietf.org; Thu, 05 Apr 2007 08:54:45 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 05 Apr 2007 14:54:41 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35CseIH020317; 
	Thu, 5 Apr 2007 14:54:40 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com
	[144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35CselZ006166; 
	Thu, 5 Apr 2007 12:54:40 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by
	xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 14:54:40 +0200
Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 5 Apr 2007 14:54:39 +0200
In-Reply-To: <OF70F734C1.557420EE-ON852572B4.0004D8D5-852572B4.0005C17E@csc.com>
References: <OF70F734C1.557420EE-ON852572B4.0004D8D5-852572B4.0005C17E@csc.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/alternative; boundary=Apple-Mail-8--98152538
Message-Id: <05AD1B16-0982-42F9-8EBF-88A4E7B12D3C@cisco.com>
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
Date: Thu, 5 Apr 2007 14:52:22 +0200
To: Janet P Gunn <jgunn6@csc.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 05 Apr 2007 12:54:39.0597 (UTC)
	FILETIME=[928429D0:01C77781]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15630; t=1175777680;
	x=1176641680; c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=flefauch@cisco.com;
	z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20WG=20last=20call=20of=20draft-ietf-tsvwg-em
	ergency-rsvp-02 |Sender:=20;
	bh=mAug43glg5tTJ1SSSh5f/whT/frBhqKnjsVa+E2iQyE=;
	b=JwrJzVmYEpMS6NYzGJ/wOmdxFBwUo5OflKkCU+el1VYsh0YcKIJeMa2dGkWAZ8uTAYA96oZm
	awPFNCYuDxyK088uA3TivuALfzqkgciKwoK7VO+zBapOjBJnXJH9Lz24;
Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim2001 verified; ); 
X-Spam-Score: 0.3 (/)
X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg <tsvwg@ietf.org>,
	ken carlberg <carlberg@g11.org.uk>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-8--98152538
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,
Just catching up on this.
It sounds like Ken and Janet have converged already.

Just a small extra clarification:
>
>> Nit-
>> In 3.1.1, I don't quite understand what is meant by "Take priority  
>> of highest QoS".  It seems to me that the set of all possible QoS  
>> specifications is  a partially ordered set (POSET) rather than a  
>> fully ordered set.  For instance,  QoS "A" may have stringent  
>> requirements for packet dropping, but weak requirements for delay  
>> and jitter.  But QoS "B" may have stringent requirements for delay  
>> and jitter, but weaker requirements for packet dropping.  It is  
>> not immediately obvious to me whether A or B is the "highest QoS".
>>
>> But the "Highest QoS"  concept is certainly not central to this  
>> document, and perhaps it is addressed in detail somewhere else  
>> that I have not come across.

The terminology of "Take priority of highest QoS" is taken directly  
from RFC3181 whcih defines these "merge strategies". Basically it  
refers to comparing Flowspecs of reservations (so there is no notion  
of packet dropping preference or anything like that - the key  
parameters are bandwidth).  Although Flowspec are not immediately  
comparable (as they include several parameters) RFC3181 mentions that  
there is a local policy behavior for comparing those.

Since the draft already explicitly reference RFC3181 when discussing  
the merge strategies, I think we're covered. But we can always add a  
sentence making this clarification.

Cheers

Francois



On 5 Apr 2007, at 03:02, Janet P Gunn wrote:

>
>
>
> In line.
>
>
> ken carlberg <carlberg@g11.org.uk> wrote on 04/04/2007 07:58:11 PM:
>
> > My apologies for the tardy response
> >
> >
> > For instance, at the end of section 3.1 it says "The Admission
> > Priority and Preemption
> >    Priority are handled by LPDPs and PEPs as orthogonal and  
> independent
> >    mechanisms. "
> > This is a bit of a cop out, as admission policy and preemption
> > policy cannot, in practice, be completely independent.  You can have
> > preemption without separate priority admission.  You can have
> > priority admission without preemption.
> >
> > you've just lost me because as I read your last two sentences, they
> > appear to contract your statement that they cannot be independent.
> >
>
> I guess I wasn't clear enough.
>
> They ARE independent in the sense that you can have one without.
>
> But they are NOT independent in the sense that, if you have both,  
> there is an interaction between them (for instance which is applied  
> first).
>
> > But if you have both priority  admission, and preemption, you have
> > to define the interaction, if only which one is applied first.
> > (Appendix B, in fact, describes cases in which admission priority is
> > applied first, and preemption is only applied if admission priority
> > fails.  But other interactions are possible.)  Therefore it would be
> > more realistic to say that, if both are used, the interaction is
> > defined "by local policy, outside the scope of this document".
> >
> > what we can do in Appendix B is add that other interactions are  
> possible.
> >
> Works for me.
> >
> > Appendix A
> >
> > This text appears a couple of times in Appendix A
> > "In that case additional priority sessions could not be accepted.  
> Note
> >    that this does not mean that such calls are dropped  
> altogether: they
> >    may be handled by mechanisms, which are beyond the scope of this
> >    particular document (such as establishment through preemption of
> >    existing non-priority sessions, or such as queuing of new  
> priority
> >    session requests until capacity becomes available again for  
> priority
> >    traffic)."
> >
> > It seems to me that, in most cases, preemption is applied by one
> > priority call to OTHER priority calls (which have lower preemption
> > priority), rather than to "non-priority" calls.
> >
> > Conversely, since priority admission and preemption are "orthogonal
> > and independent", it might be that some of the calls which are "non-
> > priority calls" from an "admission priority" perspective could be
> > "high priority calls" form a "preemption " perspective.  Therefore
> > it would probably be better to say
> > "(such as establishment through preemption of existing   
> sessions,...)"
> >
> > well, the term "such as" was really meant to convey an example.  we
> > can probably clear up the matter by switching "such as" with "for
> > example", and state that other variations could exist.
> >
> Works for me
>
> > Appendix B
> >
> > grammar nit-
> > "If one wants to implement an emergency service based on Call  
> Queueing,
> >    on "prioritized access to network layer resources", and  
> ensures that
> >    (say) "Emergency-1" sessions can preempt "Emergency-2"  
> sessions, but
> >    non-emergency sessions are not affected by preemption, one can do
> >    that by signaling emergency calls::"
> > is not quite grammatically correct.
> >  It needs to be (Changes in CAPS)
> > "If one wants to implement an emergency service based on Call  
> Queueing,
> >    on "prioritized access to network layer resources", and WHICH  
> ensures that
> >    (say) "Emergency-1" sessions can preempt "Emergency-2"  
> sessions, but
> >    non-emergency sessions are not affected by preemption, one can do
> >    that by signaling emergency calls:"
> > or
> > "If one wants to implement an emergency service based on Call  
> Queueing,
> >    on "prioritized access to network layer resources", and  
> ENSURE  that
> >    (say) "Emergency-1" sessions can preempt "Emergency-2"  
> sessions, but
> >    non-emergency sessions are not affected by preemption, one can do
> >    that by signaling emergency calls:"
> >
> > I'm sorry, but I don't see the difference nor the significance of
> > capitalizing "ensure" in comparison to the original text.
>
> Again, I wasn't clear.  It is simply a question of subject - verb  
> agreement
> "If one wants to ... ensure"
> not
> "If one wants to ... ensures"
>
> >
> > -ken
>
> The rest of your responses are fine with me.
>
> Janet


--Apple-Mail-8--98152538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>Hi,</DIV><DIV>Just catching =
up on this.=A0</DIV><DIV>It sounds like Ken and Janet have converged =
already.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Just a small extra =
clarification:</DIV><BLOCKQUOTE type=3D"cite"><BR style=3D""><BLOCKQUOTE =
type=3D"cite"><FONT class=3D"Apple-style-span" size=3D"5"><SPAN =
class=3D"Apple-style-span" style=3D"font-size: =
16.02px;">Nit-</SPAN></FONT> <BR style=3D""><FONT =
class=3D"Apple-style-span" size=3D"5"><SPAN class=3D"Apple-style-span" =
style=3D"font-size: 16.02px;">In 3.1.1, I don't quite understand what is =
meant by "Take priority of highest QoS". =A0It seems to me that the set =
of all possible QoS specifications is =A0a partially ordered set (POSET) =
rather than a fully ordered set. =A0For instance, =A0QoS "A" may have =
stringent requirements for packet dropping, but weak requirements for =
delay and jitter. =A0But QoS "B" may have stringent requirements for =
delay and jitter, but weaker requirements for packet dropping. =A0It is =
not immediately obvious to me whether A or B is the "highest QoS". =
=A0</SPAN></FONT> <BR style=3D""><BR style=3D""><FONT =
class=3D"Apple-style-span" size=3D"5"><SPAN class=3D"Apple-style-span" =
style=3D"font-size: 16.02px;">But the "Highest QoS" =A0concept is =
certainly not central to this document, and perhaps it is addressed in =
detail somewhere else that I have not come =
across.</SPAN></FONT>=A0</BLOCKQUOTE></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The terminology of "Take =
priority of highest QoS" is taken directly from RFC3181 whcih defines =
these "merge strategies". Basically it refers to comparing Flowspecs of =
reservations (so there is no notion of packet dropping preference or =
anything like that - the key parameters are bandwidth).=A0 Although =
Flowspec are not immediately comparable (as they include several =
parameters) RFC3181 mentions that there is a local policy behavior for =
comparing those.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Since the draft =
already=A0explicitly reference RFC3181 when discussing the merge =
strategies, I think we're covered. But we can always add a sentence =
making this clarification.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Cheers</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Francois</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><DIV><DIV>On 5 Apr 2007, at =
03:02, Janet P Gunn wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><BR><FONT =
size=3D"2" face=3D"sans-serif"><BR> <BR> In line.<BR> </FONT> <BR> =
<BR><FONT size=3D"2"><TT>ken carlberg &lt;<A =
href=3D"mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</A>&gt; wrote on =
04/04/2007 07:58:11 PM:<BR> <BR> &gt; My apologies for the tardy =
response</TT></FONT> <BR><FONT size=3D"2"><TT>&gt; =A0</TT></FONT> =
<BR><FONT size=3D"2"><TT>&gt; <BR> &gt; For instance, at the end of =
section 3.1 it says "The Admission <BR> &gt; Priority and Preemption =
<BR> &gt; =A0 =A0Priority are handled by LPDPs and PEPs as orthogonal =
and independent <BR> &gt; =A0 =A0mechanisms. " <BR> &gt; This is a bit =
of a cop out, as admission policy and preemption <BR> &gt; policy =
cannot, in practice, be completely independent. =A0You can have<BR> &gt; =
preemption without separate priority admission. =A0You can have <BR> =
&gt; priority admission without preemption. =A0</TT></FONT> <BR><FONT =
size=3D"2"><TT>&gt; <BR> &gt; you've just lost me because as I read your =
last two sentences, they <BR> &gt; appear to contract your statement =
that they cannot be independent.</TT></FONT> <BR><FONT size=3D"2"><TT>&gt;=
 </TT></FONT> <BR> <BR><FONT size=3D"2"><TT>I guess I wasn't clear =
enough. =A0</TT></FONT> <BR> <BR><FONT size=3D"2"><TT>They ARE =
independent in the sense that you can have one without.</TT></FONT> <BR> =
<BR><FONT size=3D"2"><TT>But they are NOT independent in the sense that, =
if you have both, there is an interaction between them (for instance =
which is applied first).</TT></FONT> <BR><FONT size=3D"2"><TT><BR> &gt; =
But if you have both priority =A0admission, and preemption, you have =
<BR> &gt; to define the interaction, if only which one is applied first. =
<BR> &gt; (Appendix B, in fact, describes cases in which admission =
priority is<BR> &gt; applied first, and preemption is only applied if =
admission priority <BR> &gt; fails. =A0But other interactions are =
possible.) =A0Therefore it would be<BR> &gt; more realistic to say that, =
if both are used, the interaction is <BR> &gt; defined "by local policy, =
outside the scope of this document".</TT></FONT> <BR><FONT =
size=3D"2"><TT>&gt; <BR> &gt; what we can do in Appendix B is add that =
other interactions are possible.</TT></FONT> <BR><FONT size=3D"2"><TT>&gt;=
 </TT></FONT> <BR><FONT size=3D"2"><TT>Works for me.</TT></FONT> =
<BR><FONT size=3D"2"><TT>&gt; <BR> &gt; Appendix A <BR> &gt; <BR> &gt; =
This text appears a couple of times in Appendix A <BR> &gt; "In that =
case additional priority sessions could not be accepted. Note <BR> &gt; =
=A0 =A0that this does not mean that such calls are dropped altogether: =
they <BR> &gt; =A0 =A0may be handled by mechanisms, which are beyond the =
scope of this <BR> &gt; =A0 =A0particular document (such as =
establishment through preemption of <BR> &gt; =A0 =A0existing =
non-priority sessions, or such as queuing of new priority <BR> &gt; =A0 =
=A0session requests until capacity becomes available again for priority =
<BR> &gt; =A0 =A0traffic)." <BR> &gt; <BR> &gt; It seems to me that, in =
most cases, preemption is applied by one <BR> &gt; priority call to =
OTHER priority calls (which have lower preemption <BR> &gt; priority), =
rather than to "non-priority" calls. <BR> &gt; <BR> &gt; Conversely, =
since priority admission and preemption are "orthogonal <BR> &gt; and =
independent", it might be that some of the calls which are "non-<BR> =
&gt; priority calls" from an "admission priority" perspective could be =
<BR> &gt; "high priority calls" form a "preemption " perspective. =
=A0Therefore <BR> &gt; it would probably be better to say <BR> &gt; =
"(such as establishment through preemption of existing =
=A0sessions,...)"=A0</TT></FONT> <BR><FONT size=3D"2"><TT>&gt; <BR> &gt; =
well, the term "such as" was really meant to convey an example.=A0 we =
<BR> &gt; can probably clear up the matter by switching "such as" with =
"for <BR> &gt; example", and state that other variations could =
exist.</TT></FONT> <BR><FONT size=3D"2"><TT>&gt; </TT></FONT> <BR><FONT =
size=3D"2"><TT>Works for me</TT></FONT> <BR><FONT size=3D"2"><TT><BR> =
&gt; Appendix B <BR> &gt; <BR> &gt; grammar nit- <BR> &gt; "If one wants =
to implement an emergency service based on Call Queueing, <BR> &gt; =A0 =
=A0on "prioritized access to network layer resources", and ensures that =
<BR> &gt; =A0 =A0(say) "Emergency-1" sessions can preempt "Emergency-2" =
sessions, but <BR> &gt; =A0 =A0non-emergency sessions are not affected =
by preemption, one can do <BR> &gt; =A0 =A0that by signaling emergency =
calls::" <BR> &gt; is not quite grammatically correct. <BR> &gt; =A0It =
needs to be (Changes in CAPS) <BR> &gt; "If one wants to implement an =
emergency service based on Call Queueing, <BR> &gt; =A0 =A0on =
"prioritized access to network layer resources", and WHICH ensures that =
<BR> &gt; =A0 =A0(say) "Emergency-1" sessions can preempt "Emergency-2" =
sessions, but <BR> &gt; =A0 =A0non-emergency sessions are not affected =
by preemption, one can do <BR> &gt; =A0 =A0that by signaling emergency =
calls:" <BR> &gt; or <BR> &gt; "If one wants to implement an emergency =
service based on Call Queueing, <BR> &gt; =A0 =A0on "prioritized access =
to network layer resources", and ENSURE =A0that <BR> &gt; =A0 =A0(say) =
"Emergency-1" sessions can preempt "Emergency-2" sessions, but <BR> &gt; =
=A0 =A0non-emergency sessions are not affected by preemption, one can do =
<BR> &gt; =A0 =A0that by signaling emergency calls:" </TT></FONT> =
<BR><FONT size=3D"2"><TT>&gt; <BR> &gt; I'm sorry, but I don't see the =
difference nor the significance of <BR> &gt; capitalizing "ensure" in =
comparison to the original text.</TT></FONT> <BR> <BR><FONT =
size=3D"2"><TT>Again, I wasn't clear. =A0It is simply a question of =
subject - verb agreement</TT></FONT> <BR><FONT size=3D"2"><TT>"If one =
wants to ... ensure"</TT></FONT> <BR><FONT size=3D"2"><TT>not =
</TT></FONT> <BR><FONT size=3D"2"><TT>"If one wants to ... =
ensures"</TT></FONT> <BR> <BR><FONT size=3D"2"><TT>&gt; <BR> &gt; =
-ken</TT></FONT> <BR> <BR><FONT size=3D"2"><TT>The rest of your =
responses are fine with me.</TT></FONT> <BR> <BR><FONT =
size=3D"2"><TT>Janet</TT></FONT></BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-8--98152538--




From tsvwg-bounces@ietf.org Thu Apr 05 09:31:14 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZS3G-0002iA-OM; Thu, 05 Apr 2007 09:30:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS3E-0002hn-HB
	for tsvwg@ietf.org; Thu, 05 Apr 2007 09:30:56 -0400
Received: from amer-mta07.csc.com ([20.137.52.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZS38-0007dv-5b
	for tsvwg@ietf.org; Thu, 05 Apr 2007 09:30:56 -0400
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	l35DUiMb000947; Thu, 5 Apr 2007 09:30:46 -0400 (EDT)
In-Reply-To: <05AD1B16-0982-42F9-8EBF-88A4E7B12D3C@cisco.com>
To: Francois Le Faucheur IMAP <flefauch@cisco.com>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF9ABBD4C0.FEA17945-ON852572B4.00499691-852572B4.004A38A4@csc.com>
Date: Thu, 5 Apr 2007 09:30:40 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF16|January 29, 2007) at 04/05/2007 09:29:30 AM,
	Serialize complete at 04/05/2007 09:29:30 AM
Content-Type: multipart/alternative;
	boundary="=_alternative 004A3868852572B4_="
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsvwg <tsvwg@ietf.org>,
	ken carlberg <carlberg@g11.org.uk>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is a multipart message in MIME format.
--=_alternative 004A3868852572B4_=
Content-Type: text/plain; charset="US-ASCII"

Francois,

Since the merging strategy is described in 3181, the "Janet doesn't 
understand" is there, and not in this document, so no need to change it 
here.
And now I DO understand .

I am happy with it.

Happy Easter/Passover/Spring,

Janet


Francois Le Faucheur IMAP <flefauch@cisco.com> wrote on 04/05/2007 
08:52:22 AM:

> Hi,
> Just catching up on this. 
> It sounds like Ken and Janet have converged already. 
> 
> Just a small extra clarification:
> 
> Nit- 
> In 3.1.1, I don't quite understand what is meant by "Take priority 
> of highest QoS".  It seems to me that the set of all possible QoS 
> specifications is  a partially ordered set (POSET) rather than a 
> fully ordered set.  For instance,  QoS "A" may have stringent 
> requirements for packet dropping, but weak requirements for delay 
> and jitter.  But QoS "B" may have stringent requirements for delay 
> and jitter, but weaker requirements for packet dropping.  It is not 
> immediately obvious to me whether A or B is the "highest QoS".   
> 
> But the "Highest QoS"  concept is certainly not central to this 
> document, and perhaps it is addressed in detail somewhere else that 
> I have not come across. 
> 
> The terminology of "Take priority of highest QoS" is taken directly 
> from RFC3181 whcih defines these "merge strategies". Basically it 
> refers to comparing Flowspecs of reservations (so there is no notion
> of packet dropping preference or anything like that - the key 
> parameters are bandwidth).  Although Flowspec are not immediately 
> comparable (as they include several parameters) RFC3181 mentions 
> that there is a local policy behavior for comparing those.
> 
> Since the draft already explicitly reference RFC3181 when discussing
> the merge strategies, I think we're covered. But we can always add a
> sentence making this clarification.
> 
> Cheers
> 
> Francois
> 
> On 5 Apr 2007, at 03:02, Janet P Gunn wrote:
> 
> 
> 
> 
> In line.
> 
> 
> ken carlberg <carlberg@g11.org.uk> wrote on 04/04/2007 07:58:11 PM:
> 
> > My apologies for the tardy response 
> >   
> > 
> > For instance, at the end of section 3.1 it says "The Admission 
> > Priority and Preemption 
> >    Priority are handled by LPDPs and PEPs as orthogonal and 
independent 
> >    mechanisms. " 
> > This is a bit of a cop out, as admission policy and preemption 
> > policy cannot, in practice, be completely independent.  You can have
> > preemption without separate priority admission.  You can have 
> > priority admission without preemption.   
> > 
> > you've just lost me because as I read your last two sentences, they 
> > appear to contract your statement that they cannot be independent. 
> > 
> 
> I guess I wasn't clear enough.   
> 
> They ARE independent in the sense that you can have one without. 
> 
> But they are NOT independent in the sense that, if you have both, 
> there is an interaction between them (for instance which is applied 
first). 
> 
> > But if you have both priority  admission, and preemption, you have 
> > to define the interaction, if only which one is applied first. 
> > (Appendix B, in fact, describes cases in which admission priority is
> > applied first, and preemption is only applied if admission priority 
> > fails.  But other interactions are possible.)  Therefore it would be
> > more realistic to say that, if both are used, the interaction is 
> > defined "by local policy, outside the scope of this document". 
> > 
> > what we can do in Appendix B is add that other interactions are 
possible. 
> > 
> Works for me. 
> > 
> > Appendix A 
> > 
> > This text appears a couple of times in Appendix A 
> > "In that case additional priority sessions could not be accepted. Note 

> >    that this does not mean that such calls are dropped altogether: 
they 
> >    may be handled by mechanisms, which are beyond the scope of this 
> >    particular document (such as establishment through preemption of 
> >    existing non-priority sessions, or such as queuing of new priority 
> >    session requests until capacity becomes available again for 
priority 
> >    traffic)." 
> > 
> > It seems to me that, in most cases, preemption is applied by one 
> > priority call to OTHER priority calls (which have lower preemption 
> > priority), rather than to "non-priority" calls. 
> > 
> > Conversely, since priority admission and preemption are "orthogonal 
> > and independent", it might be that some of the calls which are "non-
> > priority calls" from an "admission priority" perspective could be 
> > "high priority calls" form a "preemption " perspective.  Therefore 
> > it would probably be better to say 
> > "(such as establishment through preemption of existing 
 sessions,...)"  
> > 
> > well, the term "such as" was really meant to convey an example.  we 
> > can probably clear up the matter by switching "such as" with "for 
> > example", and state that other variations could exist. 
> > 
> Works for me 
> 
> > Appendix B 
> > 
> > grammar nit- 
> > "If one wants to implement an emergency service based on Call 
Queueing, 
> >    on "prioritized access to network layer resources", and ensures 
that 
> >    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, 
but 
> >    non-emergency sessions are not affected by preemption, one can do 
> >    that by signaling emergency calls::" 
> > is not quite grammatically correct. 
> >  It needs to be (Changes in CAPS) 
> > "If one wants to implement an emergency service based on Call 
Queueing, 
> >    on "prioritized access to network layer resources", and WHICH 
> ensures that 
> >    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, 
but 
> >    non-emergency sessions are not affected by preemption, one can do 
> >    that by signaling emergency calls:" 
> > or 
> > "If one wants to implement an emergency service based on Call 
Queueing, 
> >    on "prioritized access to network layer resources", and ENSURE 
 that 
> >    (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, 
but 
> >    non-emergency sessions are not affected by preemption, one can do 
> >    that by signaling emergency calls:" 
> > 
> > I'm sorry, but I don't see the difference nor the significance of 
> > capitalizing "ensure" in comparison to the original text. 
> 
> Again, I wasn't clear.  It is simply a question of subject - verb 
agreement 
> "If one wants to ... ensure" 
> not 
> "If one wants to ... ensures" 
> 
> > 
> > -ken 
> 
> The rest of your responses are fine with me. 
> 
> Janet
--=_alternative 004A3868852572B4_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
<br>
Francois,</font>
<br>
<br><font size=2 face="sans-serif">Since the merging strategy is described
in 3181, the &quot;Janet doesn't understand&quot; is there, and not in
this document, so no need to change it here.</font>
<br><font size=2 face="sans-serif">And now I DO understand .</font>
<br>
<br><font size=2 face="sans-serif">I am happy with it.</font>
<br>
<br><font size=2 face="sans-serif">Happy Easter/Passover/Spring,</font>
<br>
<br><font size=2 face="sans-serif">Janet<br>
</font>
<br>
<br><font size=2><tt>Francois Le Faucheur IMAP &lt;flefauch@cisco.com&gt;
wrote on 04/05/2007 08:52:22 AM:<br>
<br>
&gt; Hi,</tt></font>
<br><font size=2><tt>&gt; Just catching up on this.&nbsp;</tt></font>
<br><font size=2><tt>&gt; It sounds like Ken and Janet have converged already.&nbsp;</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Just a small extra clarification:</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Nit- <br>
&gt; In 3.1.1, I don't quite understand what is meant by &quot;Take priority
<br>
&gt; of highest QoS&quot;. &nbsp;It seems to me that the set of all possible
QoS <br>
&gt; specifications is &nbsp;a partially ordered set (POSET) rather than
a <br>
&gt; fully ordered set. &nbsp;For instance, &nbsp;QoS &quot;A&quot; may
have stringent <br>
&gt; requirements for packet dropping, but weak requirements for delay
<br>
&gt; and jitter. &nbsp;But QoS &quot;B&quot; may have stringent requirements
for delay <br>
&gt; and jitter, but weaker requirements for packet dropping. &nbsp;It
is not <br>
&gt; immediately obvious to me whether A or B is the &quot;highest QoS&quot;.
&nbsp; <br>
&gt; <br>
&gt; But the &quot;Highest QoS&quot; &nbsp;concept is certainly not central
to this <br>
&gt; document, and perhaps it is addressed in detail somewhere else that
<br>
&gt; I have not come across.&nbsp;</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; The terminology of &quot;Take priority of highest QoS&quot; is taken
directly <br>
&gt; from RFC3181 whcih defines these &quot;merge strategies&quot;. Basically
it <br>
&gt; refers to comparing Flowspecs of reservations (so there is no notion<br>
&gt; of packet dropping preference or anything like that - the key <br>
&gt; parameters are bandwidth).&nbsp; Although Flowspec are not immediately
<br>
&gt; comparable (as they include several parameters) RFC3181 mentions <br>
&gt; that there is a local policy behavior for comparing those.</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Since the draft already&nbsp;explicitly reference RFC3181 when discussing<br>
&gt; the merge strategies, I think we're covered. But we can always add
a<br>
&gt; sentence making this clarification.</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Cheers</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; Francois</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; On 5 Apr 2007, at 03:02, Janet P Gunn wrote:</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; In line.<br>
&gt; <br>
&gt; <br>
&gt; ken carlberg &lt;carlberg@g11.org.uk&gt; wrote on 04/04/2007 07:58:11
PM:<br>
&gt; <br>
&gt; &gt; My apologies for the tardy response <br>
&gt; &gt; &nbsp; <br>
&gt; &gt; <br>
&gt; &gt; For instance, at the end of section 3.1 it says &quot;The Admission
<br>
&gt; &gt; Priority and Preemption <br>
&gt; &gt; &nbsp; &nbsp;Priority are handled by LPDPs and PEPs as orthogonal
and independent <br>
&gt; &gt; &nbsp; &nbsp;mechanisms. &quot; <br>
&gt; &gt; This is a bit of a cop out, as admission policy and preemption
<br>
&gt; &gt; policy cannot, in practice, be completely independent. &nbsp;You
can have<br>
&gt; &gt; preemption without separate priority admission. &nbsp;You can
have <br>
&gt; &gt; priority admission without preemption. &nbsp; <br>
&gt; &gt; <br>
&gt; &gt; you've just lost me because as I read your last two sentences,
they <br>
&gt; &gt; appear to contract your statement that they cannot be independent.
<br>
&gt; &gt; <br>
&gt; <br>
&gt; I guess I wasn't clear enough. &nbsp; <br>
&gt; <br>
&gt; They ARE independent in the sense that you can have one without. <br>
&gt; <br>
&gt; But they are NOT independent in the sense that, if you have both,
<br>
&gt; there is an interaction between them (for instance which is applied
first). <br>
&gt; <br>
&gt; &gt; But if you have both priority &nbsp;admission, and preemption,
you have <br>
&gt; &gt; to define the interaction, if only which one is applied first.
<br>
&gt; &gt; (Appendix B, in fact, describes cases in which admission priority
is<br>
&gt; &gt; applied first, and preemption is only applied if admission priority
<br>
&gt; &gt; fails. &nbsp;But other interactions are possible.) &nbsp;Therefore
it would be<br>
&gt; &gt; more realistic to say that, if both are used, the interaction
is <br>
&gt; &gt; defined &quot;by local policy, outside the scope of this document&quot;.
<br>
&gt; &gt; <br>
&gt; &gt; what we can do in Appendix B is add that other interactions are
possible. <br>
&gt; &gt; <br>
&gt; Works for me. <br>
&gt; &gt; <br>
&gt; &gt; Appendix A <br>
&gt; &gt; <br>
&gt; &gt; This text appears a couple of times in Appendix A <br>
&gt; &gt; &quot;In that case additional priority sessions could not be
accepted. Note <br>
&gt; &gt; &nbsp; &nbsp;that this does not mean that such calls are dropped
altogether: they <br>
&gt; &gt; &nbsp; &nbsp;may be handled by mechanisms, which are beyond the
scope of this <br>
&gt; &gt; &nbsp; &nbsp;particular document (such as establishment through
preemption of <br>
&gt; &gt; &nbsp; &nbsp;existing non-priority sessions, or such as queuing
of new priority <br>
&gt; &gt; &nbsp; &nbsp;session requests until capacity becomes available
again for priority <br>
&gt; &gt; &nbsp; &nbsp;traffic).&quot; <br>
&gt; &gt; <br>
&gt; &gt; It seems to me that, in most cases, preemption is applied by
one <br>
&gt; &gt; priority call to OTHER priority calls (which have lower preemption
<br>
&gt; &gt; priority), rather than to &quot;non-priority&quot; calls. <br>
&gt; &gt; <br>
&gt; &gt; Conversely, since priority admission and preemption are &quot;orthogonal
<br>
&gt; &gt; and independent&quot;, it might be that some of the calls which
are &quot;non-<br>
&gt; &gt; priority calls&quot; from an &quot;admission priority&quot; perspective
could be <br>
&gt; &gt; &quot;high priority calls&quot; form a &quot;preemption &quot;
perspective. &nbsp;Therefore <br>
&gt; &gt; it would probably be better to say <br>
&gt; &gt; &quot;(such as establishment through preemption of existing &nbsp;sessions,...)&quot;&nbsp;
<br>
&gt; &gt; <br>
&gt; &gt; well, the term &quot;such as&quot; was really meant to convey
an example.&nbsp; we <br>
&gt; &gt; can probably clear up the matter by switching &quot;such as&quot;
with &quot;for <br>
&gt; &gt; example&quot;, and state that other variations could exist. <br>
&gt; &gt; <br>
&gt; Works for me <br>
&gt; <br>
&gt; &gt; Appendix B <br>
&gt; &gt; <br>
&gt; &gt; grammar nit- <br>
&gt; &gt; &quot;If one wants to implement an emergency service based on
Call Queueing, <br>
&gt; &gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and ensures that <br>
&gt; &gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt
&quot;Emergency-2&quot; sessions, but <br>
&gt; &gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &gt; &nbsp; &nbsp;that by signaling emergency calls::&quot; <br>
&gt; &gt; is not quite grammatically correct. <br>
&gt; &gt; &nbsp;It needs to be (Changes in CAPS) <br>
&gt; &gt; &quot;If one wants to implement an emergency service based on
Call Queueing, <br>
&gt; &gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and WHICH <br>
&gt; ensures that <br>
&gt; &gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt
&quot;Emergency-2&quot; sessions, but <br>
&gt; &gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &gt; &nbsp; &nbsp;that by signaling emergency calls:&quot; <br>
&gt; &gt; or <br>
&gt; &gt; &quot;If one wants to implement an emergency service based on
Call Queueing, <br>
&gt; &gt; &nbsp; &nbsp;on &quot;prioritized access to network layer resources&quot;,
and ENSURE &nbsp;that <br>
&gt; &gt; &nbsp; &nbsp;(say) &quot;Emergency-1&quot; sessions can preempt
&quot;Emergency-2&quot; sessions, but <br>
&gt; &gt; &nbsp; &nbsp;non-emergency sessions are not affected by preemption,
one can do <br>
&gt; &gt; &nbsp; &nbsp;that by signaling emergency calls:&quot; <br>
&gt; &gt; <br>
&gt; &gt; I'm sorry, but I don't see the difference nor the significance
of <br>
&gt; &gt; capitalizing &quot;ensure&quot; in comparison to the original
text. <br>
&gt; <br>
&gt; Again, I wasn't clear. &nbsp;It is simply a question of subject -
verb agreement <br>
&gt; &quot;If one wants to ... ensure&quot; <br>
&gt; not <br>
&gt; &quot;If one wants to ... ensures&quot; <br>
&gt; <br>
&gt; &gt; <br>
&gt; &gt; -ken <br>
&gt; <br>
&gt; The rest of your responses are fine with me. <br>
&gt; <br>
&gt; Janet</tt></font>
--=_alternative 004A3868852572B4_=--




From tsvwg-bounces@ietf.org Thu Apr 05 11:45:07 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZU7z-0004xD-PW; Thu, 05 Apr 2007 11:43:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZU7y-0004x8-KN
	for tsvwg@ietf.org; Thu, 05 Apr 2007 11:43:58 -0400
Received: from [2001:240:585:2:203:6dff:fe1a:4ddc] (helo=lakerest.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZU7u-0000XU-Nc
	for tsvwg@ietf.org; Thu, 05 Apr 2007 11:43:58 -0400
Received: from [10.1.1.11] (ibmlap [10.1.1.11])
	by lakerest.net (8.13.8/8.13.8) with ESMTP id l35Fhaoc049022;
	Thu, 5 Apr 2007 11:43:37 -0400 (EDT)
	(envelope-from randall@lakerest.net)
Message-ID: <461519D6.5070206@lakerest.net>
Date: Thu, 05 Apr 2007 11:46:30 -0400
From: Randall Stewart <randall@lakerest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
References: <4.3.2.7.2.20061128202906.02be3688@email.cisco.com><72CAFB34-883C-4CBB-A994-F9DEB1B0996A@nokia.com><424B01E7-F3D9-474B-80B9-F5FE5939211C@fh-muenster.de>	<DEA5C136-77ED-4D90-B1AB-A76268E53720@nokia.com>	<BAA65A575825454CBB0103267553FCCC02491DAA@esebe199.NOE.Nokia.com>	<45F6DAC8.3030701@cisco.com>	<902915D1-C42D-414E-BE44-0767CAA05C8B@nokia.com>	<45F807C8.2090805@mail.eecis.udel.edu>
	<CA64DEAB-72FE-4513-B52A-317526D55F8A@nokia.com>
In-Reply-To: <CA64DEAB-72FE-4513-B52A-317526D55F8A@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: iyengar@cis.udel.edu, Randall Stewart <rrs@cisco.com>, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Lars Eggert wrote:
> On 2007-3-14, at 16:33, ext Janardhan Iyengar wrote:
>> (I'm assuming we're LC'ing on -18, and not -17, as the subject suggests)
> 
> Right. There was an interim revision to address some issues.
> 
> Thanks for the review!
> 
> It looks as if we have consensus to request publication, and will do so 
> once -19 becomes available, which should address the issues people have 
> raised during the LC.
> 
> Lars
> 
> 
Lars:

Just had an offline comment.. and its valid too..
Somewhere in our editing (merging the asconf extended)
we took out the Supported Extensions Parameter.. opps.

I will add this to the things that need to be done to
clean up.. sorry about that... not sure how it was deleted.

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)




From tsvwg-bounces@ietf.org Thu Apr 05 14:19:43 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZWY1-0007hd-4a; Thu, 05 Apr 2007 14:19:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWXz-0007hY-Ge
	for tsvwg@ietf.org; Thu, 05 Apr 2007 14:18:59 -0400
Received: from mailhub.hp.com ([192.151.27.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWXw-0005od-DK
	for tsvwg@ietf.org; Thu, 05 Apr 2007 14:18:59 -0400
Received: from [192.168.98.102] (pool-64-222-184-138.man.east.verizon.net
	[64.222.184.138]) by mailhub.hp.com (Postfix) with ESMTP
	id 26A1E2711F; Thu,  5 Apr 2007 14:18:48 -0400 (EDT)
Message-ID: <46153D88.2060704@hp.com>
Date: Thu, 05 Apr 2007 12:18:48 -0600
From: Vlad Yasevich <vladislav.yasevich@hp.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com> <4614374F.8030607@cisco.com>
In-Reply-To: <4614374F.8030607@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>,
	jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> Vlad Yasevich wrote:
>> Michael Tuexen wrote:
>>>> At this point, I think perusing a generic standard bindx() is a
>>>> better option, but that will probably have to deal with some
>>>> specific sockaddr structures as well.
>>> So you are suggesting new (different names) bindx() and connectx() 
>>> calls or
>>> what do you mean by "generic standard"?
>>
>> I think Kacheong's idea of proposing a bindx() and connectx() API
>> for other socket types, not just SCTP, has merit, and I would
>> support that work faster then any changes to the sctp_bindx() or
>> sctp_connectx() api.
> 
> I agree other than the 3 point clarification Michael made earlier

Yes, sorry.  The context I was referring to here was changing the API 
itself.  I agree that the clarifications that Michael proposed are 
needed, but that don't change the API.

-vlad

> 
> R
>>
>> -vlad
>>
> 
> 





From tsvwg-bounces@ietf.org Thu Apr 05 15:50:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyf-0002lZ-Jg; Thu, 05 Apr 2007 15:50:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyV-0002iI-C3; Thu, 05 Apr 2007 15:50:27 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyK-0004dI-Ia; Thu, 05 Apr 2007 15:50:27 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AF13026F55;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00046G-Gj; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-cc-alt-01.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Specifying New Congestion Control Algorithms
	Author(s)	: S. Floyd, M. Allman
	Filename	: draft-ietf-tsvwg-cc-alt-01.txt
	Pages		: 11
	Date		: 2007-4-5
	
The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
    [XCP], and many more).  Using these new congestion control
    schemes in the global Internet has possible ramifications to
    both the traffic using the new congestion control and to traffic
    using the currently standardized congestion control.  Therefore,
    the IETF must proceed with caution when dealing with alternate
    congestion control proposals.  The goal of this document is to
    provide guidance for considering alternate congestion control
    algorithms within the IETF.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-cc-alt-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-cc-alt-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>


--OtherAccess--

--NextPart--





From tsvwg-bounces@ietf.org Thu Apr 05 15:50:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyR-0002eI-S1; Thu, 05 Apr 2007 15:50:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyM-0002cu-BL; Thu, 05 Apr 2007 15:50:18 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyD-0004dS-8C; Thu, 05 Apr 2007 15:50:18 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8CC8A329C0;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-000466-ED; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-000466-ED@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpthreat-03.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Security Attacks Found Against SCTP and Current Countermeasures
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-sctpthreat-03.txt
	Pages		: 14
	Date		: 2007-4-5
	
Stream Control Transmission Protocol defined in RFC 2960 is a multi-
   homed transport protocol.  As such, unique security threats exists
   that are addressed in various ways within the protocol itself.  This
   document attempts to detail the known security threats and their
   countermeasures as detailed in the current version of the SCTP
   Implementors guide RFC 4460.  It is hoped that this information will
   provide some useful background information for many of the newest
   requirements spelled out in the SCTP Implementors guide.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-sctpthreat-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5135650.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-03.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5135650.I-D@ietf.org>


--OtherAccess--

--NextPart--




From tsvwg-bounces@ietf.org Thu Apr 05 15:50:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyf-0002lZ-Jg; Thu, 05 Apr 2007 15:50:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyV-0002iI-C3; Thu, 05 Apr 2007 15:50:27 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyK-0004dI-Ia; Thu, 05 Apr 2007 15:50:27 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AF13026F55;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00046G-Gj; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-cc-alt-01.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Specifying New Congestion Control Algorithms
	Author(s)	: S. Floyd, M. Allman
	Filename	: draft-ietf-tsvwg-cc-alt-01.txt
	Pages		: 11
	Date		: 2007-4-5
	
The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
    [XCP], and many more).  Using these new congestion control
    schemes in the global Internet has possible ramifications to
    both the traffic using the new congestion control and to traffic
    using the currently standardized congestion control.  Therefore,
    the IETF must proceed with caution when dealing with alternate
    congestion control proposals.  The goal of this document is to
    provide guidance for considering alternate congestion control
    algorithms within the IETF.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-cc-alt-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-cc-alt-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>


--OtherAccess--

--NextPart--





From tsvwg-bounces@ietf.org Thu Apr 05 15:50:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyR-0002eI-S1; Thu, 05 Apr 2007 15:50:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyM-0002cu-BL; Thu, 05 Apr 2007 15:50:18 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyD-0004dS-8C; Thu, 05 Apr 2007 15:50:18 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8CC8A329C0;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-000466-ED; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-000466-ED@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpthreat-03.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Security Attacks Found Against SCTP and Current Countermeasures
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-sctpthreat-03.txt
	Pages		: 14
	Date		: 2007-4-5
	
Stream Control Transmission Protocol defined in RFC 2960 is a multi-
   homed transport protocol.  As such, unique security threats exists
   that are addressed in various ways within the protocol itself.  This
   document attempts to detail the known security threats and their
   countermeasures as detailed in the current version of the SCTP
   Implementors guide RFC 4460.  It is hoped that this information will
   provide some useful background information for many of the newest
   requirements spelled out in the SCTP Implementors guide.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-sctpthreat-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5135650.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-sctpthreat-03.txt

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

Content-Type: text/plain
Content-ID: <2007-4-5135650.I-D@ietf.org>


--OtherAccess--

--NextPart--




From tsvwg-bounces@ietf.org Thu Apr 05 15:51:04 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXz6-0003d5-4w; Thu, 05 Apr 2007 15:51:04 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXye-0002kx-FN; Thu, 05 Apr 2007 15:50:36 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HZXya-0002qM-W9; Thu, 05 Apr 2007 15:50:36 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E54012ACD2;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00046W-MR; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00046W-MR@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-addip-sctp-20.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-tsvwg-addip-sctp-20.txt
	Pages		: 38
	Date		: 2007-4-5
	
This document describes extensions to the Stream Control Transmission
   Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
   address information on an existing association.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-addip-sctp-20.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-20.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5142223.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-addip-sctp-20.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-addip-sctp-20.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-5142223.I-D@ietf.org>


--OtherAccess--

--NextPart--




From tsvwg-bounces@ietf.org Thu Apr 05 16:23:26 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZYUN-0005Q8-RP; Thu, 05 Apr 2007 16:23:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZYUL-0005PD-TD
	for tsvwg@ietf.org; Thu, 05 Apr 2007 16:23:21 -0400
Received: from pork.icsi.berkeley.edu ([192.150.186.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZYUH-0002q4-EC
	for tsvwg@ietf.org; Thu, 05 Apr 2007 16:23:21 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58])
	by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id
	l35KNEZh001774; Thu, 5 Apr 2007 13:23:14 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 5BFA299924E;
	Thu,  5 Apr 2007 16:23:08 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP id 18A7C1C7557;
	Thu,  5 Apr 2007 16:23:06 -0400 (EDT)
To: tsvwg@ietf.org
From: Mark Allman <mallman@icir.org>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Play Guitar
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 05 Apr 2007 16:23:06 -0400
Message-Id: <20070405202306.18A7C1C7557@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: Sally Floyd <floyd@icir.org>
Subject: [Tsvwg] rev-ed alternate cc draft
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--=_bOundary
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

 
Folks-

We made a small update to the cc-alt i-d to reflect the feedback from
the tsvwg meeting in Prague that we needed to better explain how this
document relates to RFC 2914.  The update is
draft-ietf-tsvwg-cc-alt-01.txt.

We added this paragraph to the intro:

    The guidelines in this document are intended to be consistent with
    the congestion control principles from [RFC2914] of preventing
    congestion collapse, considering fairness, and optimizing the flow's
    own performance in terms of throughput, delay, and loss.  [RFC2914]
    also discusses the goal of avoiding a congestion control `arms race'
    among competing transport protocols.  

In addition, we added a guideline to section 3:

    (0) Differences with Congestion Control Principles [RFC2914]

        Proposed congestion control mechanisms that do not take into
        account the congestion control principles from [RFC2914] should
        include a clear explanation of their differences.

Please let us know if there are further comments.  We are not aware of
any and believe the document is ready for WGLC.

Thanks!

allman




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFVqpWyrrWs4yIs4RAhGTAJ9xq8tKTo2P8dwLDEzSKxxMMwnVVwCeMKwG
6/na4MGoAsRMMGhT48g7jsA=
=sgFq
-----END PGP SIGNATURE-----
--=_bOundary--




From tsvwg-bounces@ietf.org Thu Apr 05 20:17:21 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZc7d-00060Q-PF; Thu, 05 Apr 2007 20:16:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZc7b-0005zv-VE
	for tsvwg@ietf.org; Thu, 05 Apr 2007 20:16:07 -0400
Received: from cypress.conncoll.edu ([136.244.1.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZc7a-0006JL-3q
	for tsvwg@ietf.org; Thu, 05 Apr 2007 20:16:07 -0400
Received: from [136.244.17.98] ([136.244.17.98]) by cypress.conncoll.edu with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 20:16:05 -0400
Message-ID: <46159142.2000609@mail.eecis.udel.edu>
Date: Thu, 05 Apr 2007 20:16:02 -0400
From: Janardhan Iyengar <iyengar@mail.eecis.udel.edu>
Organization: University of Delaware
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
In-Reply-To: <AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Apr 2007 00:16:05.0457 (UTC)
	FILETIME=[C4634C10:01C777E0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: TSWG <tsvwg@ietf.org>, jan@newmarch.name,
	Vlad Yasevich <vladislav.yasevich@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Rick Jones <rick.jones2@hp.com>, Kacheong Poon <kacheong.poon@sun.com>,
	Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iyengar@cis.udel.edu
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael,

> Do the addresses listed in a connectx() call belong to the same host? 

I'm starting to see a semantic inconsistency that makes me uncomfortable 
here.

In the TCP case, it seems that it does not matter whether the addresses 
belong to the same host or not. So, connectx() can, in the TCP world, 
connect to one of the IP addresses that responds, does not matter which.

But in SCTP, it does. So, during address confirmation, if one of the 
peer's IP address happens to be on another host, an ABORT will result 
from the host not in the association, and the association drops.


Here's another related inconsistency:

In TCP connectx(), suppose that the IPs belonged to different hosts, and 
one IP address responds with a SYN/ACK and the other responds with an 
RST. And suppose that the RST is dropped in the network. Should the 
sender still continue with a connection to the IP that responded 
disregarding the one that sent an RST, or should the sender wait for ALL 
IPs to respond first?

(a) Seems strange that the sender would wait for all IPs to respond, 
since ultimately only one peer IP is required for the connection. So, it 
makes sense for the sender to NOT wait.

(b) On the other hand, not waiting becomes another semantic 
inconsistency. In SCTP, confirmation is required for all peer IP 
addresses. So, if any of the IPs returned an ABORT during confirmation, 
the association is dropped.


These inconsistencies in interpreting the same call make me uncomfortable.

- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/




From tsvwg-bounces@ietf.org Fri Apr 06 04:03:09 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZjOd-0004H1-I7; Fri, 06 Apr 2007 04:02:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZjOc-0004Gt-CT; Fri, 06 Apr 2007 04:02:10 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZjOZ-0000SL-Pm; Fri, 06 Apr 2007 04:02:10 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3681VbQ022383; Fri, 6 Apr 2007 11:02:00 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 6 Apr 2007 11:01:43 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 6 Apr 2007 11:01:43 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by
	esebh102.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 11:01:43 +0300
Received: from [192.168.255.2] (essapo-nirac253239.europe.nokia.com
	[10.162.253.239])
	by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3681dNm020333; Fri, 6 Apr 2007 11:01:40 +0300
In-Reply-To: <26B285A9-3D4C-43B1-9C32-37EBC4AF39BE@nokia.com>
References: <26B285A9-3D4C-43B1-9C32-37EBC4AF39BE@nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-56--29203158;
	protocol="application/pkcs7-signature"
Message-Id: <0260FF1D-E29B-4D91-991D-612E77F53970@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Fri, 6 Apr 2007 11:01:32 +0300
To: TSV Area <tsv-area@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 06 Apr 2007 08:01:43.0060 (UTC)
	FILETIME=[D07F3540:01C77821]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070406110200-50BF6BB0-1224CEE6/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: iccrg@cs.ucl.ac.uk, tsvwg WG <tsvwg@ietf.org>
Subject: [Tsvwg] consensus call: bringing new congestion control to the IETF
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: TSV Area <tsv-area@ietf.org>
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-56--29203158
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,

On 2007-3-12, at 10:06, ext Lars Eggert wrote:
> the attentive reader of IETF agendas will have picked up on the  
> following presentation during the TSVAREA meeting:
>
> 20 min	Bringing Experimental High-Speed Congestion Control to the IETF
> 	Lars Eggert

after the presentation at TSVAREA, there was strong consensus in the  
room for the presented process to bring new congestion control to the  
IETF. I'd like to confirm that the community as a whole has consensus  
on this.

Please take a look at the following draft ION, which describes the  
process from the presentation: http://www.ietf.org/IESG/content/ions/ 
drafts/ion-tsv-alt-cc.txt

The consensus call will run until April 18, 2007. Please review the  
draft ION and send comments by the deadline.

Assuming the consensus from Prague is confirmed, I will ask the IESG  
to approve the ION after April 18.

Lars

PS: Please discuss on tsv-area@ietf.org. Reply-to set accordingly.

--Apple-Mail-56--29203158
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDYwODAxMzJaMCMGCSqGSIb3DQEJBDEWBBSM7RyQA2AcYy+s
GoRFHsnc1hkBBjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEA0GxuAzqr65OKC3DSInB8HMiZMIBAjw84k+N1KI7glqXhRW8J1GAf
7J2X6F2A4sXeTNqK7fEQkdzpLsWdd0kqj41clFsYVQtck9r4Mi5MQb3N/0PSxm/1ZDeE3vv7Leer
GeDjG2PCbMFGAEP8caawdVEu8lCyiMEx4r4ZpA9kCZvQDSaGeuCtlbiyJRMSMhwSKhj8S7tnoaQ2
+kFpK7Yw6Y00uSoYiTuHMdGji7Ip6Ocolx755Mem6evNl1Z+ZdLk2Wiuqk01DCvvwnUakNDoK7k0
dFHifUubvcefzB07oInF/XKk2QOa5J1IHsdrrQVlmbltZlogzLhf0KJdcPwhMQAAAAAAAA==

--Apple-Mail-56--29203158--




From tsvwg-bounces@ietf.org Fri Apr 06 04:06:01 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZjSC-0007aV-T0; Fri, 06 Apr 2007 04:05:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZjSB-0007Td-2x
	for tsvwg@ietf.org; Fri, 06 Apr 2007 04:05:51 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZjS9-00019O-KB
	for tsvwg@ietf.org; Fri, 06 Apr 2007 04:05:51 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3685EeF022349; Fri, 6 Apr 2007 11:05:39 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 6 Apr 2007 11:05:37 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by
	esebh104.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 11:05:36 +0300
Received: from [192.168.255.2] (essapo-nirac253239.europe.nokia.com
	[10.162.253.239])
	by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3685WRv022924; Fri, 6 Apr 2007 11:05:33 +0300
In-Reply-To: <461519D6.5070206@lakerest.net>
References: <4.3.2.7.2.20061128202906.02be3688@email.cisco.com><72CAFB34-883C-4CBB-A994-F9DEB1B0996A@nokia.com><424B01E7-F3D9-474B-80B9-F5FE5939211C@fh-muenster.de>	<DEA5C136-77ED-4D90-B1AB-A76268E53720@nokia.com>	<BAA65A575825454CBB0103267553FCCC02491DAA@esebe199.NOE.Nokia.com>	<45F6DAC8.3030701@cisco.com>	<902915D1-C42D-414E-BE44-0767CAA05C8B@nokia.com>	<45F807C8.2090805@mail.eecis.udel.edu>
	<CA64DEAB-72FE-4513-B52A-317526D55F8A@nokia.com>
	<461519D6.5070206@lakerest.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-57--28970653;
	protocol="application/pkcs7-signature"
Message-Id: <C5FD1247-DAB0-49D0-B154-C4043B4E8F6F@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
Date: Fri, 6 Apr 2007 11:05:24 +0300
To: ext Randall Stewart <randall@lakerest.net>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 06 Apr 2007 08:05:36.0973 (UTC)
	FILETIME=[5BEB7FD0:01C77822]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: iyengar@cis.udel.edu, Randall Stewart <rrs@cisco.com>, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-57--28970653
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 2007-4-5, at 18:46, ext Randall Stewart wrote:
> Lars Eggert wrote:
>> It looks as if we have consensus to request publication, and will  
>> do so once -19 becomes available, which should address the issues  
>> people have raised during the LC.
>
> Just had an offline comment.. and its valid too..
> Somewhere in our editing (merging the asconf extended)
> we took out the Supported Extensions Parameter.. opps.
>
> I will add this to the things that need to be done to
> clean up.. sorry about that... not sure how it was deleted.

Thanks for keeping on top of things.

WG: The -20 revision has just appeared; please take a quick look.  
Unless someone yells, we'll request publication next week.

Lars



--Apple-Mail-57--28970653
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MDYwODA1MjVaMCMGCSqGSIb3DQEJBDEWBBQnyQNwOGgD6/pG
UVPeo2sKu1/HLTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAxYvZnyjeNWXwC24VqNlm/0Ye40Ug9Edu43cr5AFuwRbzel8PteeC
04CMxPkotEmnZpBpwBkPFwFL0tA5O9fvI+bMerK0SqFp7QeSGSudvk7LuiEJGnmBaXjWJSjMjqP6
iQXheoQOJGFjCXHy8uUr4AofuIjofQ0DP0lRxmG77QVu75FmOr6L4YPAtAJJ8m3ZV1JzQ9loBSjQ
QU5Ic74dMzoLQwkjn4MIUfVCYIqkfSqNDOLKIhqvcNUTO8lcfUecV/rSzlyT5n0+xZo4/GSFYB86
iNCgLk3p0+wGrnCd5snKXaV5U8IRhcgrJPjyBk1w0xpKx8nhWhRDVsV3ib9nUwAAAAAAAA==

--Apple-Mail-57--28970653--




From tsvwg-bounces@ietf.org Fri Apr 06 07:33:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZmgQ-0006IV-B3; Fri, 06 Apr 2007 07:32:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZmgO-0006IO-UY
	for tsvwg@ietf.org; Fri, 06 Apr 2007 07:32:44 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZmgN-00030k-Ba
	for tsvwg@ietf.org; Fri, 06 Apr 2007 07:32:44 -0400
Received: from [192.168.1.17] (p508FD7E8.dip.t-dialin.net [80.143.215.232])
	by mail-n.franken.de (Postfix) with ESMTP id E1399800009F;
	Fri,  6 Apr 2007 13:12:29 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <46159142.2000609@mail.eecis.udel.edu>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<46159142.2000609@mail.eecis.udel.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <32054065-61CF-4416-84AB-BF59B4E7C539@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Fri, 6 Apr 2007 13:12:26 +0200
To: iyengar@cis.udel.edu
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, Rick Jones <rick.jones2@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Jana,

comments in-line.

Best regards
Michael

On Apr 6, 2007, at 2:16 AM, Janardhan Iyengar wrote:

> Michael,
>
>> Do the addresses listed in a connectx() call belong to the same host?
>
> I'm starting to see a semantic inconsistency that makes me  
> uncomfortable here.
>
> In the TCP case, it seems that it does not matter whether the  
> addresses belong to the same host or not. So, connectx() can, in  
> the TCP world, connect to one of the IP addresses that responds,  
> does not matter which.
>
> But in SCTP, it does. So, during address confirmation, if one of  
> the peer's IP address happens to be on another host, an ABORT will  
> result from the host not in the association, and the association  
> drops.
Yes, this is what I pointed out earlier in an e-mail... Maybe it did  
not get through.
>
>
> Here's another related inconsistency:
>
> In TCP connectx(), suppose that the IPs belonged to different  
> hosts, and one IP address responds with a SYN/ACK and the other  
> responds with an RST. And suppose that the RST is dropped in the  
> network. Should the sender still continue with a connection to the  
> IP that responded disregarding the one that sent an RST, or should  
> the sender wait for ALL IPs to respond first?
>
> (a) Seems strange that the sender would wait for all IPs to  
> respond, since ultimately only one peer IP is required for the  
> connection. So, it makes sense for the sender to NOT wait.
>
> (b) On the other hand, not waiting becomes another semantic  
> inconsistency. In SCTP, confirmation is required for all peer IP  
> addresses. So, if any of the IPs returned an ABORT during  
> confirmation, the association is dropped.
>
>
> These inconsistencies in interpreting the same call make me  
> uncomfortable.
Yes, basically for TCP it is "connect to one of these addresses" and  
for SCTP
it is "connect to all of these addresses". The same applies to bindx 
()...

Kacheong, what do you think? Is it a good idea to have a generic call  
with these
kind of differences in the semantics? I'm not sure. But I'm not an  
app writer...
>
> - jana
>
> -- 
> Janardhan R. Iyengar
> Visiting Assistant Professor
> Connecticut College
> http://cs.conncoll.edu/iyengar/
>
>





From tsvwg-bounces@ietf.org Fri Apr 06 09:39:07 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZodg-0005gA-59; Fri, 06 Apr 2007 09:38:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZode-0005g3-Rf
	for tsvwg@ietf.org; Fri, 06 Apr 2007 09:38:02 -0400
Received: from cypress.conncoll.edu ([136.244.1.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZodc-000881-Jg
	for tsvwg@ietf.org; Fri, 06 Apr 2007 09:38:02 -0400
Received: from [136.244.17.98] ([136.244.17.98]) by cypress.conncoll.edu with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 09:37:59 -0400
Message-ID: <46164D34.2050008@mail.eecis.udel.edu>
Date: Fri, 06 Apr 2007 09:37:56 -0400
From: Janardhan Iyengar <iyengar@mail.eecis.udel.edu>
Organization: University of Delaware
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<46159142.2000609@mail.eecis.udel.edu>
	<32054065-61CF-4416-84AB-BF59B4E7C539@micmac.franken.de>
In-Reply-To: <32054065-61CF-4416-84AB-BF59B4E7C539@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Apr 2007 13:37:59.0875 (UTC)
	FILETIME=[CAD0D930:01C77850]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, Rick Jones <rick.jones2@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, iyengar@cis.udel.edu,
	Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iyengar@cis.udel.edu
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael,

> Yes, basically for TCP it is "connect to one of these addresses" and for 
> SCTP
> it is "connect to all of these addresses". The same applies to bindx()...

It seems to me that bindx() would be different. bind() allows binding to 
all local interfaces (srcIP = *) or to one of them (srcIP = chosenIP). 
bindx() allows a subset.

I see that there is an inconsistency in that SCTP allows _all_ of these 
addresses to be in an association, but TCP will allow only one of these. 
But that seems to be somewhat more benign than the inconsistency with 
connectx() in that an app programmer will know what to expect of TCP or 
SCTP with bindx(). What do you think?

- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/




From tsvwg-bounces@ietf.org Fri Apr 06 09:58:03 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZowP-00024m-Hx; Fri, 06 Apr 2007 09:57:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZowO-00024h-8K
	for tsvwg@ietf.org; Fri, 06 Apr 2007 09:57:24 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZowM-0004wQ-M1
	for tsvwg@ietf.org; Fri, 06 Apr 2007 09:57:24 -0400
Received: from [192.168.1.17] (p508FD7E8.dip.t-dialin.net [80.143.215.232])
	by mail-n.franken.de (Postfix) with ESMTP id EDDF48006D97;
	Fri,  6 Apr 2007 15:57:18 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <46164D34.2050008@mail.eecis.udel.edu>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<46159142.2000609@mail.eecis.udel.edu>
	<32054065-61CF-4416-84AB-BF59B4E7C539@micmac.franken.de>
	<46164D34.2050008@mail.eecis.udel.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DC6A5BD0-291F-4FA5-B3FF-434DF665935B@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Fri, 6 Apr 2007 15:57:16 +0200
To: iyengar@cis.udel.edu
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, Rick Jones <rick.jones2@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Jana,

comment in-line.

Best regards
Michael

On Apr 6, 2007, at 3:37 PM, Janardhan Iyengar wrote:

> Michael,
>
>> Yes, basically for TCP it is "connect to one of these addresses"  
>> and for SCTP
>> it is "connect to all of these addresses". The same applies to  
>> bindx()...
>
> It seems to me that bindx() would be different. bind() allows  
> binding to all local interfaces (srcIP = *) or to one of them  
> (srcIP = chosenIP). bindx() allows a subset.
But it is still a difference for the the connections/associations.  
For connections on of the
bound addresses is used, for associations most of the addresses are  
used.
>
> I see that there is an inconsistency in that SCTP allows _all_ of  
> these addresses to be in an association, but TCP will allow only  
> one of these. But that seems to be somewhat more benign than the  
> inconsistency with connectx() in that an app programmer will know  
> what to expect of TCP or SCTP with bindx(). What do you think?
bindx() for SCTP is more complicated. Think about the cases where you  
call bindx() with
two address sets, same port number, and the address sets are not  
disjunct... Something
like SO_REUSEADDR/SO_REUSPORT is more complicated for SCTP than for  
TCP... And not all
cases are clear...
>
> - jana
>
> -- 
> Janardhan R. Iyengar
> Visiting Assistant Professor
> Connecticut College
> http://cs.conncoll.edu/iyengar/
>





From tsvwg-bounces@ietf.org Fri Apr 06 10:25:41 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZpNE-0001yZ-2Z; Fri, 06 Apr 2007 10:25:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpND-0001yQ-0u
	for tsvwg@ietf.org; Fri, 06 Apr 2007 10:25:07 -0400
Received: from cypress.conncoll.edu ([136.244.1.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpNB-00064j-QO
	for tsvwg@ietf.org; Fri, 06 Apr 2007 10:25:07 -0400
Received: from [136.244.17.98] ([136.244.17.98]) by cypress.conncoll.edu with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 10:25:05 -0400
Message-ID: <4616583D.6060305@mail.eecis.udel.edu>
Date: Fri, 06 Apr 2007 10:25:01 -0400
From: Janardhan Iyengar <iyengar@mail.eecis.udel.edu>
Organization: University of Delaware
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<46159142.2000609@mail.eecis.udel.edu>
	<32054065-61CF-4416-84AB-BF59B4E7C539@micmac.franken.de>
	<46164D34.2050008@mail.eecis.udel.edu>
	<DC6A5BD0-291F-4FA5-B3FF-434DF665935B@micmac.franken.de>
In-Reply-To: <DC6A5BD0-291F-4FA5-B3FF-434DF665935B@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Apr 2007 14:25:05.0237 (UTC)
	FILETIME=[5EDCE050:01C77857]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: TSWG <tsvwg@ietf.org>, Vlad Yasevich <vladislav.yasevich@hp.com>,
	jan@newmarch.name, Rick Jones <rick.jones2@hp.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, iyengar@cis.udel.edu,
	Randall Stewart <rrs@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iyengar@cis.udel.edu
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

> But it is still a difference for the the connections/associations. For 
> connections on of the
> bound addresses is used, for associations most of the addresses are used.

Yup, I agree that is an inconsistency.

> bindx() for SCTP is more complicated. Think about the cases where you 
> call bindx() with
> two address sets, same port number, and the address sets are not 
> disjunct... Something
> like SO_REUSEADDR/SO_REUSPORT is more complicated for SCTP than for 
> TCP... And not all
> cases are clear...

I see. I am not clear also on how much complication something like 
bindx() will add to the TCP API, in terms of implementation.

It seems to me that there's enough concern (and not enough motivation??) 
to hold off on something like this. But that's my take from what I've 
gathered so far.

- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/




From tsvwg-bounces@ietf.org Fri Apr 06 17:17:59 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZvnT-0001a0-P0; Fri, 06 Apr 2007 17:16:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZvnS-0001Vw-2t; Fri, 06 Apr 2007 17:16:38 -0400
Received: from pork.icsi.berkeley.edu ([192.150.186.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZvnO-00055k-Mc; Fri, 06 Apr 2007 17:16:38 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58])
	by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id
	l36LGXoB022390; Fri, 6 Apr 2007 14:16:33 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id D887B9A08EB;
	Fri,  6 Apr 2007 17:16:27 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP id DF8781C8DBC;
	Fri,  6 Apr 2007 17:16:24 -0400 (EDT)
To: Michael Scharf <michael.scharf@ikr.uni-stuttgart.de>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <20070331111615.GA29580@ikr.uni-stuttgart.de> 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Play Guitar
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 06 Apr 2007 17:16:24 -0400
Message-Id: <20070406211624.DF8781C8DBC@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: tcpm@ietf.org, tsvwg@ietf.org
Subject: [Tsvwg] Re: [tcpm] Extending RFC 1323 window scaling? 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--=_bOundary
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


>   (1) The semantics of the SEG.WND field in the TCP header could be
>       changed, i. e., the receive window is scaled in <SYN,ACK>
>       segments under some constraints. Whether or not the receive
>       window is scaled could be announced explicitly by a flag, or
>       implicitly, e. g., due to the presence of Quick-Start options or
>       other options. However, changing the semantics of the receive
>       window header field creates interoperation issues with hosts
>       that do not implement such a modification.
> 
>   (2) The true amount of free buffer space is announced somehow, and
>       overwrites the (unscaled) value in the TCP header, which remains
>       unscaled in order to be compatible with hosts that do not
>       implement this mechanism. This requires some new mechanism to
>       signal a scaled receive window in <SYN,ACK> segments.
> 
> The proposed new TCP option is a straightforward realization of
> approach (2).

I am not sure if we need a (2).  As you note, Quick-Start is currently
the only thing that really runs into a problem and maybe something else
could.  To be precise, I think we can say that the only place where this
is a problem is when the initiator of a connection wants to (and can)
send more than 64KB in the first RTT of the connection.  Unless we
pretty drastically change the rules it seems that this is going to have
to be done only with some explicit communication and so using that as an
implicit signal seems fine to me.  (We clearly botched this in terms of
Quick-Start because we were too dumb to think of it and you found it
after publication.)  Further, it is not clear that we need to add new
functionality like this for something experimental (Quick-Start).  But,
maybe ...

If I were going to take approach (2) I would suggest a two-byte option
that indicates the value in the standard TCP header is to be scaled.
Why add another 2 byte window value when one of them is going to be
ignored?  This fails safe because if a host doesn't understand the new
("the window is scaled") option it will think the advertised window is
unscaled and so less than it really is and so there is no danger in
running into problems.

allman




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGFrioWyrrWs4yIs4RAq+jAKCPDevUDeFqkHFtZ7yYHWLLBrgwRACfZU3p
xqyQPn3AvJ59k5thbqRoMSM=
=Evjf
-----END PGP SIGNATURE-----
--=_bOundary--




From tsvwg-bounces@ietf.org Mon Apr 09 15:51:30 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazt9-0004lh-Bm; Mon, 09 Apr 2007 15:50:55 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hazsn-0004fg-RM; Mon, 09 Apr 2007 15:50:33 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1Hazsn-0000aL-9Q; Mon, 09 Apr 2007 15:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1048F2ACAF;
	Mon,  9 Apr 2007 19:50:03 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HazsI-0005ci-QX; Mon, 09 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HazsI-0005ci-QX@stiedprstage1.ietf.org>
Date: Mon, 09 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-user-error-spec-00.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: User Defined Errors for RSVP
	Author(s)	: G. Swallow, A. Farrel
	Filename	: draft-ietf-tsvwg-rsvp-user-error-spec-00.txt
	Pages		: 10
	Date		: 2007-4-9
	
   The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
   for communicating errors.  That object has a defined format that
   permits the definition of 256 error codes.  As RSVP has been
   developed and extended, the convention has been to be conservative in
   defining new error codes.  Further, no provision for user defined
   errors exists in RSVP.   

This document defines a new RSVP object to permit user defined error
   values to be communicated.




A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-rsvp-user-error-spec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-9140323.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-tsvwg-rsvp-user-error-spec-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-9140323.I-D@ietf.org>


--OtherAccess--

--NextPart--





From tsvwg-bounces@ietf.org Mon Apr 09 17:31:49 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb1Ri-000898-ON; Mon, 09 Apr 2007 17:30:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hb1RL-0007ne-Pe; Mon, 09 Apr 2007 17:30:19 -0400
Received: from [202.99.23.227] (helo=people.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Hb1NY-0004eV-7i; Mon, 09 Apr 2007 17:26:26 -0400
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jmb3461ab59e; Tue, 10 Apr 2007 05:37:07 +0800
Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jmb046161798; Fri, 06 Apr 2007 11:29:17 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Fri, 06 Apr 2007 11:29:17 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyf-0002kj-81; Thu, 05 Apr 2007 15:50:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HZXyV-0002iI-C3; Thu, 05 Apr 2007 15:50:27 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HZXyK-0004dI-Ia; Thu, 05 Apr 2007 15:50:27 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AF13026F55;
	Thu,  5 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HZXy6-00046G-Gj; Thu, 05 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
Date: Thu, 05 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 386e0819b1192672467565a524848168
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-cc-alt-01.txt 
X-BeenThere: tsvwg@ietf.org
Reply-To: internet-drafts@ietf.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Specifying New Congestion Control Algorithms
	Author(s)	: S. Floyd, M. Allman
	Filename	: draft-ietf-tsvwg-cc-alt-01.txt
	Pages		: 11
	Date		: 2007-4-5
	
The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
    [XCP], and many more).  Using these new congestion control
    schemes in the global Internet has possible ramifications to
    both the traffic using the new congestion control and to traffic
    using the currently standardized congestion control.  Therefore,
    the IETF must proceed with caution when dealing with alternate
    congestion control proposals.  The goal of this document is to
    provide guidance for considering alternate congestion control
    algorithms within the IETF.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-cc-alt-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-cc-alt-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-5140411.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--






From tsvwg-bounces@ietf.org Tue Apr 10 03:14:34 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbAX8-0007CN-6s; Tue, 10 Apr 2007 03:12:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAX6-0007CI-Ni
	for tsvwg@ietf.org; Tue, 10 Apr 2007 03:12:52 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbAX5-0001tk-8T
	for tsvwg@ietf.org; Tue, 10 Apr 2007 03:12:52 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3A7CHh9001940 for <tsvwg@ietf.org>; Tue, 10 Apr 2007 10:12:48 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 10:12:36 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 10:12:36 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by
	esebh102.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:12:35 +0300
Received: from [172.21.34.179] (esdhcp034179.research.nokia.com
	[172.21.34.179])
	by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3A7CYnv019956 for <tsvwg@ietf.org>; Tue, 10 Apr 2007 10:12:34 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
References: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-313446989;
	protocol="application/pkcs7-signature"
Message-Id: <5A1E6DB4-9F21-4AEE-9025-F61028A3D034@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Tue, 10 Apr 2007 10:12:22 +0300
To: tsvwg WG <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 Apr 2007 07:12:35.0815 (UTC)
	FILETIME=[9D744F70:01C77B3F]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Tsvwg] start of WGLC for draft-ietf-tsvwg-cc-alt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-7-313446989
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 2007-4-5, at 22:50, ext tsvwg-bounces@ietf.org wrote:
> 	Title		: Specifying New Congestion Control Algorithms
> 	Author(s)	: S. Floyd, M. Allman
> 	Filename	: draft-ietf-tsvwg-cc-alt-01.txt
>
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt

We're starting the WGLC for this draft now. Please send your reviews  
by April 24, 2007.

Lars



--Apple-Mail-7-313446989
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MTAwNzEyMjJaMCMGCSqGSIb3DQEJBDEWBBSVEddFTPfGXiU8
ncrZmWhVbppAdTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAmCqxFBQ7d59U0o24EKRdx31CCpacClBn/fcJxGHY4oZlM87BEeXd
Vc5jA31wvYgJp+8uK/tNJxFWarKJ4mgyJJDwOGU4JX0MV3TQg0eA26dFnyFQHHQwvD3Hq69hAH7w
Z3Uq8A0Q0CeCnm4X9Q54SNWWVkrjUXXd7sMy5jQPQkbphLGzgiXn5w8gF0xg/39nQvgdZDuuEfXp
RSjWhgazWFnJcyLp8sBYuQwF6uHuk1bP6L4kyirERkGefbQMSA0ipCSWzYafMX+g2v9JsG/oEs4Y
H13BGd+v1x/hxBQLooimdBGR7oDs/tqGfSDybIEoHXY2oeUzGQupd8VpE2+BQAAAAAAAAA==

--Apple-Mail-7-313446989--




From tsvwg-bounces@ietf.org Tue Apr 10 07:10:00 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbEDj-0004Md-Mf; Tue, 10 Apr 2007 07:09:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEDi-0004MT-6a
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:09:06 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEDe-0007VP-Rj
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:09:06 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l3AB8O03014586; Tue, 10 Apr 2007 11:08:24 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3AB8KXu375107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 04:08:23 -0700 (PDT)
Message-ID: <461B7023.1030803@sun.com>
Date: Tue, 10 Apr 2007 19:08:19 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
In-Reply-To: <AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: jan@newmarch.name, Randall Stewart <rrs@cisco.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:

> Yes. You can have (only the port numbers are written):
> 0, 0, 0, 0, 0, 0 -> OK.
> p, 0, p, 0, p, 0 -> OK.
> p, p, p, p, p, p -> OK.
> p, q (with p > 0, p!=q) -> not OK.
> I would always fail the call for
> 0, p (p > 0)
> even if the kernel choses by random the port number p...


The last one requires the stack to keep a state
and I don't see why this is necessary.  In fact,
this will break an existing app.  For example,
an app does a bind(0) and getsockname(), then use
the port obtained in sctp_bindx().  This is correct
using the current semantics.  But with the last rule
above, it will fail.  I don't think we need to have
that rule.


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 07:10:56 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbEFT-0005hj-Qx; Tue, 10 Apr 2007 07:10:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEFS-0005hc-MO
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:10:54 -0400
Received: from sca-ea-mail-3.sun.com ([192.18.43.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEFR-0007q8-CD
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:10:54 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3ABAI74003409; Tue, 10 Apr 2007 11:10:18 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3ABAELD375364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 04:10:16 -0700 (PDT)
Message-ID: <461B7095.5050602@sun.com>
Date: Tue, 10 Apr 2007 19:10:13 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com>
In-Reply-To: <4613FBC7.3070406@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Michael Tuexen <Michael.Tuexen@micmac.franken.de>, jan@newmarch.name,
	SCTP Implementors <sctp-impl@external.cisco.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:

> I am fine with that.. as long as Kacheong and Vlad agree :-D


Sorry for the delay in response, it was holiday time :-)
Except for the last rule I mentioned in a previous mail,
I think Michael's new rules are good.



-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 07:14:00 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbEIR-0007HN-TP; Tue, 10 Apr 2007 07:13:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEIQ-0007HI-Tj
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:13:58 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEIP-0008MZ-3F
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:13:58 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l3ABDGuB015480; Tue, 10 Apr 2007 11:13:16 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3ABDCQU375841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 04:13:15 -0700 (PDT)
Message-ID: <461B7148.9020309@sun.com>
Date: Tue, 10 Apr 2007 19:13:12 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: Randall Stewart <rrs@cisco.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com>
In-Reply-To: <4613FFB5.1060800@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
	Michael Tuexen <Michael.Tuexen@micmac.franken.de>,
	SCTP Implementors <sctp-impl@external.cisco.com>,
	TSWG <tsvwg@ietf.org>, jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:
> One other question..
> 
> Should we change it to use a true array
> of
> 
> union struct sctp_sockstore's
> 
> Or whatever we call them?
> 
> I did teach a class on the socket api and this was
> a complaint .. the students would rather have a
> array of something like this union type..  Its smaller
> and more compact...


I don't think we should change the prototype.  The
current rules are just clarifications on the existing
prototype.  Changing the argument is not a good idea
at this point.





-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 07:53:17 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbEtx-0001AM-QY; Tue, 10 Apr 2007 07:52:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEtx-0001AG-2W
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:52:45 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbEtu-0000yd-Oa
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:52:45 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3ABqBCI009230; Tue, 10 Apr 2007 11:52:11 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3ABq7po379538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 04:52:10 -0700 (PDT)
Message-ID: <461B7A67.2070806@sun.com>
Date: Tue, 10 Apr 2007 19:52:07 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<6EF1DC22-143D-4201-B957-A2AA18736960@windriver.com>
In-Reply-To: <6EF1DC22-143D-4201-B957-A2AA18736960@windriver.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

David Borman wrote:
> It depends on what semantics are assigned to it.  For example, as was
> stated, it could be used for TCP to have a series of choices for how to
> connect to the remote host, rather than doing a loop in user space
> trying to connect to each address one at a time.  I could even see it
> being an optimization for connection time, where a SYN gets sent to all
> the addresses at the same time; the first SYN/ACK back wins, and a RST
> is sent in response to any additional SYN/ACKs that come back. And if
> the list is only 1 long, then it should be obvious what TCP should do.
> 
> connectx() is for connecting to a multi-homed host, and it can make
> sense for initiating a TCP connection, just not in the same way as SCTP.


Another usage which people have talked about is in IPv4/IPv6
transitioning.  Suppose a DNS query of a peer results in both
IPv4 and IPv6 addresses.  An app prefers IPv6 but somehow the
path to the peer does not quite work with IPv6.  It will take
some time before TCP times out the connection attempt.  But
if the stack knows that there is an IPv4 alternative, it can
be smarter to try the IPv4 address after the first RTO.

I agree that the important question is what semantics bindx()
and connectx() have.  And as with all other socket calls, it
will be different depending on the socket's address family and
protocol used.


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 07:55:35 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbEwg-0001ux-MS; Tue, 10 Apr 2007 07:55:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbEwf-0001uo-N7
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:55:33 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbEwd-0001pY-1o
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:55:33 -0400
Received: from [192.168.1.3] (p5481D4C9.dip.t-dialin.net [84.129.212.201])
	by mail-n.franken.de (Postfix) with ESMTP id B81B780000A0;
	Tue, 10 Apr 2007 13:55:17 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <461B7023.1030803@sun.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<461B7023.1030803@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <18CEE7B5-9D56-47F4-8C21-46FC091E7D9F@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Tue, 10 Apr 2007 13:55:15 +0200
To: Kacheong Poon <kacheong.poon@sun.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: jan@newmarch.name, Randall Stewart <rrs@cisco.com>,
	SCTP Implementors <sctp-impl@external.cisco.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Kacheong,

comments in-line.

Best regards
Michael

On Apr 10, 2007, at 1:08 PM, Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>> Yes. You can have (only the port numbers are written):
>> 0, 0, 0, 0, 0, 0 -> OK.
>> p, 0, p, 0, p, 0 -> OK.
>> p, p, p, p, p, p -> OK.
>> p, q (with p > 0, p!=q) -> not OK.
>> I would always fail the call for
>> 0, p (p > 0)
>> even if the kernel choses by random the port number p...
>
>
> The last one requires the stack to keep a state
> and I don't see why this is necessary.  In fact,
> this will break an existing app.  For example,
> an app does a bind(0) and getsockname(), then use
> the port obtained in sctp_bindx().  This is correct
> using the current semantics.  But with the last rule
> above, it will fail.  I don't think we need to have
> that rule.
I was thinking about the port number sequence in one
bindx() call.
On multiple calls you are right, of course. But if you
use 0, p in one call, the user has no chance in getting
the port number chosen. So most likely it is a bug in the
application. But if you think we should succeed the call
if the user guesses the port number right in advance, we
can do that. Running the code a second time will demonstrate
the bug.
>
>
> -- 
>
> 						K. Poon.
> 						kacheong.poon@sun.com
>
>





From tsvwg-bounces@ietf.org Tue Apr 10 08:00:01 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbF0b-0004dS-8B; Tue, 10 Apr 2007 07:59:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbF0Z-0004Zm-V2
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:59:35 -0400
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbF0Y-0002f9-Mc
	for tsvwg@ietf.org; Tue, 10 Apr 2007 07:59:35 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3ABx37f015873; Tue, 10 Apr 2007 11:59:03 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3ABwxHe380044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 04:59:02 -0700 (PDT)
Message-ID: <461B7C03.7020301@sun.com>
Date: Tue, 10 Apr 2007 19:58:59 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
In-Reply-To: <46143862.8080201@hp.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Rick Jones wrote:

> Heck, if you are going to go ahead and give connectx() a list of IPs for
> TCP to try, why not just give it the hostname...


Possibly.  But I suspect that this is better done by a
higher level function.  I think except name/service
resolution functions, all other socket calls do not deal
with such a "high level" concept as a hostname.



-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 10:46:37 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbHbS-0000NC-JY; Tue, 10 Apr 2007 10:45:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHbR-0000N7-NO
	for tsvwg@ietf.org; Tue, 10 Apr 2007 10:45:49 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHbQ-0006ka-9I
	for tsvwg@ietf.org; Tue, 10 Apr 2007 10:45:49 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 10 Apr 2007 16:45:48 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3AEjlw5004739; 
	Tue, 10 Apr 2007 16:45:47 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com
	[144.254.231.87])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AEjcld008784; 
	Tue, 10 Apr 2007 14:45:43 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by
	xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 16:45:39 +0200
Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 16:45:39 +0200
In-Reply-To: <5o6afq$43psnc@sj-inbound-e.cisco.com>
References: <5o6afq$43psnc@sj-inbound-e.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <940D0F31-2886-4410-A127-37C7B0B5E3E3@cisco.com>
Content-Transfer-Encoding: 7bit
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Date: Tue, 10 Apr 2007 16:43:18 +0200
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 Apr 2007 14:45:39.0406 (UTC)
	FILETIME=[E8231EE0:01C77B7E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1776; t=1176216347;
	x=1177080347; c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=flefauch@cisco.com;
	z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco.com>
	|Subject:=20Lou's=20suggestion=20for=20draft-ietf-tsvwg-rsvp-proxy-proto
	|Sender:=20; bh=QF2+vz8+FqOZbbounxOzUBk4/OFDtH3kZlD4arogXzs=;
	b=OTuYo2XQPiFZhIo+fSB0nCnktkQhvtNSICt6IvfRFySKpnz8bvMog3SbsKzOJSZdDkjosjy7
	LmeOEA5zxpNZba47bxe1843DlSvGEoynoKFd1m9iNO4yE9E996M45f09;
Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: Allan GUILLOU <allan.guillou@neufcegetel.fr>,
	Jukka Manner MJ <jmanner@cs.helsinki.fi>, Dan Wing <dwing@cisco.com>,
	"Ashok \(\(ashokn\)\) Narayanan" <ashokn@cisco.com>,
	tsvwg tsvwg <tsvwg@ietf.org>
Subject: [Tsvwg] Lou's suggestion for draft-ietf-tsvwg-rsvp-proxy-proto
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi Lou,

On 30 Mar 2007, at 21:47, Lou Berger wrote:

>
>
> Lou
>
> PS In the second draft, draft-ietf-tsvwg-rsvp-proxy-proto, you might
> consider allowing use of the Path_State_Removed flag [RFC3473].

Yes, good idea, the Path_State_Removed flag (PSR) could be used to  
expedite the release of resources/states (at least in some cases).

The one potential concern we have is in environments involving "old"  
RSVP routers which do not understand the PSR flag.
For example assume we have :
Sender--->R1--->R2--->Receiver_Proxy--->Receiver
where:
	- R1 is PSR-capable
	- R2 is not PSR-capable. R2 passes the PathErr upstream without  
resetting the PSR flag to zero and yet does not remove its Path state.
In that case, the Path state will be removed on Receiver-Proxy and on  
R1 , but will remain on R2. Furthermore, even if the Sender was to  
send a PathTear, this would not make it to R2 because R1 has already  
cleared the Path state.
The bottom line, is that in that heterogeneous case, the state  
removal is slower than without using PSR (we have to wait until Path  
times out on R2).

So, to be on the safe side, our proposal would be that :
	* by default, the PSR flag is not used (eg by default PSR flag not  
set by Receiver Proxy)
	* optionally, via a config knob, the RSVP Receiver Proxy behavior  
can be changed to set the PSR flag. This would be used in controlled  
environments (eg within a single Triple Play operator domain) where  
operator is sure that all routers are PSR-capable. In this case, the  
state removal is accelerated because the PathErr message directly  
tear downs Path state (and consequently Resv state) and Sender need  
not even send a PathTear.

Does that sound reasonable.

Francois




From tsvwg-bounces@ietf.org Tue Apr 10 11:38:25 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIPs-0002wF-Fq; Tue, 10 Apr 2007 11:37:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIPr-0002vh-5G
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:37:55 -0400
Received: from exprod7og53.obsmtp.com ([64.18.2.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbIPj-00045L-Of
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:37:55 -0400
Received: from source ([67.96.16.12]) by exprod7ob53.obsmtp.com ([64.18.6.12])
	with SMTP; Tue, 10 Apr 2007 08:37:40 PDT
Received: from ETSMSG-CINAV06.etsmsg.org ([65.90.82.49]) by
	NAOUT-CINEXS02.nasmtpout.emrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:47:02 -0400
Received: from etsmsg-cinexs02.etsmsg.org ([65.90.82.49]) by
	ETSMSG-CINAV06.etsmsg.org with InterScan Message Security Suite;
	Tue, 10 Apr 2007 11:37:39 -0400
Received: from ETSMSG-CINEXR03.etsmsg.org ([65.90.82.76]) by
	etsmsg-cinexs02.etsmsg.org with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 11:37:39 -0400
Received: from USACG-MSNEXM01.astec.com ([10.206.84.182]) by
	ETSMSG-CINEXR03.etsmsg.org with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 10 Apr 2007 11:37:39 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
Date: Tue, 10 Apr 2007 10:37:25 -0500
Message-ID: <DB255B459C0A1C458EB2D2353F1269CB023A4124@USACG-MSNEXM01.astec.com>
In-Reply-To: <C5FD1247-DAB0-49D0-B154-C4043B4E8F6F@nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
Thread-Index: Acd4IsDv40t5/zqVSrin8fGMn/X+YwDYziow
From: <ronnie@artesyncp.com>
To: <lars.eggert@nokia.com>,
	<randall@lakerest.net>
X-OriginalArrivalTime: 10 Apr 2007 15:37:39.0278 (UTC)
	FILETIME=[2BB9CEE0:01C77B86]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: iyengar@cis.udel.edu, rrs@cisco.com, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi,

Just been reading the latest ADDIP draft and something puzzles me.  May
be I'm missing something but this bit doesn't sound right to me.  I'm
looking at section 5.2 "Upon reception of an ASCONF chunk" and in
particular rule D2-ext).  The question I have is why would we want to
scan down all the ASCONF chunks in a packet to find an association match
when surely the first chunk MUST match the current association?  I am
thinking that if the first chunk does NOT match then all subsequent
chunks must be null and void. =20

After all if the first chunk was received on it's own and it didn't
match an association it would be rejected.

Sorry if I'm a bit late to the party here. :/

Ronnie
---
Ronnie Sellar			Emerson Network Power, Embedded
Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:ronnie@artesyncp.com	http://www.artesyncp.com
=20

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]=20
> Sent: 06 April 2007 09:05
> To: ext Randall Stewart
> Cc: iyengar@cis.udel.edu; Randall Stewart; tsvwg@ietf.org
> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17=20
> starts NOW
>=20
> On 2007-4-5, at 18:46, ext Randall Stewart wrote:
> > Lars Eggert wrote:
> >> It looks as if we have consensus to request publication,=20
> and will do=20
> >> so once -19 becomes available, which should address the=20
> issues people=20
> >> have raised during the LC.
> >
> > Just had an offline comment.. and its valid too..
> > Somewhere in our editing (merging the asconf extended) we=20
> took out the=20
> > Supported Extensions Parameter.. opps.
> >
> > I will add this to the things that need to be done to clean=20
> up.. sorry=20
> > about that... not sure how it was deleted.
>=20
> Thanks for keeping on top of things.
>=20
> WG: The -20 revision has just appeared; please take a quick look. =20
> Unless someone yells, we'll request publication next week.
>=20
> Lars
>=20
>=20
>=20




From tsvwg-bounces@ietf.org Tue Apr 10 11:47:08 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIY2-00087B-79; Tue, 10 Apr 2007 11:46:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIY0-000871-S3
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:46:20 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIXp-0005m4-RJ
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:46:20 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3AFjcIL015452; Tue, 10 Apr 2007 15:45:38 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3AFjYEX408219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 08:45:37 -0700 (PDT)
Message-ID: <461BB11D.7050508@sun.com>
Date: Tue, 10 Apr 2007 23:45:33 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
In-Reply-To: <B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:

> The problem with hostname is that you have no indication in the DNS
> whether the IP addresses
> belong to the same host or not. For SCTP this is crucial, all addresses
> must belong to the
> same host.


Hmm, I think the current SCTP socket API draft does not have the
above restriction.  From the -14 version of the draft.

    The way the SCTP stack uses the list of addresses to set up
    the association is implementation dependent.  This function
    only specifies that the stack will try to make use of all the
    addresses in the list when needed.

    Note that the list of addresses passed in is only used for
    setting up the association.  It does not necessarily equal the
    set of addresses the peer uses for the resulting association.

An implementation is free to choose the following semantics.
It tries the list of addresses one by one.  It waits for two
RTOs before moving to the next one.  And when it moves to the
next one, it will forget about the old one.  So when there is a
much delayed reply coming from the old one, it will treat it as
out of the blue.  Using this semantics, the list of addresses does
not need to correspond to the same host.  The above is just a
simple example, I am not advocating that it is a good implementation.

Why do we need such a restriction on sctp_connectx()?  SCTP itself
exchanges the IP addresses used by an association.  There is no
need to tell the stack what to expect from the peer.  If an app
requires this kind of restriction, it can always find out what
the list of peer addresses is after the association is set up and
terminate the association if the list does not match what it expects.


> So one one has to restrict the list of IP-addresses to belong to the
> same host.
> Assume that you send out two SYSs, one to address A, one to address B.
> Now you
> get back a RST from A. Do you fail the connectx() call?


If the semantics of the connectx() call is to try the whole list
if necessary to establish a connection, the call will not fail
after getting a RST from A.  It can continue to try B.  Are you
worried about the case that both A and B belong to the same host?

Let's consider a example.  Suppose for a reason, say load
balancing purpose, a server app writer decides to have two processes,
one with a socket bound to A and the other with a socket bound to
B.  A client can connect to either A or B to get the service.  Using
connectx(), a client can have A and B on the list of addresses to
try.  Suppose somehow the process bound to A crashes and the client's
stack tries A first.  So the client gets a RST from A.  Then the
client's stack tries B after getting the RST.  Is there a problem
with this?




-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 11:56:15 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIhO-0005OC-93; Tue, 10 Apr 2007 11:56:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIhN-0005O7-M5
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:56:01 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIhM-0008TI-Ch
	for tsvwg@ietf.org; Tue, 10 Apr 2007 11:56:01 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3AFtTcn019727; Tue, 10 Apr 2007 15:55:29 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3AFtLOJ410352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 08:55:28 -0700 (PDT)
Message-ID: <461BB369.1060006@sun.com>
Date: Tue, 10 Apr 2007 23:55:21 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
In-Reply-To: <AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:

> If yes, how do you react to a received RST segment in the TCP case.
> For SCTP, we fail the sctp_connectx() call on reception of an ABORT.
> This is due to the fact that in the SCTP case the host wants to
> use *all* addresses of the peer. 


No, I don't think sctp_connectx() provides this kind of
semantics to the caller.  In fact, how can an app know
about which addresses the peer wants to use for an
association?  Why is this restriction necessary for an
SCTP app?


> For TCP this is not possible, it
> wants to use *one* of the addresses. It could even continue trying
> addresses after for one of the addresses a RST segment has been
> received. Therefore the restriction of all addresses belong to one
> host is also not necessary for TCP... Haven't thought about
> security implications for the TCP case.


I suppose there is a security implication for SCTP if
sctp_connectx() does not have the above restriction.
What is the issue?  So suppose an app does a for loop
on the list of addresses doing connect(), is there a
problem also?


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 12:06:20 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbIrF-0002Fi-Ef; Tue, 10 Apr 2007 12:06:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIrE-0002Fd-2P
	for tsvwg@ietf.org; Tue, 10 Apr 2007 12:06:12 -0400
Received: from sca-ea-mail-1.sun.com ([192.18.43.24])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIrC-0002QY-Ng
	for tsvwg@ietf.org; Tue, 10 Apr 2007 12:06:12 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l3AG5etd006170; Tue, 10 Apr 2007 16:05:40 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3AG5Z8M413454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 09:05:39 -0700 (PDT)
Message-ID: <461BB5CF.5040005@sun.com>
Date: Wed, 11 Apr 2007 00:05:35 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<46159142.2000609@mail.eecis.udel.edu>
In-Reply-To: <46159142.2000609@mail.eecis.udel.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Janardhan Iyengar wrote:

> But in SCTP, it does. So, during address confirmation, if one of the
> peer's IP address happens to be on another host, an ABORT will result
> from the host not in the association, and the association drops.


Isn't address confirmation done in the SCTP level?  It
has nothing to do with the sctp_connectx() call.  It
seems to me that the above is a suggestion that the
list of addresses given to sctp_connectx() must be
the same list the peer uses.  Why is this necessary
for the call?


> Here's another related inconsistency:
> 
> In TCP connectx(), suppose that the IPs belonged to different hosts, and
> one IP address responds with a SYN/ACK and the other responds with an
> RST. And suppose that the RST is dropped in the network. Should the
> sender still continue with a connection to the IP that responded
> disregarding the one that sent an RST, or should the sender wait for ALL
> IPs to respond first?
> 
> (a) Seems strange that the sender would wait for all IPs to respond,
> since ultimately only one peer IP is required for the connection. So, it
> makes sense for the sender to NOT wait.


No, I don't think the wait is necessary.  But I suspect
that it can be implementation dependent.  I don't see
why it is necessary to require an implementation not
to wait.


> (b) On the other hand, not waiting becomes another semantic
> inconsistency. In SCTP, confirmation is required for all peer IP
> addresses. So, if any of the IPs returned an ABORT during confirmation,
> the association is dropped.


Given the current semantics as described in the SCTP socket
draft, I don't think the above is a requirement.




-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 12:49:42 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbJWS-0002fd-6n; Tue, 10 Apr 2007 12:48:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJWQ-0002fD-5Q
	for tsvwg@ietf.org; Tue, 10 Apr 2007 12:48:46 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbJWO-0002I9-Jl
	for tsvwg@ietf.org; Tue, 10 Apr 2007 12:48:46 -0400
Received: from [192.168.1.3] (p5481C913.dip.t-dialin.net [84.129.201.19])
	by mail-n.franken.de (Postfix) with ESMTP id 3AAC1801AC00;
	Tue, 10 Apr 2007 18:48:37 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <461BB369.1060006@sun.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Tue, 10 Apr 2007 18:48:35 +0200
To: Kacheong Poon <kacheong.poon@sun.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi Kacheong,

sctp_connectx() was invented to held in the SIGTRAN scenario, where
you typically know all addresses of your peers in advance via  
configuration.
Alternatively RSerPool also provides multiple addresses of one host.
Using connnect() you can not make use of the peers multihoming. Using
sctp_connectx() you can use this right from the beginning.
Not sure if this is written, the sender also considers the addresses
listed in the sctp_connectx() call as confirmed.

If you receive an ABORT, response to the sctp_connectx(), you fail
the association.

Best regards
Michael

On Apr 10, 2007, at 5:55 PM, Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>> If yes, how do you react to a received RST segment in the TCP case.
>> For SCTP, we fail the sctp_connectx() call on reception of an ABORT.
>> This is due to the fact that in the SCTP case the host wants to
>> use *all* addresses of the peer.
>
>
> No, I don't think sctp_connectx() provides this kind of
> semantics to the caller.  In fact, how can an app know
> about which addresses the peer wants to use for an
> association?  Why is this restriction necessary for an
> SCTP app?
>
>
>> For TCP this is not possible, it
>> wants to use *one* of the addresses. It could even continue trying
>> addresses after for one of the addresses a RST segment has been
>> received. Therefore the restriction of all addresses belong to one
>> host is also not necessary for TCP... Haven't thought about
>> security implications for the TCP case.
>
>
> I suppose there is a security implication for SCTP if
> sctp_connectx() does not have the above restriction.
> What is the issue?  So suppose an app does a for loop
> on the list of addresses doing connect(), is there a
> problem also?
>
>
> -- 
>
> 						K. Poon.
> 						kacheong.poon@sun.com
>
>
>





From tsvwg-bounces@ietf.org Tue Apr 10 13:25:39 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbK5U-0003G7-QV; Tue, 10 Apr 2007 13:25:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbK5T-0003Fx-UM
	for tsvwg@ietf.org; Tue, 10 Apr 2007 13:24:59 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbK5S-0002RJ-Ig
	for tsvwg@ietf.org; Tue, 10 Apr 2007 13:24:59 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l3AHONdm003062; Tue, 10 Apr 2007 17:24:23 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3AHOJxO429455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Apr 2007 10:24:23 -0700 (PDT)
Message-ID: <461BC843.9040809@sun.com>
Date: Wed, 11 Apr 2007 01:24:19 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
In-Reply-To: <B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:

> sctp_connectx() was invented to held in the SIGTRAN scenario, where
> you typically know all addresses of your peers in advance via
> configuration.
> Alternatively RSerPool also provides multiple addresses of one host.
> Using connnect() you can not make use of the peers multihoming. Using
> sctp_connectx() you can use this right from the beginning.


I still don't understand why the above implies the
restriction that the peer must use the same set of
addresses provided to the sctp_connectx() call.

Consider this example, an app knows that the peer has
three IP addresses A, B and C.  Using the connect() call,
the app can try A first and then if that fails, it will
try B and then C.  Suppose the peer's interface A is
somehow broken and the peer knows about it.  When the peer
gets the INIT to B, it replies with an INIT-ACK without
the address A because A is broken.  The association is setup
correctly and everything is working.

So if we have the restriction on sctp_connectx() that
the peer must use A, B, and C in the association, the
call will fail in this case.  I don't see why this is
necessary for SIGTRAN.


> Not sure if this is written, the sender also considers the addresses
> listed in the sctp_connectx() call as confirmed.


I don't think it is a good assumption.  An address should
be confirmed in the SCTP layer, not in the sctp_connectx()
call layer.


> If you receive an ABORT, response to the sctp_connectx(), you fail
> the association.


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Tue Apr 10 15:00:59 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbLZR-00069J-SI; Tue, 10 Apr 2007 15:00:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLZQ-00060B-EF
	for tsvwg@ietf.org; Tue, 10 Apr 2007 15:00:00 -0400
Received: from alnrmhc11.comcast.net ([204.127.225.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLZP-0001mr-4j
	for tsvwg@ietf.org; Tue, 10 Apr 2007 15:00:00 -0400
Received: from [10.10.0.100] (c-24-13-182-11.hsd1.il.comcast.net[24.13.182.11])
	by comcast.net (alnrmhc11) with ESMTP
	id <20070410185938b1100llh9oe>; Tue, 10 Apr 2007 18:59:58 +0000
Message-ID: <461BDE8D.5080708@ieee.org>
Date: Tue, 10 Apr 2007 13:59:25 -0500
From: Peter Lei <peter.lei@ieee.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: ronnie@artesyncp.com
Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
References: <DB255B459C0A1C458EB2D2353F1269CB023A4124@USACG-MSNEXM01.astec.com>
In-Reply-To: <DB255B459C0A1C458EB2D2353F1269CB023A4124@USACG-MSNEXM01.astec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: iyengar@cis.udel.edu, rrs@cisco.com, randall@lakerest.net, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi Ronnie,

Consider the case where the bundling of the ASCONF chunks is for
a singly-homed endpoint which changes its address more than once.
Further, assume that the peer endpoint did in fact process the
first chunk and sent an ASCONF-ACK which gets lost somewhere in
the network.

In this case, the source address and lookup address from the
first chunk may not find an association (since it processed the
first delete address and it no longer exists in the assoc), but
the second ASCONF chunk's lookup address should (since this one
should correspond to a valid address in the assoc).

Thus, you must process through all the asconf chunks that may be
bundled together in order to do an appropriate assoc lookup.

--peter

ronnie@artesyncp.com wrote:
> Hi,
> 
> Just been reading the latest ADDIP draft and something puzzles me.  May
> be I'm missing something but this bit doesn't sound right to me.  I'm
> looking at section 5.2 "Upon reception of an ASCONF chunk" and in
> particular rule D2-ext).  The question I have is why would we want to
> scan down all the ASCONF chunks in a packet to find an association match
> when surely the first chunk MUST match the current association?  I am
> thinking that if the first chunk does NOT match then all subsequent
> chunks must be null and void.  
> 
> After all if the first chunk was received on it's own and it didn't
> match an association it would be rejected.
> 
> Sorry if I'm a bit late to the party here. :/
> 
> Ronnie
> ---
> Ronnie Sellar			Emerson Network Power, Embedded
> Computing
> Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
> Fax: +44 131 475 7001		Edinburgh EH6 5NP
> mailto:ronnie@artesyncp.com	http://www.artesyncp.com
>  
> 
>> -----Original Message-----
>> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
>> Sent: 06 April 2007 09:05
>> To: ext Randall Stewart
>> Cc: iyengar@cis.udel.edu; Randall Stewart; tsvwg@ietf.org
>> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 
>> starts NOW
>>
>> On 2007-4-5, at 18:46, ext Randall Stewart wrote:
>>> Lars Eggert wrote:
>>>> It looks as if we have consensus to request publication, 
>> and will do 
>>>> so once -19 becomes available, which should address the 
>> issues people 
>>>> have raised during the LC.
>>> Just had an offline comment.. and its valid too..
>>> Somewhere in our editing (merging the asconf extended) we 
>> took out the 
>>> Supported Extensions Parameter.. opps.
>>>
>>> I will add this to the things that need to be done to clean 
>> up.. sorry 
>>> about that... not sure how it was deleted.
>> Thanks for keeping on top of things.
>>
>> WG: The -20 revision has just appeared; please take a quick look.  
>> Unless someone yells, we'll request publication next week.
>>
>> Lars
>>
>>
>>
> 
> 




From tsvwg-bounces@ietf.org Tue Apr 10 15:14:16 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbLmk-0005MF-Bz; Tue, 10 Apr 2007 15:13:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLmj-0005MA-Ku
	for tsvwg@ietf.org; Tue, 10 Apr 2007 15:13:45 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HbLmi-0005TW-6F
	for tsvwg@ietf.org; Tue, 10 Apr 2007 15:13:45 -0400
Received: from [192.168.1.3] (p5481C913.dip.t-dialin.net [84.129.201.19])
	by mail-n.franken.de (Postfix) with ESMTP id 19B6F8006DBF;
	Tue, 10 Apr 2007 21:13:42 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <461BC843.9040809@sun.com>
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<461BC843.9040809@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
Date: Tue, 10 Apr 2007 21:13:40 +0200
To: Kacheong Poon <kacheong.poon@sun.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On Apr 10, 2007, at 7:24 PM, Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>> sctp_connectx() was invented to held in the SIGTRAN scenario, where
>> you typically know all addresses of your peers in advance via
>> configuration.
>> Alternatively RSerPool also provides multiple addresses of one host.
>> Using connnect() you can not make use of the peers multihoming. Using
>> sctp_connectx() you can use this right from the beginning.
>
>
> I still don't understand why the above implies the
> restriction that the peer must use the same set of
> addresses provided to the sctp_connectx() call.
The reason is the following:
Assume I know that Host1 has IP11 and IP12 and Host2 has
IP21 and IP22.

When I call connectx(IP11,IP12) and the application is not
running on Host1 (due to a failure) I get back an ABORT and
know that it does not make sense to retry IP11 or IP12. I
can report the failure and try to connectx(IP21,IP22).

I can consider the reception of an ABORT as a failure of
the application and can skip all related IP addresses.
>
> Consider this example, an app knows that the peer has
> three IP addresses A, B and C.  Using the connect() call,
> the app can try A first and then if that fails, it will
> try B and then C.  Suppose the peer's interface A is
> somehow broken and the peer knows about it.  When the peer
> gets the INIT to B, it replies with an INIT-ACK without
> the address A because A is broken.  The association is setup
> correctly and everything is working.
That is OK.
>
> So if we have the restriction on sctp_connectx() that
> the peer must use A, B, and C in the association, the
> call will fail in this case.  I don't see why this is
> necessary for SIGTRAN.
It can us a subset. But the problem is the ABORT handling
described above. If I do not know which IP addresses belong
to the same host, I must try all of them. But in SIGTRAN
I either know the grouping (and can use connectx()) or I
do not know it in which case I just use connect().
>
>
>> Not sure if this is written, the sender also considers the addresses
>> listed in the sctp_connectx() call as confirmed.
>
>
> I don't think it is a good assumption.  An address should
> be confirmed in the SCTP layer, not in the sctp_connectx()
> call layer.
The upper layer always provides some addresses of the peer.
But one could make this stuff optional...
>
>
>> If you receive an ABORT, response to the sctp_connectx(), you fail
>> the association.
>
>
> -- 
>
> 						K. Poon.
> 						kacheong.poon@sun.com
>





From tsvwg-bounces@ietf.org Tue Apr 10 23:28:31 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbTTw-0007S9-H6; Tue, 10 Apr 2007 23:26:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbTTv-0007S1-B7
	for tsvwg@ietf.org; Tue, 10 Apr 2007 23:26:51 -0400
Received: from [205.234.190.117] (helo=esc91.midphase.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbTTu-0003bV-2c
	for tsvwg@ietf.org; Tue, 10 Apr 2007 23:26:51 -0400
Received: from esc91.midphase.com ([216.246.62.14] helo=LC1.labn.net)
	by esc91.midphase.com with esmtpa (Exim 4.63)
	(envelope-from <lberger@labn.net>)
	id 1HbTTi-0007y8-KC; Tue, 10 Apr 2007 23:26:38 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Apr 2007 23:26:39 -0400
To: Francois Le Faucheur IMAP <flefauch@cisco.com>
From: Lou Berger <lberger@labn.net>
In-Reply-To: <940D0F31-2886-4410-A127-37C7B0B5E3E3@cisco.com>
References: <5o6afq$43psnc@sj-inbound-e.cisco.com>
	<940D0F31-2886-4410-A127-37C7B0B5E3E3@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Allan GUILLOU <allan.guillou@neufcegetel.fr>,
	Jukka Manner MJ <jmanner@cs.helsinki.fi>, Dan Wing <dwing@cisco.com>,
	"Ashok \(\(ashokn\)\) Narayanan" <ashokn@cisco.com>,
	tsvwg tsvwg <tsvwg@ietf.org>
Subject: [Tsvwg] Re: Lou's suggestion for draft-ietf-tsvwg-rsvp-proxy-proto
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org
Message-Id: <E1HbTTw-0007S9-H6@megatron.ietf.org>

Francois,
         Yes, this sounds reasonable.

Lou

At 10:43 AM 4/10/2007, Francois Le Faucheur IMAP wrote:

>Hi Lou,
>
>On 30 Mar 2007, at 21:47, Lou Berger wrote:
>
>>
>>
>>Lou
>>
>>PS In the second draft, draft-ietf-tsvwg-rsvp-proxy-proto, you might
>>consider allowing use of the Path_State_Removed flag [RFC3473].
>
>Yes, good idea, the Path_State_Removed flag (PSR) could be used to
>expedite the release of resources/states (at least in some cases).
>
>The one potential concern we have is in environments involving "old"
>RSVP routers which do not understand the PSR flag.
>For example assume we have :
>Sender--->R1--->R2--->Receiver_Proxy--->Receiver
>where:
>         - R1 is PSR-capable
>         - R2 is not PSR-capable. R2 passes the PathErr upstream without
>resetting the PSR flag to zero and yet does not remove its Path state.
>In that case, the Path state will be removed on Receiver-Proxy and on
>R1 , but will remain on R2. Furthermore, even if the Sender was to
>send a PathTear, this would not make it to R2 because R1 has already
>cleared the Path state.
>The bottom line, is that in that heterogeneous case, the state
>removal is slower than without using PSR (we have to wait until Path
>times out on R2).
>
>So, to be on the safe side, our proposal would be that :
>         * by default, the PSR flag is not used (eg by default PSR flag not
>set by Receiver Proxy)
>         * optionally, via a config knob, the RSVP Receiver Proxy behavior
>can be changed to set the PSR flag. This would be used in controlled
>environments (eg within a single Triple Play operator domain) where
>operator is sure that all routers are PSR-capable. In this case, the
>state removal is accelerated because the PathErr message directly
>tear downs Path state (and consequently Resv state) and Sender need
>not even send a PathTear.
>
>Does that sound reasonable.
>
>Francois
>
>





From tsvwg-bounces@ietf.org Wed Apr 11 03:28:40 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbXEk-0002TT-8A; Wed, 11 Apr 2007 03:27:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXEi-0002Sa-IT
	for tsvwg@ietf.org; Wed, 11 Apr 2007 03:27:24 -0400
Received: from exprod7og59.obsmtp.com ([64.18.2.173])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbXEc-0006MN-0E
	for tsvwg@ietf.org; Wed, 11 Apr 2007 03:27:24 -0400
Received: from source ([67.96.16.11]) by exprod7ob59.obsmtp.com ([64.18.6.12])
	with SMTP; Wed, 11 Apr 2007 00:27:17 PDT
Received: from ETSMSG-CINAV02.etsmsg.org ([65.90.82.49]) by
	naout-cinexs01.nasmtpout.emrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 03:36:40 -0400
Received: from ETSMSG-CINEXS01.etsmsg.org ([65.90.82.49]) by
	ETSMSG-CINAV02.etsmsg.org with InterScan Message Security Suite;
	Wed, 11 Apr 2007 03:27:16 -0400
Received: from ETSMSG-CINEXR02.etsmsg.org ([65.90.82.108]) by
	ETSMSG-CINEXS01.etsmsg.org with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:27:15 -0400
Received: from USACG-MSNEXM01.astec.com ([10.206.84.182]) by
	ETSMSG-CINEXR02.etsmsg.org with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:27:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
Date: Wed, 11 Apr 2007 02:27:13 -0500
Message-ID: <DB255B459C0A1C458EB2D2353F1269CB023A4449@USACG-MSNEXM01.astec.com>
In-Reply-To: <461BDE8D.5080708@ieee.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW
Thread-Index: Acd7onId4RGj+62SQxS+BE/Mz2UbuAAaBxwg
From: <ronnie@artesyncp.com>
To: <peter.lei@ieee.org>
X-OriginalArrivalTime: 11 Apr 2007 07:27:15.0568 (UTC)
	FILETIME=[D43DB700:01C77C0A]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: iyengar@cis.udel.edu, rrs@cisco.com, randall@lakerest.net, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi Peter,

Thanks for that explanation.  I hadn't quite got round to considering
that the first ASCONF may have already been processed.  Doh !

That clears things up.

Ronnie
---
Ronnie Sellar			Emerson Network Power, Embedded
Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:ronnie@artesyncp.com	http://www.artesyncp.com
=20

> -----Original Message-----
> From: Peter Lei [mailto:peter.lei@ieee.org]=20
> Sent: 10 April 2007 19:59
> To: Sellar, Ronnie [ECB/EDI]
> Cc: lars.eggert@nokia.com; randall@lakerest.net;=20
> iyengar@cis.udel.edu; rrs@cisco.com; tsvwg@ietf.org
> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17=20
> starts NOW
>=20
> Hi Ronnie,
>=20
> Consider the case where the bundling of the ASCONF chunks is=20
> for a singly-homed endpoint which changes its address more than once.
> Further, assume that the peer endpoint did in fact process=20
> the first chunk and sent an ASCONF-ACK which gets lost=20
> somewhere in the network.
>=20
> In this case, the source address and lookup address from the=20
> first chunk may not find an association (since it processed=20
> the first delete address and it no longer exists in the=20
> assoc), but the second ASCONF chunk's lookup address should=20
> (since this one should correspond to a valid address in the assoc).
>=20
> Thus, you must process through all the asconf chunks that may=20
> be bundled together in order to do an appropriate assoc lookup.
>=20
> --peter
>=20
> ronnie@artesyncp.com wrote:
> > Hi,
> >=20
> > Just been reading the latest ADDIP draft and something puzzles me. =20
> > May be I'm missing something but this bit doesn't sound=20
> right to me. =20
> > I'm looking at section 5.2 "Upon reception of an ASCONF=20
> chunk" and in=20
> > particular rule D2-ext).  The question I have is why would=20
> we want to=20
> > scan down all the ASCONF chunks in a packet to find an association=20
> > match when surely the first chunk MUST match the current=20
> association? =20
> > I am thinking that if the first chunk does NOT match then all=20
> > subsequent chunks must be null and void.
> >=20
> > After all if the first chunk was received on it's own and it didn't=20
> > match an association it would be rejected.
> >=20
> > Sorry if I'm a bit late to the party here. :/
> >=20
> > Ronnie
> > ---
> > Ronnie Sellar			Emerson Network Power, Embedded
> > Computing
> > Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
> > Fax: +44 131 475 7001		Edinburgh EH6 5NP
> > mailto:ronnie@artesyncp.com	http://www.artesyncp.com
> > =20
> >=20
> >> -----Original Message-----
> >> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> >> Sent: 06 April 2007 09:05
> >> To: ext Randall Stewart
> >> Cc: iyengar@cis.udel.edu; Randall Stewart; tsvwg@ietf.org
> >> Subject: Re: [Tsvwg] WGLC for=20
> draft-ietf-tsvwg-addip-sctp-17 starts=20
> >> NOW
> >>
> >> On 2007-4-5, at 18:46, ext Randall Stewart wrote:
> >>> Lars Eggert wrote:
> >>>> It looks as if we have consensus to request publication,
> >> and will do
> >>>> so once -19 becomes available, which should address the
> >> issues people
> >>>> have raised during the LC.
> >>> Just had an offline comment.. and its valid too..
> >>> Somewhere in our editing (merging the asconf extended) we
> >> took out the
> >>> Supported Extensions Parameter.. opps.
> >>>
> >>> I will add this to the things that need to be done to clean
> >> up.. sorry
> >>> about that... not sure how it was deleted.
> >> Thanks for keeping on top of things.
> >>
> >> WG: The -20 revision has just appeared; please take a quick look. =20
> >> Unless someone yells, we'll request publication next week.
> >>
> >> Lars
> >>
> >>
> >>
> >=20
> >=20
>=20




From tsvwg-bounces@ietf.org Wed Apr 11 06:29:45 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hba4S-0001EV-2V; Wed, 11 Apr 2007 06:29:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hba4Q-0001EQ-O2
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:28:58 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hba4O-0000mv-8P
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:28:58 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 11 Apr 2007 03:28:55 -0700
X-IronPort-AV: i="4.14,394,1170662400"; 
	d="scan'208"; a="134418565:sNHT57472272"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3BASt1s001659; 
	Wed, 11 Apr 2007 03:28:55 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3BAStZT000342;
	Wed, 11 Apr 2007 10:28:55 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:28:55 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:28:54 -0700
Message-ID: <461CB90A.3080403@cisco.com>
Date: Wed, 11 Apr 2007 06:31:38 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Kacheong Poon <kacheong.poon@sun.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<579ea40b0704030204x58f9183vb4b1a96a40139e0a@mail.gmail.com>
	<46123559.20906@cisco.com>
	<579ea40b0704031923k553bed54kff59e052952fa31b@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<461BB11D.7050508@sun.com>
In-Reply-To: <461BB11D.7050508@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Apr 2007 10:28:54.0959 (UTC)
	FILETIME=[34C8CBF0:01C77C24]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3277; t=1176287335;
	x=1177151335; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=9OGu+uqia7Ds/v5j5YXAbdjUik/an2TfMpMUVaugatQ=;
	b=RxfU8adangN1OX9ubEIXiqjyg7rK4Q6GMar3mG4dj9x8ysLPwo9PS92hLxmUaTUbNpr2M6H5
	2HN9zaSKPalewHmpCMdQcb2ox+lsauVj1oblsb+iPDiC7aNiHnuQEWerMuPo1ekwJF7E8zFya2
	czqCpGow62lUNBNLW0amOzh5k=;
Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: jan@newmarch.name, SCTP Implementors <sctp-impl@external.cisco.com>,
	TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Kacheong:

One little note that neither adds to nor takes away
your argument..

All addresses that are listed by connect/connectx are
considered "confirmed" by the stack. This does not change
your scenario's .. but it is something to consider :-D

R

Kacheong Poon wrote:
> Michael Tuexen wrote:
> 
>> The problem with hostname is that you have no indication in the DNS
>> whether the IP addresses
>> belong to the same host or not. For SCTP this is crucial, all addresses
>> must belong to the
>> same host.
> 
> 
> Hmm, I think the current SCTP socket API draft does not have the
> above restriction.  From the -14 version of the draft.
> 
>     The way the SCTP stack uses the list of addresses to set up
>     the association is implementation dependent.  This function
>     only specifies that the stack will try to make use of all the
>     addresses in the list when needed.
> 
>     Note that the list of addresses passed in is only used for
>     setting up the association.  It does not necessarily equal the
>     set of addresses the peer uses for the resulting association.
> 
> An implementation is free to choose the following semantics.
> It tries the list of addresses one by one.  It waits for two
> RTOs before moving to the next one.  And when it moves to the
> next one, it will forget about the old one.  So when there is a
> much delayed reply coming from the old one, it will treat it as
> out of the blue.  Using this semantics, the list of addresses does
> not need to correspond to the same host.  The above is just a
> simple example, I am not advocating that it is a good implementation.
> 
> Why do we need such a restriction on sctp_connectx()?  SCTP itself
> exchanges the IP addresses used by an association.  There is no
> need to tell the stack what to expect from the peer.  If an app
> requires this kind of restriction, it can always find out what
> the list of peer addresses is after the association is set up and
> terminate the association if the list does not match what it expects.
> 
> 
>> So one one has to restrict the list of IP-addresses to belong to the
>> same host.
>> Assume that you send out two SYSs, one to address A, one to address B.
>> Now you
>> get back a RST from A. Do you fail the connectx() call?
> 
> 
> If the semantics of the connectx() call is to try the whole list
> if necessary to establish a connection, the call will not fail
> after getting a RST from A.  It can continue to try B.  Are you
> worried about the case that both A and B belong to the same host?
> 
> Let's consider a example.  Suppose for a reason, say load
> balancing purpose, a server app writer decides to have two processes,
> one with a socket bound to A and the other with a socket bound to
> B.  A client can connect to either A or B to get the service.  Using
> connectx(), a client can have A and B on the list of addresses to
> try.  Suppose somehow the process bound to A crashes and the client's
> stack tries A first.  So the client gets a RST from A.  Then the
> client's stack tries B after getting the RST.  Is there a problem
> with this?
> 
> 
> 
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 11 06:31:34 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hba6w-0002xu-1p; Wed, 11 Apr 2007 06:31:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hba6v-0002xp-Bi
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:31:33 -0400
Received: from sca-ea-mail-3.sun.com ([192.18.43.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hba6r-0001CG-Ph
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:31:33 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3BAUuoI025728; Wed, 11 Apr 2007 10:30:56 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3BAUqmH570852
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Apr 2007 03:30:55 -0700 (PDT)
Message-ID: <461CB8DC.4030104@sun.com>
Date: Wed, 11 Apr 2007 18:30:52 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<46137F67.7080504@cisco.com> <461380FB.6060704@cisco.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<461BC843.9040809@sun.com>
	<C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
In-Reply-To: <C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Michael Tuexen wrote:

> Assume I know that Host1 has IP11 and IP12 and Host2 has
> IP21 and IP22.
> 
> When I call connectx(IP11,IP12) and the application is not
> running on Host1 (due to a failure) I get back an ABORT and
> know that it does not make sense to retry IP11 or IP12. I
> can report the failure and try to connectx(IP21,IP22).
> 
> I can consider the reception of an ABORT as a failure of
> the application and can skip all related IP addresses.


As in the example I sent out in my previous mail, getting
a RST or ABORT does not necessarily imply that the peer app
is not running.  One can only make the above assumption if
the app knows exactly what the peer app must do, which means
that the app must be accepting INIT for the list of addresses.
It does not seem to be a general usage of sctp_connectx() and
I don't think connectx() should have this restrictions by
default.  If this kind of behavior is preferred by a certain
set of apps, connectx() may take a protocol specific flag
which indicates certain behavior.

BTW, the current specification of sctp_connectx() does not
have this restriction.  And it seems to me that if an app
expects this behavior, it will not be portable.


> It can us a subset. But the problem is the ABORT handling
> described above. If I do not know which IP addresses belong
> to the same host, I must try all of them. But in SIGTRAN
> I either know the grouping (and can use connectx()) or I
> do not know it in which case I just use connect().


Actually, the restriction is more than the knowledge of
all the addresses belonging to the same host.  The peer app
must also be accepting INIT for the whole list of addresses.


>> I don't think it is a good assumption.  An address should
>> be confirmed in the SCTP layer, not in the sctp_connectx()
>> call layer.
> The upper layer always provides some addresses of the peer.
> But one could make this stuff optional...


Yes, the upper layer provides some peer addresses.  But
it does not mean that those addresses are automatically
confirmed.  The confirmation must be done in the SCTP
layer.


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Wed Apr 11 06:36:18 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbaAx-0004lR-8z; Wed, 11 Apr 2007 06:35:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbaAw-0004lM-3S
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:35:42 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbaAt-0001nL-AH
	for tsvwg@ietf.org; Wed, 11 Apr 2007 06:35:42 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-4.cisco.com with ESMTP; 11 Apr 2007 03:35:38 -0700
X-IronPort-AV: i="4.14,394,1170662400"; 
	d="scan'208"; a="52776054:sNHT55830420"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3BAZc65016521; 
	Wed, 11 Apr 2007 03:35:38 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3BAZcEi003929;
	Wed, 11 Apr 2007 10:35:38 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:35:38 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 03:35:37 -0700
Message-ID: <461CBA9E.2070608@cisco.com>
Date: Wed, 11 Apr 2007 06:38:22 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Kacheong Poon <kacheong.poon@sun.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<461BC843.9040809@sun.com>
	<C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
	<461CB8DC.4030104@sun.com>
In-Reply-To: <461CB8DC.4030104@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Apr 2007 10:35:38.0006 (UTC)
	FILETIME=[2504E360:01C77C25]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2971; t=1176287738;
	x=1177151738; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=W2aont/niKmdTCIkMHO3Ezl4x7PweOyMh/w+YMB8540=;
	b=lSxyDb6MiprPu7zMstDQ4bzpSo8mwFxxmfTxig1ZwgWX4zm/o5zxnP7iuWpyphhiuh2s+Mzr
	DriyPmarRLCHDX68A7IlzNO1vFC9uM6f0MtO4et1czPXaxmy/qyFiptU;
Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Kacheong Poon wrote:
> Michael Tuexen wrote:
> 
>> Assume I know that Host1 has IP11 and IP12 and Host2 has
>> IP21 and IP22.
>>
>> When I call connectx(IP11,IP12) and the application is not
>> running on Host1 (due to a failure) I get back an ABORT and
>> know that it does not make sense to retry IP11 or IP12. I
>> can report the failure and try to connectx(IP21,IP22).
>>
>> I can consider the reception of an ABORT as a failure of
>> the application and can skip all related IP addresses.
> 
> 
> As in the example I sent out in my previous mail, getting
> a RST or ABORT does not necessarily imply that the peer app
> is not running.  One can only make the above assumption if
> the app knows exactly what the peer app must do, which means
> that the app must be accepting INIT for the list of addresses.
> It does not seem to be a general usage of sctp_connectx() and
> I don't think connectx() should have this restrictions by
> default.  If this kind of behavior is preferred by a certain
> set of apps, connectx() may take a protocol specific flag
> which indicates certain behavior.
> 
> BTW, the current specification of sctp_connectx() does not
> have this restriction.  And it seems to me that if an app
> expects this behavior, it will not be portable.
> 
> 
>> It can us a subset. But the problem is the ABORT handling
>> described above. If I do not know which IP addresses belong
>> to the same host, I must try all of them. But in SIGTRAN
>> I either know the grouping (and can use connectx()) or I
>> do not know it in which case I just use connect().
> 
> 
> Actually, the restriction is more than the knowledge of
> all the addresses belonging to the same host.  The peer app
> must also be accepting INIT for the whole list of addresses.
> 
> 
>>> I don't think it is a good assumption.  An address should
>>> be confirmed in the SCTP layer, not in the sctp_connectx()
>>> call layer.
>> The upper layer always provides some addresses of the peer.
>> But one could make this stuff optional...
> 
> 
> Yes, the upper layer provides some peer addresses.  But
> it does not mean that those addresses are automatically
> confirmed.  The confirmation must be done in the SCTP
> layer.
> 
> 

I think I agree with all you say (i.e. no such restriction
that the addresses all are on the same host is in
connectx).. however.. I disagree with the last statement.
If a user passes SCTP some addresses... saying in effect
I would like to talk to one or some set of these
addresses IP1, IP2, IP3.. then these addresses
are considered "good" addresses and not an attacker..

Now if the INIT-ACK comes back WITHOUT  IP3.. thats
ok.. the association will come up...  it just will
NOT have IP3 in it.. However.. both IP1 and IP2 should
be considered confirmed.. and not require a confirmation
HB..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Wed Apr 11 07:33:39 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbb4N-0007UF-1x; Wed, 11 Apr 2007 07:32:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbb4L-0007Tz-P3
	for tsvwg@ietf.org; Wed, 11 Apr 2007 07:32:57 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbb4K-00081m-FY
	for tsvwg@ietf.org; Wed, 11 Apr 2007 07:32:57 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	l3BBWPoa020137; Wed, 11 Apr 2007 11:32:25 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3BBWKYp574680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Apr 2007 04:32:24 -0700 (PDT)
Message-ID: <461CC744.2010201@sun.com>
Date: Wed, 11 Apr 2007 19:32:20 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<B0C58D77-3C0E-4D7F-9EB1-1E3834149CF7@micmac.franken.de>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<461BC843.9040809@sun.com>
	<C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
	<461CB8DC.4030104@sun.com> <461CBA9E.2070608@cisco.com>
In-Reply-To: <461CBA9E.2070608@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Randall Stewart wrote:

> I think I agree with all you say (i.e. no such restriction
> that the addresses all are on the same host is in
> connectx).. however.. I disagree with the last statement.
> If a user passes SCTP some addresses... saying in effect
> I would like to talk to one or some set of these
> addresses IP1, IP2, IP3.. then these addresses
> are considered "good" addresses and not an attacker..


But "good" does not imply "confirmed."  "Confirmed"
is a concept in the SCTP protocol.  It is not "clean"
to add this semantics to the call, IMHO.


> Now if the INIT-ACK comes back WITHOUT  IP3.. thats
> ok.. the association will come up...  it just will
> NOT have IP3 in it.. However.. both IP1 and IP2 should
> be considered confirmed.. and not require a confirmation
> HB..


Is the purpose of forcing a confirmation just saving
the HB?  If this is the reason, I'd say not to have
this additional meaning.  The HB exchange serves more
than confirming an address.  SCTP can get some info,
say RTT and reachability from the exchange.


-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Wed Apr 11 08:01:41 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbbVp-0006AT-UA; Wed, 11 Apr 2007 08:01:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HbbVl-00066e-Gw
	for tsvwg@ietf.org; Wed, 11 Apr 2007 08:01:17 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbbSD-0005wh-Oa
	for tsvwg@ietf.org; Wed, 11 Apr 2007 07:57:39 -0400
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id
	l3BBv6dv015925; Wed, 11 Apr 2007 11:57:06 GMT
Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50])
	by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id
	l3BBv2Uc576107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Apr 2007 04:57:05 -0700 (PDT)
Message-ID: <461CCD0D.3010607@sun.com>
Date: Wed, 11 Apr 2007 19:57:01 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Thunderbird 1.5.0.10 (X11/20070303)
MIME-Version: 1.0
To: Jan Newmarch <jan.newmarch@gmail.com>, TSWG <tsvwg@ietf.org>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<579ea40b0704110401w7ab28c13h1fa79253d49c3dae@mail.gmail.com>
In-Reply-To: <579ea40b0704110401w7ab28c13h1fa79253d49c3dae@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: SCTP Implementors <sctp-impl@external.cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Jan Newmarch wrote:

> I'm just coming at this from an apps programmer viewpoint, and would
> seek clarity about what the spec should tell me.
> 
> For connectx, I think the spec is clear enough  that all the addresses
> MUST belong to the same endpoint. If they do not, the application may
> behave in unpredictable ways. If I put in a bogus address then the app
> may work ok or may fail (and it's my fault).


Yes, I think this was the original idea.  Note that the
sctp_connectx() call itself does not and probably cannot
check whether the list of addresses actually belong to
the same host.  It may assume that.  But it seems that
people are saying that if there is no such assumption,
the connectx() (not sctp_connectx() which I assume is what
is referred above) can do more.  For example, if an app
only cares about getting some service from a list of servers,
giving the list of servers to connectx() is quite handy.

So the question here is whether the stack should assume the
list of addresses belong to the same peer or not.  I guess
a flag, as mentioned in a previous mail, may be used for
this.  And whether the stack makes use of this assumption
or not is probably implementation and protocol dependent.


> However, it goes on to say "Note that the list of addresses passed in
> is only used for setting up the association.  It does not necessarily
> equal the set of addresses  the peer uses for the resulting
> association.  If the caller wants to find out the set of peer
> addresses, it must use sctp_getpaddrs() to retrieve them after the
> association has been set up."
> 
> a) Could this be tightened up at all?
> b) Not the right forum, I know, but Linux getpaddrs() seems to have a bug
> 
> For (a) what would make sense to me would be that either
> - the set of peer addresses is the intersection of the set requested
> by connectx and the set offered by the peer (either by bind or bindx);


I don't understand this.  The set of peer addresses is
controlled by the peer.  What the app uses in the sctp_connectx()
call does not matter.  In fact, the peer does not know what
the app passes to sctp_connectx().  There is no way to have
this meaning.


> or
> - the set of peer addresses is the set offered by the peer,
> irrespective of the set requested by the client.


This is what is meant in the current draft.  The SCTP protocol
does not have the provision to force a peer to use certain set
of addresses.


> Whatever, I assume that there must be a non-zero intersection between
> the addresses in connectx and bindx. Must the set of connectx
> addresses be a subset of the addresses on the peer, or a subset of the
> addresses bound to by the peer? I'm sometimes seeing a connection to a
> peer address not in the connectx list.


I think the caller of sctp_connectx() can only assume that one
of the addresses passed in is also used by the peer for the
association, otherwise the association cannot be set up at
all :-)  This means that an app can only assume that the
intersection of the set passes to sctp_connectx() and the set
of peer addresses used for the association is not empty.



-- 

						K. Poon.
						kacheong.poon@sun.com





From tsvwg-bounces@ietf.org Wed Apr 11 08:13:39 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HbbhQ-0003tA-Gf; Wed, 11 Apr 2007 08:13:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbaa0-0001da-QI
	for tsvwg@ietf.org; Wed, 11 Apr 2007 07:01:36 -0400
Received: from wr-out-0506.google.com ([64.233.184.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbaZy-0007w5-GM
	for tsvwg@ietf.org; Wed, 11 Apr 2007 07:01:36 -0400
Received: by wr-out-0506.google.com with SMTP id i20so97847wra
	for <tsvwg@ietf.org>; Wed, 11 Apr 2007 04:01:34 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Ym+AvmBF0/rEOT0Tpe/dQFxJxuSoZUznqKG0Bu83tRyEZ2FZE9Jt+bScVN9cpPZbYf25yk3zwpwTh1gKWpQxYTe5EQ+awmbO9HeQTkcb2cFAmIvnFGKTP9Zk++CdrSp2ORkt0+BMJ9jYppzezfmNLowTBStOq62YxLCyFfwqyl4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=hp5vHWZxtxjsaDtY6R1MEufw1sFlD4KIjKy1pLThuNl1aXAe+L44VDuvjlNhYtskIpBdqwUrcbYlvjUM5BLgnKVAX7WgcNo8VfJU0ZiZLJovjYcVIOiOMm3aVv4gnZBsYCzXVeFFCjnwZGe2GzQBNQ83fJ0oX+uclVOTUQmK7wM=
Received: by 10.114.198.1 with SMTP id v1mr214807waf.1176289293672;
	Wed, 11 Apr 2007 04:01:33 -0700 (PDT)
Received: by 10.115.74.2 with HTTP; Wed, 11 Apr 2007 04:01:33 -0700 (PDT)
Message-ID: <579ea40b0704110401w7ab28c13h1fa79253d49c3dae@mail.gmail.com>
Date: Wed, 11 Apr 2007 21:01:33 +1000
From: "Jan Newmarch" <jan.newmarch@gmail.com>
To: "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
In-Reply-To: <B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
X-Mailman-Approved-At: Wed, 11 Apr 2007 08:13:19 -0400
Cc: SCTP Implementors <sctp-impl@external.cisco.com>,
	Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi

I'm just coming at this from an apps programmer viewpoint, and would
seek clarity about what the spec should tell me.

For connectx, I think the spec is clear enough  that all the addresses
MUST belong to the same endpoint. If they do not, the application may
behave in unpredictable ways. If I put in a bogus address then the app
may work ok or may fail (and it's my fault).

However, it goes on to say "Note that the list of addresses passed in
is only used for setting up the association.  It does not necessarily
equal the set of addresses  the peer uses for the resulting
association.  If the caller wants to find out the set of peer
addresses, it must use sctp_getpaddrs() to retrieve them after the
association has been set up."

a) Could this be tightened up at all?
b) Not the right forum, I know, but Linux getpaddrs() seems to have a bug

For (a) what would make sense to me would be that either
- the set of peer addresses is the intersection of the set requested
by connectx and the set offered by the peer (either by bind or bindx);
or
- the set of peer addresses is the set offered by the peer,
irrespective of the set requested by the client.

Whatever, I assume that there must be a non-zero intersection between
the addresses in connectx and bindx. Must the set of connectx
addresses be a subset of the addresses on the peer, or a subset of the
addresses bound to by the peer? I'm sometimes seeing a connection to a
peer address not in the connectx list.

b) What I am also seeing from the Linux implementation is that
getpaddrs just returns the set I asked for in connectx irrespective of
what may have been set up (including any bogus addresses I put in
connectx).

Cheers

Jan
--

On 4/11/07, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> Hi Kacheong,
>
> sctp_connectx() was invented to held in the SIGTRAN scenario, where
> you typically know all addresses of your peers in advance via
> configuration.
> Alternatively RSerPool also provides multiple addresses of one host.
> Using connnect() you can not make use of the peers multihoming. Using
> sctp_connectx() you can use this right from the beginning.
> Not sure if this is written, the sender also considers the addresses
> listed in the sctp_connectx() call as confirmed.
>
> If you receive an ABORT, response to the sctp_connectx(), you fail
> the association.
>
> Best regards
> Michael
>
> On Apr 10, 2007, at 5:55 PM, Kacheong Poon wrote:
>
> > Michael Tuexen wrote:
> >
> >> If yes, how do you react to a received RST segment in the TCP case.
> >> For SCTP, we fail the sctp_connectx() call on reception of an ABORT.
> >> This is due to the fact that in the SCTP case the host wants to
> >> use *all* addresses of the peer.
> >
> >
> > No, I don't think sctp_connectx() provides this kind of
> > semantics to the caller.  In fact, how can an app know
> > about which addresses the peer wants to use for an
> > association?  Why is this restriction necessary for an
> > SCTP app?
> >
> >
> >> For TCP this is not possible, it
> >> wants to use *one* of the addresses. It could even continue trying
> >> addresses after for one of the addresses a RST segment has been
> >> received. Therefore the restriction of all addresses belong to one
> >> host is also not necessary for TCP... Haven't thought about
> >> security implications for the TCP case.
> >
> >
> > I suppose there is a security implication for SCTP if
> > sctp_connectx() does not have the above restriction.
> > What is the issue?  So suppose an app does a for loop
> > on the list of addresses doing connect(), is there a
> > problem also?
> >
> >
> > --
> >
> >                                               K. Poon.
> >                                               kacheong.poon@sun.com
> >
> >
> >
>
>




From tsvwg-bounces@ietf.org Wed Apr 11 12:41:00 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hbfrc-0008EL-Mk; Wed, 11 Apr 2007 12:40:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbfrb-00088Z-2u
	for tsvwg@ietf.org; Wed, 11 Apr 2007 12:40:07 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbfrZ-0003ym-N7
	for tsvwg@ietf.org; Wed, 11 Apr 2007 12:40:07 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-4.cisco.com with ESMTP; 11 Apr 2007 09:40:04 -0700
X-IronPort-AV: i="4.14,395,1170662400"; 
	d="scan'208"; a="52840528:sNHT345374433"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3BGe4Rh006748; 
	Wed, 11 Apr 2007 09:40:04 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3BGe4wn012337;
	Wed, 11 Apr 2007 16:40:04 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 09:40:04 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 11 Apr 2007 09:40:03 -0700
Message-ID: <461D1004.9060501@cisco.com>
Date: Wed, 11 Apr 2007 12:42:44 -0400
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Kacheong Poon <kacheong.poon@sun.com>
Subject: Re: [Tsvwg] Re: ephemeral ports and bindx
References: <579ea40b0704012229v787db339h4ab111ae69a17325@mail.gmail.com>
	<461396B8.4090403@cisco.com> <4613D887.1030303@sun.com>
	<4613E7CE.2020407@cisco.com>
	<AB3E43E5-5B9B-45E9-BCBD-17350D897AEF@micmac.franken.de>
	<4613FBC7.3070406@cisco.com> <4613FD6D.7040908@hp.com>
	<4613FFB5.1060800@cisco.com> <46140324.8090609@hp.com>
	<40A38A45-5C91-4EB4-A2DF-5D0A246CC8BC@micmac.franken.de>
	<461408F1.8080500@hp.com>
	<AF840E80-71F7-4502-A9A8-CF2E36826CD3@micmac.franken.de>
	<461437A3.9050309@cisco.com> <46143862.8080201@hp.com>
	<B9DF6C06-C38F-4781-B272-6B346A7824B7@micmac.franken.de>
	<4614C59F.8000900@cisco.com>
	<AD9F82EA-11A1-42B4-9CBA-75AD1C188A08@micmac.franken.de>
	<461BB369.1060006@sun.com>
	<B18D5137-4CA4-4D80-A0BB-745512075A1F@lurchi.franken.de>
	<461BC843.9040809@sun.com>
	<C35C1C11-E58A-46DE-8C05-CAE05FBCE4CC@micmac.franken.de>
	<461CB8DC.4030104@sun.com> <461CBA9E.2070608@cisco.com>
	<461CC744.2010201@sun.com>
In-Reply-To: <461CC744.2010201@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Apr 2007 16:40:03.0868 (UTC)
	FILETIME=[0E16A5C0:01C77C58]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2203; t=1176309604;
	x=1177173604; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20[Tsvwg]=20Re=3A=20ephemeral=20ports=20and=20bindx
	|Sender:=20; bh=8upqEHjGl0u4grNPkXku3sCzW1cqeN3hJTn2QYa/I64=;
	b=tX6rvxwnlZI5D37s5V8RIJ0cNmG6ol6xk6cR8Xh9Rvrq2LcgqYimaFlXoxeLwaowg8gslKCo
	9KQsFwV6SdStDp7d9cOs72ggKNuA2kywnjvibtKlyyatIsgGQg9AazfQ;
Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: SCTP Implementors <sctp-impl@external.cisco.com>, jan@newmarch.name,
	TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Kacheong Poon wrote:
> Randall Stewart wrote:
> 
>> I think I agree with all you say (i.e. no such restriction
>> that the addresses all are on the same host is in
>> connectx).. however.. I disagree with the last statement.
>> If a user passes SCTP some addresses... saying in effect
>> I would like to talk to one or some set of these
>> addresses IP1, IP2, IP3.. then these addresses
>> are considered "good" addresses and not an attacker..
> 
> 
> But "good" does not imply "confirmed."  "Confirmed"
> is a concept in the SCTP protocol.  It is not "clean"
> to add this semantics to the call, IMHO.

Confirmed means the peer is not listing addresses
in its INIT/INIT-ACK that it does not own. Are you saying
that what the user lists might be an attack address, an
attack on itself?

I don't get this..

> 
> 
>> Now if the INIT-ACK comes back WITHOUT  IP3.. thats
>> ok.. the association will come up...  it just will
>> NOT have IP3 in it.. However.. both IP1 and IP2 should
>> be considered confirmed.. and not require a confirmation
>> HB..
> 
> 
> Is the purpose of forcing a confirmation just saving
> the HB?  If this is the reason, I'd say not to have
> this additional meaning.  The HB exchange serves more
> than confirming an address.  SCTP can get some info,
> say RTT and reachability from the exchange.

There may be other addresses to confirm besides the ones
given by connectx() example:

connectx(IP1, IP2, IP3)--->
                        -------INIT(IPA)--> IP1
                        IPA <---INIT-ACK(IP1, IP2, IP4, IP5, IP6, IP7)

Now IP4 - 7 NEED to be confirmed BEFORE you can use them..

IP3 gets dropped.

Why should IP2 take up time in the confirmation process.

If who you connected to is "evil" then IP4 -7 may not
belong to them.. so it is best to HB them asap.. at only
Max.Hb.Burst set to 1.. it delays possibly by 1 second
the "true unknown" addresses that were NOT listed in connectx()

Yes, we can use the HB to measure the RTT.. and that is
good.. but this is the "normal" HB that can work just as
well..

R



-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)




From tsvwg-bounces@ietf.org Sat Apr 14 01:36:04 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcavZ-0000nj-If; Sat, 14 Apr 2007 01:36:01 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HcavW-0000na-TR
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 01:35:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcavW-0000nQ-50
	for tsvwg@ietf.org; Sat, 14 Apr 2007 01:35:58 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcavU-0000Mc-MU
	for tsvwg@ietf.org; Sat, 14 Apr 2007 01:35:58 -0400
Received: from [127.0.0.1] (c1-vpn2.isi.edu [128.9.176.28])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3E5ZgGd006468;
	Fri, 13 Apr 2007 22:35:43 -0700 (PDT)
Message-ID: <4620681F.4060203@isi.edu>
Date: Fri, 13 Apr 2007 22:35:27 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [Tsvwg] port randomization
References: <20070328190335.4D3081BCC13@lawyers.icir.org>
	<200703290832.l2T8WIVO012282@venus.xmundo.net>
In-Reply-To: <200703290832.l2T8WIVO012282@venus.xmundo.net>
X-Enigmail-Version: 0.94.1.2.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigDC1C93FEF849CF409298C205"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: tsvwg@ietf.org, mallman@icir.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDC1C93FEF849CF409298C205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Fernando Gont wrote:
=2E..
> The collisions we are more concerned about are those that happen when
> the client chooses a port number for which there's a TCP in the
> TIME_WAIT state at the server (rather than "local collisions" because o=
f
> a port number being currently in use at the client side).
>=20
> The problem here is that in BSD-derived systems, if there's a collision=

> the connection attempt might timeout after 75 seconds or so (IIRC, SYN
> segments received for connections in the TIME-WAIT state with an ISN
> smaller that the last sequence number seen on the connection are
> ignored). OTOH, if the server strictly implements RFC 793, the
> connection attempt would lead to the assassination of the TIME-WAIT
> state (unless there's some spec that I missed).

Receiving a SYN in TW has two possible results:
	- if not in window, resend the last valid ACK
	- if in window, kill the TW and send a RST
		this assassinates your TW, but also ought
		to cause the other side to go into TW
		(unless the RST is lost)

		FWIW, this is another example of why RST-senders
		ought to go into TW (as Ted and I noted in our
		Infocom99 pub)

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enigDC1C93FEF849CF409298C205
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIGgfE5f5cImnZrsRAj1SAJ9xvYW8RT0CGqcX04gzAY0caN9muACg/tAl
GJT8urYiBdo6Ft1bMGOYX70=
=HUTa
-----END PGP SIGNATURE-----

--------------enigDC1C93FEF849CF409298C205--






From tsvwg-bounces@ietf.org Sat Apr 14 03:17:51 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HccW0-0000Qp-PD; Sat, 14 Apr 2007 03:17:44 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HccVz-0000Qj-Ex
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 03:17:43 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HccVz-0000Qb-5k
	for tsvwg@ietf.org; Sat, 14 Apr 2007 03:17:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HccP4-0004vb-2e
	for tsvwg@ietf.org; Sat, 14 Apr 2007 03:10:34 -0400
Received: from mxfep02.bredband.com ([195.54.107.73])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HccP1-0000aY-F8
	for tsvwg@ietf.org; Sat, 14 Apr 2007 03:10:34 -0400
Received: from ironport.bredband.com ([195.54.107.82] [195.54.107.82])
	by mxfep02.bredband.com with ESMTP
	id <20070414071030.GFMM2832.mxfep02.bredband.com@ironport.bredband.com>
	for <tsvwg@ietf.org>; Sat, 14 Apr 2007 09:10:30 +0200
Received: from c-41bce255.022-251-6c756c10.cust.bredbandsbolaget.se
	([85.226.188.65])
	by ironport.bredband.com with ESMTP; 14 Apr 2007 09:10:30 +0200
From: Anders Torger <torger@ludd.ltu.se>
To: tsvwg@ietf.org
Date: Sat, 14 Apr 2007 09:10:23 +0200
User-Agent: KMail/1.9.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200704140910.23265.torger@ludd.ltu.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
X-TMDA-Confirmed: Sat, 14 Apr 2007 03:17:43 -0400
Subject: [Tsvwg] Is there a SCTP maximum user message size?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

I'm trying to understand what the maximum user message size for SCTP is 
so I can adapt buffer management accordingly.

It seems to me that it at least theoretically can be unlimited, since 
there is no user message size tag in the protocol, just a beginning 
fragment, a number of middle fragments ant then the ending fragment.

However, implementations seem to limit the size in some way related to 
the RWND, but I guess that is only to make things practical rather than 
it really is the limit enforced directly or indirectly by the protocol 
specification?

Also, it seems to me that there is no negotiation during association 
establishment that sets the maximum user message size. This means that 
the receiving side cannot know in advance how large user messages it 
needs to accept, and the stack is not allowed to abort the association 
if a "too large user message" arrives, am I right?

Thus, is it true that if the sending side implementation supports it, it 
could send a message that never ends, and the receiving stack is 
required to accept this? Since the receiving side can deliver partial 
messages using the partial delivery API, it seems like this is a 
possible scenario (no real application would use this approach of 
course, but it could potentially be used as an attack against 
applications with poor buffer management that assumes some maximum 
size, or extend buffers until it runs out of memory).

There is however no partial sending API of what I know of, so in 
practice user messages cannot become extremely large (unless a special 
stack implementation is made), but it bugs me that for a particular 
association I cannot find out what the limit really is.

/Anders Torger






From tsvwg-bounces@ietf.org Sat Apr 14 04:15:17 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HcdPf-0006Te-Bd; Sat, 14 Apr 2007 04:15:15 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HcdPe-0006TT-EM
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 04:15:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HcdPe-0006TI-2Z
	for tsvwg@ietf.org; Sat, 14 Apr 2007 04:15:14 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcdPd-0003k9-Bm
	for tsvwg@ietf.org; Sat, 14 Apr 2007 04:15:14 -0400
Received: from [10.10.10.16] (fgrpf.plus.com [212.159.18.54])
	(authenticated bits=0)
	by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l3E8Ekjo004865
	(version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT);
	Sat, 14 Apr 2007 09:14:49 +0100 (BST)
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Sat, 14 Apr 2007 09:15:10 +0100
Subject: Re: [Tsvwg] start of WGLC for draft-ietf-tsvwg-cc-alt
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: tsvwg WG <tsvwg@ietf.org>
Message-ID: <C2464C1E.6F68%gorry@erg.abdn.ac.uk>
Thread-Topic: [Tsvwg] start of WGLC for draft-ietf-tsvwg-cc-alt
Thread-Index: Acd+bQTGQy8qS+pgEduylQAKlc/qXg==
In-Reply-To: <5A1E6DB4-9F21-4AEE-9025-F61028A3D034@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: Sally Floyd <floyd@icir.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On 10/4/07 08:12, "Lars Eggert" <lars.eggert@nokia.com> wrote:

> On 2007-4-5, at 22:50, ext tsvwg-bounces@ietf.org wrote:
>> Title  : Specifying New Congestion Control Algorithms
>> Author(s) : S. Floyd, M. Allman
>> Filename : draft-ietf-tsvwg-cc-alt-01.txt
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt
> 
> We're starting the WGLC for this draft now. Please send your reviews
> by April 24, 2007.
> 
> Lars
> 

This seems like reasonable guidance, and I'd be happy to see this published
as a BCP. I think the new sections provide good advice, A few minor NiTs are
below.

Gorry

----
1. Intro.
/for what makes for an appropriate congestion control scheme/
 ^^^^^^^^^^^^^^^^^^
- Poor use of English?
Could try:
/for what makes an appropriate congestion control scheme/
Or
/for what constitutes an appropriate congestion control scheme/
Or similar...
----
2.
  / A minimum goal for experimental mechanisms
      ^^^^^^^
    proposed for widespread deployment in the Internet should
    be that they do not perform significantly worse than TCP
    in these environments. /

- Is this really meant to read as the only essential (minimum) goal?
(eliminating the word "minimum" would help).

----
5.
/ Minimum requirements for approval for widespread deploy /
                                                  ^^^^^^^
- Should this be "deployment"?







From tsvwg-bounces@ietf.org Sat Apr 14 06:36:55 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hcfce-0003Hp-QX; Sat, 14 Apr 2007 06:36:48 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hcfcd-0003Hk-1i
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 06:36:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcfcc-0003Hc-OX
	for tsvwg@ietf.org; Sat, 14 Apr 2007 06:36:46 -0400
Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa]
	helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hcfcb-0002xj-0x
	for tsvwg@ietf.org; Sat, 14 Apr 2007 06:36:46 -0400
Received: from [192.168.1.17] (p508FF3CB.dip.t-dialin.net [80.143.243.203])
	by mail-n.franken.de (Postfix) with ESMTP id 4E1CA8006DAD;
	Sat, 14 Apr 2007 12:36:43 +0200 (CEST)
	(KNF-authenticated sender: macmic)
In-Reply-To: <200704140910.23265.torger@ludd.ltu.se>
References: <200704140910.23265.torger@ludd.ltu.se>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <38752E1F-0ED4-48D9-B50E-0A1341DE1DB1@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [Tsvwg] Is there a SCTP maximum user message size?
Date: Sat, 14 Apr 2007 12:36:41 +0200
To: Anders Torger <torger@ludd.ltu.se>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi Anders,

see my comments in-line.

Best regards
Michael

On Apr 14, 2007, at 9:10 AM, Anders Torger wrote:

> I'm trying to understand what the maximum user message size for  
> SCTP is
> so I can adapt buffer management accordingly.
>
> It seems to me that it at least theoretically can be unlimited, since
> there is no user message size tag in the protocol, just a beginning
> fragment, a number of middle fragments ant then the ending fragment.
Correct. There is no limit in the protocol.
>
> However, implementations seem to limit the size in some way related to
> the RWND, but I guess that is only to make things practical rather  
> than
> it really is the limit enforced directly or indirectly by the protocol
> specification?
What I see is that Linux and Solaris fail the send() call when the
length of the user message is larger than the send buffer size.
I do not see (and expect) a relation to the a_rwnd of the peer.
>
> Also, it seems to me that there is no negotiation during association
> establishment that sets the maximum user message size. This means that
> the receiving side cannot know in advance how large user messages it
> needs to accept, and the stack is not allowed to abort the association
> if a "too large user message" arrives, am I right?
The SCTP stack should not initiate the ABORT, but if the application
code does this, SCTP has to do it. So: you are right.
>
> Thus, is it true that if the sending side implementation supports  
> it, it
> could send a message that never ends, and the receiving stack is
> required to accept this? Since the receiving side can deliver partial
> messages using the partial delivery API, it seems like this is a
> possible scenario (no real application would use this approach of
> course, but it could potentially be used as an attack against
> applications with poor buffer management that assumes some maximum
> size, or extend buffers until it runs out of memory).
The BSD stack can send really large messages... and you are correct,
applications should do an appropriate buffer management.
>
> There is however no partial sending API of what I know of, so in
> practice user messages cannot become extremely large (unless a special
> stack implementation is made), but it bugs me that for a particular
> association I cannot find out what the limit really is.
As I said the BSD stack can send large messages. And in addition,
it supports what you call "partial sending API" and is described in
section 7.1.30 of
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-14.txt
called the explicit EOR mode. Using this mode, the user can make  
multiple
send() calls for one user message.
>
> /Anders Torger
>
>
>
>






From tsvwg-bounces@ietf.org Sat Apr 14 06:43:03 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hcfig-0006hJ-8F; Sat, 14 Apr 2007 06:43:02 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hcfie-0006h9-Mi
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 06:43:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcfie-0006h1-D7
	for tsvwg@ietf.org; Sat, 14 Apr 2007 06:43:00 -0400
Received: from [2001:240:585:2:203:6dff:fe1a:4ddc] (helo=lakerest.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcfid-00041z-3m
	for tsvwg@ietf.org; Sat, 14 Apr 2007 06:43:00 -0400
Received: from [10.1.1.11] (ibmlap [10.1.1.11])
	by lakerest.net (8.13.8/8.13.8) with ESMTP id l3EAgu2O015892;
	Sat, 14 Apr 2007 06:42:56 -0400 (EDT)
	(envelope-from randall@lakerest.net)
Message-ID: <4620B0D2.7090706@lakerest.net>
Date: Sat, 14 Apr 2007 06:45:38 -0400
From: Randall Stewart <randall@lakerest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Anders Torger <torger@ludd.ltu.se>
Subject: Re: [Tsvwg] Is there a SCTP maximum user message size?
References: <200704140910.23265.torger@ludd.ltu.se>
In-Reply-To: <200704140910.23265.torger@ludd.ltu.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Anders Torger wrote:
> I'm trying to understand what the maximum user message size for SCTP is 
> so I can adapt buffer management accordingly.
> 
> It seems to me that it at least theoretically can be unlimited, since 
> there is no user message size tag in the protocol, just a beginning 
> fragment, a number of middle fragments ant then the ending fragment.
> 
> However, implementations seem to limit the size in some way related to 
> the RWND, but I guess that is only to make things practical rather than 
> it really is the limit enforced directly or indirectly by the protocol 
> specification?

Well.. like many things this is implementation dependent. In theory
we have the partial delivery API that can be started on the receiver
this gets out of the deadlock you are referring to.

Now it USED to be that the BSD stack would only allow a message
as large as the socket send buffer. This is no longer true. You
basically can malloc a 1 Gig buffer and send it... the BSD stack
will happily get the data all across to the peer. This came about
with the implementation of EEOR mode. Which basically allows you to
do multiple writes to the same message until you indicate a MSG_EOR.
So using EEOR mode you don't even have to have a large malloc.. you can
just do multiple writes until you send a EEOR explictly.. this would
actually be ideal for something like an FTP transfer where you were
sending disk blocks.. you set EEOR mode and then write away disk
block at a time to the last read.. then on that send.. you set the
MSG_EOR. The peer of course needs to set is PARTIAL_DELIVERY_POINT down
so he wont get a large read all at once.. and he can then read and
write to the file until it sees the MSG_EOR. Of course once you
start the EEOR you cannot write a message to another stream.. and once
the PD-API starts on the receiver you pretty much are reading that
same message until its complete... defeats the multi-streaming.. if
you will.

Of course if you are using the one-2-many model you could still
get reads off other assoc's (if you have enabled the socket option..
SCTP_FRAGMENT_INTERLEAVE)... but no matter what the place where the
large message is coming from is stuck reading that one message (and
sending on the sender side too) until its all consumed.



> 
> Also, it seems to me that there is no negotiation during association 
> establishment that sets the maximum user message size. This means that 
> the receiving side cannot know in advance how large user messages it 
> needs to accept, and the stack is not allowed to abort the association 
> if a "too large user message" arrives, am I right?

Well, if the stack is written correctly it won't have that problem.
Since it will start the PD-API. Now there are some stacks that I
know of that will just abort the association if they have a limited
message size and don't support the PD-API...  but as long as
a stack supports the PD-API then this is not a problem.

For an application one would hope that you would design it with
a pretty good idea of what messages are going to be received and
what formats are coming from the peer :-D

> 
> Thus, is it true that if the sending side implementation supports it, it 
> could send a message that never ends, and the receiving stack is 
> required to accept this? 

Thats what EEOR mode does, yes... if both sides
a) set the PARTIAL_DELIVERY_POINT to 1 byte
and
b) Turn on EEOR mode.

Then by default, if they never send a MSG_EOR in any send .. they
look and smell like a stream of bytes being sent.

Each side will start the PD_API right away and from then
on that assoc will be stuck on that message until a MSG_EOR is
sent or the assoc is closed.

Since the receiving side can deliver partial
> messages using the partial delivery API, it seems like this is a 
> possible scenario (no real application would use this approach of 
> course, but it could potentially be used as an attack against 
> applications with poor buffer management that assumes some maximum 
> size, or extend buffers until it runs out of memory).

That is the whole reason you have the ability to set down the
PARTIAL_DELIVERY_POINT to some other value. For example if I am
a app and I expect no more than 10k messages, I will set the
PARTIAL_DELIVERY_POINT to 10k +1 byte. Once I have done this
I would then only receive 10k mesgs (since the stack will not
start the PD-API until 10k+1byte.. unless of course the
local socket read buffer is less than 10k.. but lets assume
it is something more sane like 200k)...

If a PD-API begins (i.e. I see a message WITHOUT the MSG_EOR and
its 10k read) then I know its an attacker.. and I can abort
the association to him.


> 
> There is however no partial sending API of what I know of, so in 
> practice user messages cannot become extremely large (unless a special 
> stack implementation is made), but it bugs me that for a particular 
> association I cannot find out what the limit really is.
No thats not true.. set EEOR mode and you have just that.. a partial
sending point.. you keep sending until you specify a MSG_EOR.

This is really no different than TCP.. except the connection can
stay up.. Look at a TCP connection as sending one message. This is
in effect what happens when you do an FTP.. the sender/recv setup
a new connection and the sender just dumps the file into it.
The receiver reads it and writes everything up to the close
into the file.. ta-da.. you have transfered the file.. The connection
in effect is one big record.

The EEOR mode lets you keep the connection up and still have these
same semantics.. if you so desire them.

Of course, as I illustrated above, there is a way to know the absolute
msg size for those wanting to write an application that takes in
no more than a set size mesg... The of course should make sure
the socket receiver buffer is at least that big.. or bigger..

R


> 
> /Anders Torger
> 
> 
> 
> 


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)





From tsvwg-bounces@ietf.org Sat Apr 14 13:29:48 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hcm4E-0007Zs-Fv; Sat, 14 Apr 2007 13:29:42 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hcm49-0007SJ-Ru
	for tsvwg-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 13:29:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcm49-0007Qx-9u
	for tsvwg@ietf.org; Sat, 14 Apr 2007 13:29:37 -0400
Received: from mxfep04.bredband.com ([195.54.107.79])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcm47-0003I6-HP
	for tsvwg@ietf.org; Sat, 14 Apr 2007 13:29:37 -0400
Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84])
	by mxfep04.bredband.com with ESMTP id
	<20070414172933.YFKZ2732.mxfep04.bredband.com@ironport2.bredband.com>
	for <tsvwg@ietf.org>; Sat, 14 Apr 2007 19:29:33 +0200
Received: from c-41bce255.022-251-6c756c10.cust.bredbandsbolaget.se
	([85.226.188.65])
	by ironport2.bredband.com with ESMTP; 14 Apr 2007 19:29:33 +0200
From: Anders Torger <torger@ludd.ltu.se>
To: Randall Stewart <randall@lakerest.net>
Subject: Re: [Tsvwg] Is there a SCTP maximum user message size?
Date: Sat, 14 Apr 2007 19:29:26 +0200
User-Agent: KMail/1.9.5
References: <200704140910.23265.torger@ludd.ltu.se>
	<4620B0D2.7090706@lakerest.net>
In-Reply-To: <4620B0D2.7090706@lakerest.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200704141929.27033.torger@ludd.ltu.se>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Thank you (and Michael) for the very informative replies.

There is still one thing that confuses me. Section 3.1.4 in the latest 
sockets api draft says:

  "If the SCTP stack is running low on buffers, it may partially deliver
   a message.  In this case, MSG_EOR will not be set, and more calls to
   recvmsg() will be necessary to completely consume the message.  Only
   one message at a time per stream can be partially delivered."

Does this mean:

 Alternative A)
   If recvmsg() returns a partial message, no other messages on the same
   *association* can be delivered until the started message delivery is
   complete. However, in the case of a one-to-many socket the delivery
   can be interleaved with message deliveries belonging to other
   associations (but only if SCTP_FRAGMENT_INTERLEAVE is on).

or

 Alternative B)
   If recvmsg() returns a partial message, no other messages on the same
   *stream* can be delivered until the started message delivery is
   complete. However, it may be interleaved by a delivery of a message
   belonging to another association (one-to-many socket with
   SCTP_FRAGMENT_INTERLEAVE activated) or another stream on the same
   association. It will not be interleaved with an unordered message on
   the same stream though.

It seems to me that 3.1.4 actually indicates B), and this is what 
confuses me, because I have read a lot of other things indicating A).

This is a quite important aspect, since B) means that an application 
needs one receive buffer per stream, while in A) it typically suffices 
with one per association.

Thus A) is more efficient on buffers (having one or 65535 inbound 
streams would not make any difference in application buffer space needs 
in most cases), however B) avoids head-of-line blocking better than A) 
does. With B) you could for example start a partial delivery of a 
message on the association before the complete message has arrived, and 
if then a message on another stream arrives in a single chunk the stack 
can deliver it immediately in the B) case, but it would have to store 
it in the A) case until the complete message for the partial delivery 
has arrived.

So the question is if it is A) or B) which is correct (or perhaps both 
are incorrect), and if it is enforced by the protocol standard or by 
the sockets API (that is if the sockets API introduce some head-of-line 
blocking cases which does not exist in the protocol).

/Anders Torger





From tsvwg-bounces@ietf.org Sun Apr 15 20:03:40 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdEgw-0005ZX-JW; Sun, 15 Apr 2007 20:03:34 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdEgv-0005ZF-QL
	for tsvwg-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 20:03:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdEgv-0005YI-GF
	for tsvwg@ietf.org; Sun, 15 Apr 2007 20:03:33 -0400
Received: from smtpout.mac.com ([17.250.248.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdEgt-00032H-5d
	for tsvwg@ietf.org; Sun, 15 Apr 2007 20:03:33 -0400
Received: from mac.com (smtpin05-en2 [10.13.10.150])
	by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id
	l3G03PiZ011404; Sun, 15 Apr 2007 17:03:25 -0700 (PDT)
Received: from [192.168.1.64] (adsl-70-231-237-202.dsl.snfc21.sbcglobal.net
	[70.231.237.202]) (authenticated bits=0)
	by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l3G03N4B016325; 
	Sun, 15 Apr 2007 17:03:24 -0700 (PDT)
In-Reply-To: <C2464C1E.6F68%gorry@erg.abdn.ac.uk>
References: <C2464C1E.6F68%gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a7a748ad54c260ca8bb5e381de2ebe85@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [Tsvwg] start of WGLC for draft-ietf-tsvwg-cc-alt
Date: Sun, 15 Apr 2007 17:03:23 -0700
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: tsvwg WG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Gorry -

> This seems like reasonable guidance, and I'd be happy to see this 
> published
> as a BCP. I think the new sections provide good advice,

Many thanks for the feedback.

> A few minor NiTs are
> below.

Thanks.  I fixed two of the nits, and left the other one as is.

> ---
> 2.
>   / A minimum goal for experimental mechanisms
>       ^^^^^^^
>     proposed for widespread deployment in the Internet should
>     be that they do not perform significantly worse than TCP
>     in these environments. /
>
> - Is this really meant to read as the only essential (minimum) goal?
> (eliminating the word "minimum" would help).

I left this one.  It does not say that this is the only essential goal, 
or the
only minimum goal...

- Sally
http://www.icir.org/floyd/






From tsvwg-bounces@ietf.org Mon Apr 16 09:54:56 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdRfR-0004ES-0E; Mon, 16 Apr 2007 09:54:53 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdRfP-0004Dc-SP
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 09:54:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRfP-0004DU-Ij
	for tsvwg@ietf.org; Mon, 16 Apr 2007 09:54:51 -0400
Received: from rwcrmhc12.comcast.net ([216.148.227.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRfP-0001nP-8H
	for tsvwg@ietf.org; Mon, 16 Apr 2007 09:54:51 -0400
Received: from [192.168.1.2]
	(c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72])
	by comcast.net (rwcrmhc12) with SMTP
	id <20070416135449m1200citube>; Mon, 16 Apr 2007 13:54:50 +0000
In-Reply-To: <E1HcNlm-0008OY-8u@megatron.ietf.org>
References: <E1HcNlm-0008OY-8u@megatron.ietf.org>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
Date: Mon, 16 Apr 2007 09:54:46 -0400
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Lou,

Thanks a lot for the fresh look at things.

> One general comment is that it seems that the objective could also  
> have been reached introducing just APP_RESOURCE and a minor  
> semantic change to Preemption Priority when the new element is  
> present.  That said, the cost of  ADMISSION element is pretty low  
> and to some degree it is a cleaner solution.

Bingo.  You hit it on the head in that we wanted something clean and  
separate from the pre-existing Preemption Priority element.

> Section 2/Section 2.1:
>
> Some (not too many) words on how you see this document impacting  
> the relationship of policy control and admission control would  
> probably be worthwhile.

Unless Francois sees it differently, I don't see any change in the  
relationship of policy control with this new element in contrast to  
other policy elements like that of rfc-3181.  However, we can state  
this explicitly in the section and perhaps stress its importance in  
selection of the form of admission control given the various models  
one can choose from.

> Section 2.1:
>    bandwidth allocation model that we term the Priority Bypass Model
>    (PBM). It is important to note that the models described and
>
> PBM is typically used for Policy Based Management.  Given that  
> you're defining a Policy object redefinition of this acronym in  
> this context is bound to lead to some confusion.

ok, we can change it from PBM to PRBM.

> Section 3.1:
>
>          +-------------+-------------+-------------+-------------+
>          |     Length                | P-Type = ADMISSION_PRI    |
>          +-------------+-------------+-------------+-------------+
>          | Flags       | M. Strategy | Error Code  | Reserved    |
>          +-------------+-------------+-------------+-------------+
>          |Adm. Priority|            Reserved                     |
>          +---------------------------+---------------------------+
>
> why 4 bytes of Reserved fields? Consistency with other policy data  
> objects isn't a requirement.

agreed, but it gives us some wiggle room in case something else  
emerges that we didn't anticipate.  I've recently seen some odd stuff  
in the Land Mobile Radio arena, via project-25, that may prompt them  
to play with one of the reserved octets on an experimental basis but  
without disrupting an existing implementation of the new policy  
element.  So, I'd rather burn the bytes now.

> Section 3.1.1:
>
> I think it would be valuable to have some words on handing of (and  
> comparability with) merge nodes that are PINs or RFC2750 enabled  
> but don't support this document.

good point.  we'll sit down and add some text to talk about this.

> Section 3.2:
>
>        ALRP Namespace (Application-Level Resource Priority Namespace):
>            16 bits (unsigned)
>
> While 16 bits seems like a big number, we have lots of examples  
> where we run out of bits.  Have you thought how you'd handle this  
> if this very turned into a real issue?  Perhaps realigning the  
> element so that Reserved precedes ALRP Namespace would be a good  
> idea to allow for future flexibility.

I have no qualms in moving the reserved field to precede the ALRP  
NameSpace (James or Francois may feel differently, so they may speak  
up on their own and provide a different perspective).  However, I  
don't think we'll have a problem with a limit of 16 bits because of  
the administrative constraints placed by [SIP-PRIORITY] to register a  
new NameSpace.  The process requires expert review, so its not a  
rubber stamp for any request.

In addition, we aligned the size to coincide with a similar field  
defined in the QSPEC document being advanced in the NSIS working  
group -- one of those rare occasions where one aligns/coordinates  
work with another working group :-).  We could have stated this  
explicitly, but I feel uncomfortable doing this in section 3 given  
that the QSPEC is still in draft form.

>            represents the position of the namespace in the "Resource-
>            Priority Namespace" IANA registry, starting with 0.  
> Creation
>            of this registry has been requested to IANA in [SIP-
>            PRIORITY].
>
> Section 3.2 and Section 5:
>
> As [SIP-PRIORITY] has been issued and IANA has completed their  
> assignments, the document should be consistent with the actual IANA  
> registry.  Also, I think you should explicitly request that IANA  
> number the namespace so there is no ambiguity or possible numbering  
> issues if the namespace were to be reordered.

ok, we'll update the sentence to indicate that IANA has already set  
up the registry.

thanks,

-ken






From tsvwg-bounces@ietf.org Mon Apr 16 10:13:43 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdRxd-0002jX-DK; Mon, 16 Apr 2007 10:13:41 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdRxc-0002jR-LK
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 10:13:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRxc-0002jJ-Bk
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:13:40 -0400
Received: from [205.234.190.117] (helo=esc91.midphase.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRxZ-0000yV-Tf
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:13:40 -0400
Received: from esc91.midphase.com ([216.246.62.14] helo=LC1.labn.net)
	by esc91.midphase.com with esmtpa (Exim 4.63)
	(envelope-from <lberger@labn.net>)
	id 1HdRxV-0005Yx-Ma; Mon, 16 Apr 2007 10:13:33 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 16 Apr 2007 10:13:33 -0400
To: ken carlberg <carlberg@g11.org.uk>
From: Lou Berger <lberger@labn.net>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
In-Reply-To: <31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
References: <E1HcNlm-0008OY-8u@megatron.ietf.org>
	<31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Message-Id: <E1HdRxc-0002jR-LK@megatron.ietf.org>
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Ken,
         See in-line responses below.

Lou
At 09:54 AM 4/16/2007, ken carlberg wrote:

>Lou,
>
>Thanks a lot for the fresh look at things.
>
>>One general comment is that it seems that the objective could also
>>have been reached introducing just APP_RESOURCE and a minor
>>semantic change to Preemption Priority when the new element is
>>present.  That said, the cost of  ADMISSION element is pretty low
>>and to some degree it is a cleaner solution.
>
>Bingo.  You hit it on the head in that we wanted something clean and
>separate from the pre-existing Preemption Priority element.
>
>>Section 2/Section 2.1:
>>
>>Some (not too many) words on how you see this document impacting
>>the relationship of policy control and admission control would
>>probably be worthwhile.
>
>Unless Francois sees it differently, I don't see any change in the
>relationship of policy control with this new element in contrast to
>other policy elements like that of rfc-3181.

I think there is subtle difference in that now allocation is being 
made based on policy.  Preemption would trigger (policy based) 
removal and then normal allocation.  Also, I think it would have been 
good for 3181 to address this point as well.

>  However, we can state
>this explicitly in the section and perhaps stress its importance in
>selection of the form of admission control given the various models
>one can choose from.

I think a few sentences is all that's needed.

>>Section 2.1:
>>    bandwidth allocation model that we term the Priority Bypass Model
>>    (PBM). It is important to note that the models described and
>>
>>PBM is typically used for Policy Based Management.  Given that
>>you're defining a Policy object redefinition of this acronym in
>>this context is bound to lead to some confusion.
>
>ok, we can change it from PBM to PRBM.
>
>>Section 3.1:
>>
>>          +-------------+-------------+-------------+-------------+
>>          |     Length                | P-Type = ADMISSION_PRI    |
>>          +-------------+-------------+-------------+-------------+
>>          | Flags       | M. Strategy | Error Code  | Reserved    |
>>          +-------------+-------------+-------------+-------------+
>>          |Adm. Priority|            Reserved                     |
>>          +---------------------------+---------------------------+
>>
>>why 4 bytes of Reserved fields? Consistency with other policy data
>>objects isn't a requirement.
>
>agreed, but it gives us some wiggle room in case something else
>emerges that we didn't anticipate.

humm.  Don't really love this approach as a new element could be 
defined then, but this isn't a big deal.  If you do keep the 4 bytes 
of reserved space, I think you should align them to give you maximum 
future flexibility.

>  I've recently seen some odd stuff
>in the Land Mobile Radio arena, via project-25, that may prompt them
>to play with one of the reserved octets on an experimental basis but
>without disrupting an existing implementation of the new policy
>element.  So, I'd rather burn the bytes now.
>
>>Section 3.1.1:
>>
>>I think it would be valuable to have some words on handing of (and
>>comparability with) merge nodes that are PINs or RFC2750 enabled
>>but don't support this document.
>
>good point.  we'll sit down and add some text to talk about this.
>
>>Section 3.2:
>>
>>        ALRP Namespace (Application-Level Resource Priority Namespace):
>>            16 bits (unsigned)
>>
>>While 16 bits seems like a big number, we have lots of examples
>>where we run out of bits.  Have you thought how you'd handle this
>>if this very turned into a real issue?  Perhaps realigning the
>>element so that Reserved precedes ALRP Namespace would be a good
>>idea to allow for future flexibility.
>
>I have no qualms in moving the reserved field to precede the ALRP
>NameSpace (James or Francois may feel differently, so they may speak
>up on their own and provide a different perspective).  However, I
>don't think we'll have a problem with a limit of 16 bits because of
>the administrative constraints placed by [SIP-PRIORITY] to register a
>new NameSpace.

again, this is about future flexibility...

>The process requires expert review, so its not a
>rubber stamp for any request.
>
>In addition, we aligned the size to coincide with a similar field
>defined in the QSPEC document being advanced in the NSIS working
>group -- one of those rare occasions where one aligns/coordinates
>work with another working group :-).  We could have stated this
>explicitly, but I feel uncomfortable doing this in section 3 given
>that the QSPEC is still in draft form.
>
>>            represents the position of the namespace in the "Resource-
>>            Priority Namespace" IANA registry, starting with 0.
>>Creation
>>            of this registry has been requested to IANA in [SIP-
>>            PRIORITY].
>>
>>Section 3.2 and Section 5:
>>
>>As [SIP-PRIORITY] has been issued and IANA has completed their
>>assignments, the document should be consistent with the actual IANA
>>registry.  Also, I think you should explicitly request that IANA
>>number the namespace so there is no ambiguity or possible numbering
>>issues if the namespace were to be reordered.
>
>ok, we'll update the sentence to indicate that IANA has already set
>up the registry.

This was a trick question/comment!  Unless I missed it, the IANA 
registry doesn't match what was requested in [SIP-PRIORITY].

Lou

>thanks,
>
>-ken
>
>
>






From tsvwg-bounces@ietf.org Mon Apr 16 10:34:37 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdSHs-0001vS-Cx; Mon, 16 Apr 2007 10:34:36 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdSHr-0001vC-JK
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 10:34:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSHr-0001v3-9Y
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:34:35 -0400
Received: from alnrmhc13.comcast.net ([206.18.177.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSHq-0001ZT-1a
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:34:35 -0400
Received: from [192.168.1.2]
	(c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72])
	by comcast.net (alnrmhc13) with SMTP
	id <20070416143433b1300jof6te>; Mon, 16 Apr 2007 14:34:33 +0000
In-Reply-To: <31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
References: <E1HcNlm-0008OY-8u@megatron.ietf.org>
	<31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A840FAA8-B777-409E-B667-D7FFDD2A2DAF@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
Date: Mon, 16 Apr 2007 10:34:30 -0400
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

> I think there is subtle difference in that now allocation is being  
> made based on policy.  Preemption would trigger (policy based)  
> removal and then normal allocation.  Also, I think it would have  
> been good for 3181 to address this point as well.

ok, understood.

>>> As [SIP-PRIORITY] has been issued and IANA has completed their
>>> assignments, the document should be consistent with the actual IANA
>>> registry.  Also, I think you should explicitly request that IANA
>>> number the namespace so there is no ambiguity or possible numbering
>>> issues if the namespace were to be reordered.
>>
>> ok, we'll update the sentence to indicate that IANA has already set
>> up the registry.
>
> This was a trick question/comment!  Unless I missed it, the IANA  
> registry doesn't match what was requested in [SIP-PRIORITY].

that will teach me to assume things have been done :-).  I can only  
imagine that the registry hasn't been set up yet because there have  
been no requests for new NameSpaces.  However, one would think that  
the registry would exist to reflect existing values defined in  
RFC-4412.  Perhaps James (as the co-author of this draft and  
rfc-4412) needs to chase this down.  One way or another, the registry  
based on rfc-4412 needs to exist.

As a side note, and probably something that needs a comment from the  
Chairs/ADs, is that our IANA Considerations does not request a  
registry for a numeric representation of a NameSpace correlating to  
that requested rfc-4412.  This request is in the QSPEC, which has  
been in draft form for a while (they are on version 16 at present) as  
well as on Last Call for months.  Do we wait for the QSPEC or do we  
make the request ourselves and see who finishes first?

-ken






From tsvwg-bounces@ietf.org Mon Apr 16 10:53:49 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdSaR-0000Vz-RI; Mon, 16 Apr 2007 10:53:47 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdSaQ-0000Vj-2x
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 10:53:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSaP-0000Vb-Pm
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:53:45 -0400
Received: from amer-mta07.csc.com ([20.137.52.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSaO-00080D-Du
	for tsvwg@ietf.org; Mon, 16 Apr 2007 10:53:45 -0400
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245])
	by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	l3GEr2WR000736; Mon, 16 Apr 2007 10:53:02 -0400 (EDT)
In-Reply-To: <A840FAA8-B777-409E-B667-D7FFDD2A2DAF@g11.org.uk>
To: ken carlberg <carlberg@g11.org.uk>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF9DD34732.57837496-ON852572BF.00517B4A-852572BF.0051BF2D@csc.com>
Date: Mon, 16 Apr 2007 10:52:51 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1
	HF16|January 29, 2007) at 04/16/2007 10:51:40 AM,
	Serialize complete at 04/16/2007 10:51:40 AM
Content-Type: multipart/alternative;
	boundary="=_alternative 0051BEB2852572BF_="
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is a multipart message in MIME format.
--=_alternative 0051BEB2852572BF_=
Content-Type: text/plain; charset="US-ASCII"

ken carlberg <carlberg@g11.org.uk> wrote on 04/16/2007 10:34:30 AM:


> that will teach me to assume things have been done :-).  I can only 
> imagine that the registry hasn't been set up yet because there have 
> been no requests for new NameSpaces.  However, one would think that 
> the registry would exist to reflect existing values defined in 
> RFC-4412.  Perhaps James (as the co-author of this draft and 
> rfc-4412) needs to chase this down.  One way or another, the registry 
> based on rfc-4412 needs to exist.
>
James has an ID which will request a number of new namespaces.
draft-polk-sip-rph-new-namespaces-00
So if it has not been addressed yet, it soon will be. 

Janet

--=_alternative 0051BEB2852572BF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=2><tt>ken carlberg &lt;carlberg@g11.org.uk&gt; wrote on
04/16/2007 10:34:30 AM:<br>
<br>
<br>
&gt; that will teach me to assume things have been done :-). &nbsp;I can
only &nbsp;<br>
&gt; imagine that the registry hasn't been set up yet because there have
&nbsp;<br>
&gt; been no requests for new NameSpaces. &nbsp;However, one would think
that &nbsp;<br>
&gt; the registry would exist to reflect existing values defined in &nbsp;<br>
&gt; RFC-4412. &nbsp;Perhaps James (as the co-author of this draft and
&nbsp;<br>
&gt; rfc-4412) needs to chase this down. &nbsp;One way or another, the
registry &nbsp;<br>
&gt; based on rfc-4412 needs to exist.<br>
&gt;</tt></font>
<br><font size=2><tt>James has an ID which will request a number of new
namespaces.</tt></font>
<br><font size=2><tt>draft-polk-sip-rph-new-namespaces-00</tt></font>
<br><font size=2><tt>So if it has not been addressed yet, it soon will
be. </tt></font>
<br>
<br><font size=2><tt>Janet<br>
</tt></font>
--=_alternative 0051BEB2852572BF_=--





From tsvwg-bounces@ietf.org Mon Apr 16 14:03:07 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HdVXZ-000602-NY; Mon, 16 Apr 2007 14:03:01 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HdVXZ-0005yo-35
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 14:03:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVXX-0005yQ-JE
	for tsvwg@ietf.org; Mon, 16 Apr 2007 14:03:00 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVXW-0005sH-63
	for tsvwg@ietf.org; Mon, 16 Apr 2007 14:02:59 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 16 Apr 2007 11:02:57 -0700
X-IronPort-AV: i="4.14,415,1170662400"; 
	d="scan'208"; a="411978834:sNHT50543896"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3GI2vDO026370; 
	Mon, 16 Apr 2007 11:02:57 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3GI2RxH004599;
	Mon, 16 Apr 2007 18:02:53 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 16 Apr 2007 11:02:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] port randomization
Date: Mon, 16 Apr 2007 11:02:48 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC58032F484A@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4620681F.4060203@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tsvwg] port randomization
Thread-Index: Acd+VtnDn5MgeeKsQi6pG57Jrw9/0AB9yqtg
From: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
To: "Joe Touch" <touch@ISI.EDU>, "Fernando Gont" <fernando@gont.com.ar>
X-OriginalArrivalTime: 16 Apr 2007 18:02:49.0288 (UTC)
	FILETIME=[71C65C80:01C78051]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2306; t=1176746577;
	x=1177610577; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=ananth@cisco.com;
	z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20<ananth@cisco.com>
	|Subject:=20RE=3A=20[Tsvwg]=20port=20randomization |Sender:=20;
	bh=WHFwaNeAYSdi3AbAxAZ0btg9LfJ5fG19jZkbI7XJsjA=;
	b=POkehRi0Ejl90ApImpl+R8YfG/oxElAR+Rn4yEeItJ9AMG3jUWyaKVzsGUkoixg9Msf0gi1H
	xcMqYotoD9iXzT/lBABS4I1TsE8zYPPvPczTqb96Adi2khY/54HtcEsp;
Authentication-Results: sj-dkim-6; header.From=ananth@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: tsvwg@ietf.org, mallman@icir.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

> Fernando Gont wrote:
> ...
> > The collisions we are more concerned about are those that=20
> happen when=20
> > the client chooses a port number for which there's a TCP in the=20
> > TIME_WAIT state at the server (rather than "local=20
> collisions" because=20
> > of a port number being currently in use at the client side).
> >=20
> > The problem here is that in BSD-derived systems, if there's a=20
> > collision the connection attempt might timeout after 75=20
> seconds or so=20
> > (IIRC, SYN segments received for connections in the TIME-WAIT state=20
> > with an ISN smaller that the last sequence number seen on the=20
> > connection are ignored). OTOH, if the server strictly=20
> implements RFC=20
> > 793, the connection attempt would lead to the assassination of the=20
> > TIME-WAIT state (unless there's some spec that I missed).
>=20

> Receiving a SYN in TW has two possible results:
> 	- if not in window, resend the last valid ACK

Which would cause the other side to Reset , since :

 If the state is SYN-SENT then

      first check the ACK bit

        If the ACK bit is set

          If SEG.ACK =3D< ISS, or SEG.ACK > SND.NXT, send a reset =
(unless
          the RST bit is set, if so drop the segment and return)

            <SEQ=3DSEG.ACK><CTL=3DRST>

          and discard the segment.  Return.
=20

> 	- if in window, kill the TW and send a RST
> 		this assassinates your TW, but also ought
> 		to cause the other side to go into TW
> 		(unless the RST is lost)

Hmm.. The other side is in SYNSENT state, so receiving an RST would tear
down the connection. So the other side wouldn't go to TIMEWAIT unless
you are proposing to change the TCP state diagram, adding an arc from
SYNSENT to TIMEWAIT :-)

If we follow RFC 793 strictly, it would lead to Timewait assasination in
both the cases, unless a stack implements what BSD does as Fernando
pointed out, situation is slightly different.=20

>=20
> 		FWIW, this is another example of why RST-senders
> 		ought to go into TW (as Ted and I noted in our
> 		Infocom99 pub)

Ok, if the particular stack in question implements the suggestions
outlined above, may be things are different, but as it stands today (per
RFC) it causes TIMEWAIT assasination.

-Anantha





From tsvwg-bounces@ietf.org Wed Apr 18 06:16:28 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1He7D6-00018Q-3Y; Wed, 18 Apr 2007 06:16:24 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1He7D4-000189-4R
	for tsvwg-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 06:16:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1He7D3-00017w-Pz
	for tsvwg@ietf.org; Wed, 18 Apr 2007 06:16:21 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7D2-0000Mz-8n
	for tsvwg@ietf.org; Wed, 18 Apr 2007 06:16:21 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	93818208E1
	for <tsvwg@ietf.org>; Wed, 18 Apr 2007 12:16:19 +0200 (CEST)
X-AuditID: c1b4fb3c-a8cebbb0000073d5-83-4625eff3a762 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	88E7B208D4
	for <tsvwg@ietf.org>; Wed, 18 Apr 2007 12:16:19 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 12:13:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Apr 2007 12:11:41 +0200
Message-ID: <026F8EEDAD2C4342A993203088C1FC0504CCDD55@esealmw109.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ECN and unreliable transport
Thread-Index: AceBofVr3EbkzUt2QiqkiVqdY5D31A==
From: "Ingemar Johansson S \(LU/EAB\)" <ingemar.s.johansson@ericsson.com>
To: <tsvwg@ietf.org>
X-OriginalArrivalTime: 18 Apr 2007 10:13:15.0677 (UTC)
	FILETIME=[2DD1FCD0:01C781A2]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Tsvwg] ECN and unreliable transport
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi

I wonder if there is any specific work ongoing with regards to ECN for =
unreliable transport such as UDP. I've seen that this is mentioned every =
here and there but I have not sofar seen any specific reports on this =
matter.
Any help on this subject is much appreciated.

Regards
Ingemar
*******************************************
Ingemar Johansson
Senior Research Engineer
EAB/TVP - Multimedia Technologies Ericsson Research
Ericsson AB
Box 920
S-971 28 Lule=E5, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
Mobile: +46 (0)730 783289
MSN: ingemarjohansson1965@hotmail.com
*******************************************
=20





From tsvwg-bounces@ietf.org Wed Apr 18 11:18:57 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeBvq-0000gz-H0; Wed, 18 Apr 2007 11:18:54 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HeBvp-0000gs-6O
	for tsvwg-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 11:18:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBvo-0000gk-TA
	for tsvwg@ietf.org; Wed, 18 Apr 2007 11:18:52 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBvn-0002d7-AG
	for tsvwg@ietf.org; Wed, 18 Apr 2007 11:18:52 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	AEBE32061F
	for <tsvwg@ietf.org>; Wed, 18 Apr 2007 17:18:50 +0200 (CEST)
X-AuditID: c1b4fb3c-a7ce9bb0000073d5-84-462636da80ae 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	928E62042E
	for <tsvwg@ietf.org>; Wed, 18 Apr 2007 17:18:50 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 17:18:50 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 18 Apr 2007 17:18:50 +0200
Message-ID: <462636D9.9090607@ericsson.com>
Date: Wed, 18 Apr 2007 17:18:49 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02
References: <4607D8E9.6090300@ericsson.com>
In-Reply-To: <4607D8E9.6090300@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2007 15:18:50.0067 (UTC)
	FILETIME=[DDF7E230:01C781CC]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Magnus Westerlund skrev:
> This announces the start of the WG last call of "Resource ReSerVation 
> Protovol (RSVP) Extensions for Emergency Services" with the intended 
> status of proposed standard:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-02.txt
> 
> Please provide positive or negative feedback before the 13th of April.
> 

Hi,

This WG last call has now ended. Authors please produce an updated 
version to address the comments that come in. If there are still some 
issues where there isn't consensus please continue the discussion.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------





From tsvwg-bounces@ietf.org Wed Apr 18 12:57:07 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeDSr-0003dz-QW; Wed, 18 Apr 2007 12:57:05 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HeDSk-0003Xc-C7
	for tsvwg-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 12:56:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSj-0003Wt-NR
	for tsvwg@ietf.org; Wed, 18 Apr 2007 12:56:57 -0400
Received: from smtpout.mac.com ([17.250.248.174])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDQq-00027p-EJ
	for tsvwg@ietf.org; Wed, 18 Apr 2007 12:55:02 -0400
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id
	l3IGspFe010163; Wed, 18 Apr 2007 09:54:51 -0700 (PDT)
Received: from [192.168.1.64] (adsl-70-231-246-188.dsl.snfc21.sbcglobal.net
	[70.231.246.188]) (authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3IGsorx004000; 
	Wed, 18 Apr 2007 09:54:50 -0700 (PDT)
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504CCDD55@esealmw109.eemea.ericsson.se>
References: <026F8EEDAD2C4342A993203088C1FC0504CCDD55@esealmw109.eemea.ericsson.se>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <ce889b32429bf04d5f44911a169ae539@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [Tsvwg] ECN and unreliable transport
Date: Wed, 18 Apr 2007 09:54:49 -0700
To: "Ingemar Johansson S (LU/EAB)" <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

> I wonder if there is any specific work ongoing with regards to ECN for 
> unreliable transport such as UDP. I've seen that this is mentioned 
> every here and there but I have not sofar seen any specific reports on 
> this matter.
> Any help on this subject is much appreciated.

My own assumption is that ECN will be of great benefit for unreliable 
transport;
ECN is used the the new unreliable transport protocol DCCP
("http://www.read.cs.ucla.edu/dccp/").

However, my own view is that it would not be wise to add ECN to UDP at 
this time;
this is discussed in Section 3.1.2 of RFC 4336 
("http://www.ietf.org/rfc/rfc4336.txt").

- Sally
http://www.icir.org/floyd/






From tsvwg-bounces@ietf.org Thu Apr 19 02:42:15 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HeQLL-00023C-Jg; Thu, 19 Apr 2007 02:42:11 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HeQLK-000234-Ev
	for tsvwg-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 02:42:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQLK-00022r-4m
	for tsvwg@ietf.org; Thu, 19 Apr 2007 02:42:10 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeQLI-0000SQ-4f
	for tsvwg@ietf.org; Thu, 19 Apr 2007 02:42:10 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	DF16C20A13; Thu, 19 Apr 2007 08:42:06 +0200 (CEST)
X-AuditID: c1b4fb3c-a94ecbb0000073d5-9f-46270f3ecb61 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	CC4DA20A06; Thu, 19 Apr 2007 08:42:06 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 19 Apr 2007 08:42:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] ECN and unreliable transport
Date: Thu, 19 Apr 2007 08:42:05 +0200
Message-ID: <026F8EEDAD2C4342A993203088C1FC0504CCE439@esealmw109.eemea.ericsson.se>
In-Reply-To: <ce889b32429bf04d5f44911a169ae539@mac.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tsvwg] ECN and unreliable transport
Thread-Index: AceB2k1GL8WZM0p7TfqQ+kK+MsylaQAccxjw
From: "Ingemar Johansson S \(LU/EAB\)" <ingemar.s.johansson@ericsson.com>
To: "Sally Floyd" <sallyfloyd@mac.com>
X-OriginalArrivalTime: 19 Apr 2007 06:42:06.0637 (UTC)
	FILETIME=[D8E5A5D0:01C7824D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi

Thanks for the reply, regarding the opinion about ECN for UDP. Read
section 3.2.1 in RFC4336 and  the arguments against this usage are=20

UDP sockets: While I agree that this might be a issue for 3rd party
implemenetations running in a particular OS (Windows, Linux..) it does
not need to be a problem in e.g a mobile terminal.

Feedback: If the socket issue is solved I agree that there is no ECN
specific feedback for UDP, one could however base RTCP feedback on this
but this will probably be very easy to cheat. For walled garden
approaches such as IMS I beleieve that this is a smaller problem
however. I can agree that this is only a second best approach but it
seems to me that the industry is _very_ fond of UDP so a design that can
make use of ECN would actually be good even though it is not 100% idiot
proof.

Agree that the design of a new clean transport protocol would be alot
better though...

Ingemar
 =20

> -----Original Message-----
> From: Sally Floyd [mailto:sallyfloyd@mac.com]=20
> Sent: den 18 april 2007 18:55
> To: Ingemar Johansson S (LU/EAB)
> Cc: tsvwg@ietf.org
> Subject: Re: [Tsvwg] ECN and unreliable transport
>=20
> > I wonder if there is any specific work ongoing with regards=20
> to ECN for=20
> > unreliable transport such as UDP. I've seen that this is mentioned=20
> > every here and there but I have not sofar seen any specific=20
> reports on=20
> > this matter.
> > Any help on this subject is much appreciated.
>=20
> My own assumption is that ECN will be of great benefit for=20
> unreliable transport; ECN is used the the new unreliable=20
> transport protocol DCCP ("http://www.read.cs.ucla.edu/dccp/").
>=20
> However, my own view is that it would not be wise to add ECN=20
> to UDP at this time; this is discussed in Section 3.1.2 of=20
> RFC 4336 ("http://www.ietf.org/rfc/rfc4336.txt").
>=20
> - Sally
> http://www.icir.org/floyd/
>=20
>=20





From tsvwg-bounces@ietf.org Fri Apr 20 05:58:22 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hepsh-0006pY-GY; Fri, 20 Apr 2007 05:58:19 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hepsg-0006pA-3N
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:58:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hepsf-0006p1-Pt; Fri, 20 Apr 2007 05:58:17 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hepse-0003Nb-05; Fri, 20 Apr 2007 05:58:17 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3K9vrwI024175; Fri, 20 Apr 2007 12:58:09 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 12:57:48 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 12:57:48 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by
	esebh101.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:57:47 +0300
Received: from [10.183.156.223] (essapo-nirac253236.europe.nokia.com
	[10.162.253.236])
	by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3K9vjvY013040; Fri, 20 Apr 2007 12:57:46 +0300
In-Reply-To: <0260FF1D-E29B-4D91-991D-612E77F53970@nokia.com>
References: <26B285A9-3D4C-43B1-9C32-37EBC4AF39BE@nokia.com>
	<0260FF1D-E29B-4D91-991D-612E77F53970@nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--960130484;
	protocol="application/pkcs7-signature"
Message-Id: <36B3B805-BCD5-4490-9F5F-87BC56FC5453@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Fri, 20 Apr 2007 12:57:28 +0300
To: TSV Area <tsv-area@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 20 Apr 2007 09:57:47.0794 (UTC)
	FILETIME=[5995C720:01C78332]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: iccrg@cs.ucl.ac.uk, tsvwg WG <tsvwg@ietf.org>
Subject: [Tsvwg] Re: [tsv-area] consensus call: bringing new congestion
	control to the IETF
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: TSV Area <tsv-area@ietf.org>
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-14--960130484
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 2007-4-6, at 11:01, ext Lars Eggert wrote:
> after the presentation at TSVAREA, there was strong consensus in  
> the room for the presented process to bring new congestion control  
> to the IETF. I'd like to confirm that the community as a whole has  
> consensus on this.
>
> Please take a look at the following draft ION, which describes the  
> process from the presentation: http://www.ietf.org/IESG/content/ 
> ions/drafts/ion-tsv-alt-cc.txt
>
> The consensus call will run until April 18, 2007. Please review the  
> draft ION and send comments by the deadline.

I have seen very few comments during this consensus call, but all  
where positive. Together with the strong positive feedback from  
Prague, my take is that we have community consensus on this  
procedure. If you think I'm misjudging the consensus, please yell.

Lars



--Apple-Mail-14--960130484
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjAwOTU3MjlaMCMGCSqGSIb3DQEJBDEWBBS0cwI1bRoWn6jB
WhTJpj0EoUxQXzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAXvbpWRo+PBTY2rDiWbK/uklwZdak4winPrrEdBPGQGFF3J4ixzwp
Yhh+3xdjZSQAKnuQQ2fM5FJ+FI+CvkwrVs2Bu03XHk5itNqVJVACQ9yCKCFbnmHfl9GrZhhiHRJH
CI70x1Epm3pw8HDCmR/pqhx/bXOyy/Qek0uDvSEy8K2x0ILCjpAwThuLb0SIhHeyyQ7rrlveYbKk
Q5PO0pFlzxtU5FUu/wuOrxPkgKKgEIClAp7j3IT4oo04aEs9rRgROi/DyVQ1LZIPYic08WepP8Hr
NWGDMG9emsQRidWSSsSHaBywjxBHUrreXcZknmA0Dy1RSwPK0Ua5osE1I86EYwAAAAAAAA==

--Apple-Mail-14--960130484--





From tsvwg-bounces@ietf.org Fri Apr 20 07:18:25 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Her8A-000628-QK; Fri, 20 Apr 2007 07:18:22 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Her89-000621-9F
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 07:18:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Her88-00061t-W1
	for tsvwg@ietf.org; Fri, 20 Apr 2007 07:18:20 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Her87-0002px-7W
	for tsvwg@ietf.org; Fri, 20 Apr 2007 07:18:20 -0400
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	9B2F420BC9
	for <tsvwg@ietf.org>; Fri, 20 Apr 2007 13:18:18 +0200 (CEST)
X-AuditID: c1b4fb3c-a94ecbb0000073d5-02-4628a17a75d7 
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	8635820494
	for <tsvwg@ietf.org>; Fri, 20 Apr 2007 13:18:18 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 13:18:18 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Apr 2007 13:18:18 +0200
Message-ID: <4628A17A.7050503@ericsson.com>
Date: Fri, 20 Apr 2007 13:18:18 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Apr 2007 11:18:18.0334 (UTC)
	FILETIME=[98CFAFE0:01C7833D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Tsvwg] Adopting draft-eggert-tsvwg-udp-guidelines as WG item?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

TSVWG participants,

The author of "UDP Usage Guidelines for Application Designers" 
(draft-eggert-tsvwg-udp-guidelines) request that this is adopted as WG 
item. The other chairs support this as we think the IETF can greatly 
benefit from having the guidance on how to utilize UDP. It is also 
important that a document that provide guidance on usage of UDP have 
area wide consensus. So please comment if you think adopting this 
document in TSVWG is a good or bad idea. Do also indicate if you are 
willing to review such a document during its development.

Please provide any comments at the latest the 4th of May.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------





From tsvwg-bounces@ietf.org Fri Apr 20 15:35:05 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Heysi-0003Ix-Rw; Fri, 20 Apr 2007 15:34:56 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Heysh-0003Iq-Hc
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 15:34:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Heysh-0003If-86
	for tsvwg@ietf.org; Fri, 20 Apr 2007 15:34:55 -0400
Received: from smtpout.mac.com ([17.250.248.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heyse-0004bi-RX
	for tsvwg@ietf.org; Fri, 20 Apr 2007 15:34:55 -0400
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id
	l3KJYiVx004325; Fri, 20 Apr 2007 12:34:44 -0700 (PDT)
Received: from [192.168.1.64] (adsl-70-231-246-188.dsl.snfc21.sbcglobal.net
	[70.231.246.188]) (authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3KJYh1D024006; 
	Fri, 20 Apr 2007 12:34:43 -0700 (PDT)
In-Reply-To: <4628A17A.7050503@ericsson.com>
References: <4628A17A.7050503@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <dddbc780ede9a696db1294c9e6f2b00f@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [Tsvwg] Adopting draft-eggert-tsvwg-udp-guidelines as WG item?
Date: Fri, 20 Apr 2007 12:34:42 -0700
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

I looked at the diffs, and I think that adopting this document in
TSVWG is a good idea.

(I also wandered across the tool at tools.ietf.org for looking
at the diffs between different internet-drafts.  I think it is great!
"http://tools.ietf.org/html/draft-eggert-tsvwg-udp-guidelines-02".)

- Sally
http://www.icir.org/floyd/






From tsvwg-bounces@ietf.org Mon Apr 23 04:56:01 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HfuKv-0004Vz-03; Mon, 23 Apr 2007 04:55:53 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HfuKt-0004Vo-Sh
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 04:55:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HfuKt-0004Vd-I6
	for tsvwg@ietf.org; Mon, 23 Apr 2007 04:55:51 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfuKr-0002HV-61
	for tsvwg@ietf.org; Mon, 23 Apr 2007 04:55:50 -0400
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l3N8tmqK002850
	for <tsvwg@ietf.org>; Mon, 23 Apr 2007 10:55:48 +0200
Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net
	[139.25.131.193])
	by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3N8tkqp012360
	for <tsvwg@ietf.org>; Mon, 23 Apr 2007 10:55:47 +0200
Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by
	mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 10:55:47 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Apr 2007 10:55:48 +0200
Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A6181D@MCHP7R6A.ww002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Diameter QoS
Thread-Index: AceFhS/Tzuuj9Lf9ShyGkq3B3AYA4g==
From: "Tschofenig, Hannes" <hannes.tschofenig@nsn.com>
To: <tsvwg@ietf.org>
X-OriginalArrivalTime: 23 Apr 2007 08:55:47.0556 (UTC)
	FILETIME=[2F63C240:01C78585]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Subject: [Tsvwg] Diameter QoS
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Hi all,=20

there is work ongoing in the IETF DIME working group on defining a
Diameter application for Quality of Service. The document can be found
at:=20
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-00.txt

We would like to solicit feedback from the TSVWG working group regarding
the applicability of the document to perform authorization decisions for
RSVP.

Ciao
Hannes





From tsvwg-bounces@ietf.org Mon Apr 23 06:44:18 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hfw1o-0008Jy-MP; Mon, 23 Apr 2007 06:44:16 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hfw1n-0008JE-Bz
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:44:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfw1n-0008J6-2S
	for tsvwg@ietf.org; Mon, 23 Apr 2007 06:44:15 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfw1k-0005D2-N4
	for tsvwg@ietf.org; Mon, 23 Apr 2007 06:44:15 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 23 Apr 2007 12:44:10 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3NAi9Mn003619; 
	Mon, 23 Apr 2007 12:44:09 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com
	[144.254.231.87])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3NAi9lb013419; 
	Mon, 23 Apr 2007 10:44:09 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by
	xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 23 Apr 2007 12:44:05 +0200
Received: from [10.0.0.3] ([10.61.81.242]) by xfe-ams-331.emea.cisco.com with
	Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 12:44:04 +0200
In-Reply-To: <31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
References: <E1HcNlm-0008OY-8u@megatron.ietf.org>
	<31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <400EFFCA-A988-4028-AF48-77FD52834102@cisco.com>
Content-Transfer-Encoding: 7bit
From: Francois Le Faucheur IMAP <flefauch@cisco.com>
Subject: Unrecognized Policy Element Re: [Tsvwg] WG last call of
	draft-ietf-tsvwg-emergency-rsvp-02
Date: Mon, 23 Apr 2007 12:41:36 +0200
To: ken carlberg <carlberg@g11.org.uk>, Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 23 Apr 2007 10:44:04.0973 (UTC)
	FILETIME=[5026E9D0:01C78594]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1614; t=1177325049;
	x=1178189049; c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=flefauch@cisco.com;
	z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco.com>
	|Subject:=20Unrecognized=20Policy=20Element=20Re=3A=20[Tsvwg]=20WG=20last
	=20call=20of=20draft-ietf-tsvwg-emergency-rsvp-02 |Sender:=20;
	bh=J6jrf1DEO4Um0hMJpSlxqroxi6mr0qyq6FAhItQOIV4=;
	b=jvjvZf3iK0vmbuw06eKTh2pkqnNvxQGE+RPUuK71AjubUwfBTA3Wd/MQMVtv9SmtoRasokis
	sJ2JxG188nCANItwjIdCDHb1CrryUZtmMTfuERRvKwPV9YbkmNwxP+2N;
Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: tsvwg tsvwg <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Lou, Ken,

>
>> Section 3.1.1:
>>
>> I think it would be valuable to have some words on handing of (and  
>> comparability with) merge nodes that are PINs or RFC2750 enabled  
>> but don't support this document.
>
> good point.  we'll sit down and add some text to talk about this.
>

I think both the case of a (i) Policy-Ignorant-Node (PIN) and of a  
(ii) policy-capable-node that is not aware of a new Policy Element,  
are already covered appropriately in section " 4.2 Default Handling  
for PIN nodes" of RFC2750. (ie forward as is, concatenate upstream  
with multicast, copy downstream with multicast).

BTW, this would also apply to the ALRP Policy Element defined in 3.2,  
right?

So how about we add a section "3.3 Default Handling" that says  
something like:
"
As specified in section 4.2 of RFC2750, Policy Ignorant Nodes (PINs)  
implement a default handling of POLICY_DATA objects ensuring that  
those objects can traverse PIN nodes in transit from one PEP to  
another. This applies to the situations where POLICY_DATA objects  
contain the Admission Priority Policy Element and the ALRP Policy  
Element specified in this document, so that those can traverse PIN  
nodes.

Section 4.2 of RFC2750 also defines a similar default behavior for  
policy-capable nodes that do not recognized a particular Policy  
Element. This applies to the Admission Priority Policy Element and  
the ALRP Policy Element specified in this document, so that those can  
traverse policy-capable nodes that do not support this document.
"

Does that work?

Francois


  





From tsvwg-bounces@ietf.org Mon Apr 23 12:14:53 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg1Bi-0005ys-UZ; Mon, 23 Apr 2007 12:14:50 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hg1Bh-0005yk-6x
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 12:14:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1Bg-0005yc-Tk
	for tsvwg@ietf.org; Mon, 23 Apr 2007 12:14:48 -0400
Received: from [205.234.190.117] (helo=esc91.midphase.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1Bf-00029G-L1
	for tsvwg@ietf.org; Mon, 23 Apr 2007 12:14:48 -0400
Received: from esc91.midphase.com ([216.246.62.14] helo=LC1.labn.net)
	by esc91.midphase.com with esmtpa (Exim 4.63)
	(envelope-from <lberger@labn.net>)
	id 1Hg1BI-0006Vo-2Q; Mon, 23 Apr 2007 12:14:24 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 23 Apr 2007 12:11:40 -0400
To: Francois Le Faucheur IMAP <flefauch@cisco.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Unrecognized Policy Element Re: [Tsvwg] WG last call of
	draft-ietf-tsvwg-emergency-rsvp-02
In-Reply-To: <400EFFCA-A988-4028-AF48-77FD52834102@cisco.com>
References: <E1HcNlm-0008OY-8u@megatron.ietf.org>
	<31A09FD8-E9CA-4B78-AADB-07C4E5088174@g11.org.uk>
	<400EFFCA-A988-4028-AF48-77FD52834102@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Message-Id: <E1Hg1Bh-0005yk-6x@megatron.ietf.org>
Cc: tsvwg tsvwg <tsvwg@ietf.org>, ken carlberg <carlberg@g11.org.uk>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

Francois,

         See below.

At 06:41 AM 4/23/2007, Francois Le Faucheur IMAP wrote:

>Lou, Ken,
>
>>
>>>Section 3.1.1:
>>>
>>>I think it would be valuable to have some words on handing of (and
>>>comparability with) merge nodes that are PINs or RFC2750 enabled
>>>but don't support this document.
>>
>>good point.  we'll sit down and add some text to talk about this.
>
>I think both the case of a (i) Policy-Ignorant-Node (PIN) and of a
>(ii) policy-capable-node that is not aware of a new Policy Element,
>are already covered appropriately in section " 4.2 Default Handling
>for PIN nodes" of RFC2750. (ie forward as is, concatenate upstream
>with multicast, copy downstream with multicast).

agree, the general case is covered.

>BTW, this would also apply to the ALRP Policy Element defined in 3.2,
>right?

yes, but Application-Level Resource Priority Policy Element has 
semantics that allow for/address multiple elements.

>So how about we add a section "3.3 Default Handling" that says
>something like:
>"
>As specified in section 4.2 of RFC2750, Policy Ignorant Nodes (PINs)
>implement a default handling of POLICY_DATA objects ensuring that
>those objects can traverse PIN nodes in transit from one PEP to
>another. This applies to the situations where POLICY_DATA objects
>contain the Admission Priority Policy Element and the ALRP Policy
>Element specified in this document, so that those can traverse PIN
>nodes.
>
>Section 4.2 of RFC2750 also defines a similar default behavior for
>policy-capable nodes that do not recognized a particular Policy
>Element. This applies to the Admission Priority Policy Element and
>the ALRP Policy Element specified in this document, so that those can
>traverse policy-capable nodes that do not support this document.
>"
>
>Does that work?

yes, but also need to state how multiple Admission Priority Policy 
Elements in the same message are to be handled. (presumably the 
downstream node does the merge, but perhaps not...)

Lou

>Francois
>
>
>
>
>






From tsvwg-bounces@ietf.org Mon Apr 23 14:39:18 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3RU-0001Be-KS; Mon, 23 Apr 2007 14:39:16 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hg3RS-0001B4-Q1
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:39:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hg3RS-0001Av-GN; Mon, 23 Apr 2007 14:39:14 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hg3RS-0001Hv-1p; Mon, 23 Apr 2007 14:39:14 -0400
Received: from [127.0.0.1] (152.sub-75-215-23.myvzw.com [75.215.23.152])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3NIcTIh004285;
	Mon, 23 Apr 2007 11:38:40 -0700 (PDT)
Message-ID: <462CFD12.6030004@isi.edu>
Date: Mon, 23 Apr 2007 11:38:10 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Pyda Srisuresh <srisuresh@yahoo.com>
References: <700710.98945.qm@web33309.mail.mud.yahoo.com>
In-Reply-To: <700710.98945.qm@web33309.mail.mud.yahoo.com>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig2F5E4231C2623E63F6ABEEED"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc: behave@ietf.org, tsvwg@ietf.org,
	"Anantha Ramaiah \(ananth\)" <ananth@cisco.com>,
	"Mahesh Govind \(mgovind\)" <mgovind@cisco.com>,
	"Dan Wing \(dwing\)" <dwing@cisco.com>,
	"Faisal Siyavudeen \(fsiyavud\)" <fsiyavud@cisco.com>
Subject: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2F5E4231C2623E63F6ABEEED
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Pyda Srisuresh wrote:
> --- Joe Touch <touch@ISI.EDU> wrote:
=2E..
>>> So any discussion which is based on the semantics of a
>>> router/switch/host is IMO, useless, since things have evolved.
>> Until the requirements in the IETF are updated to reflect this opinion=
,
>> it is irrelevant.
>>
> [suresh] I agree with Ananth. Things have evolved considerably since th=
e
> introduction of NATs, web and peer networking. Any discussion based on
> semantics and not on present day deployment is not going to be useful, =
IMHO.

If you're proposing to redefine 1812 to include what a NAT does, go
ahead, and good luck.

Until then, IETF WGs need to stay within the scope of IETF standards.
Public opinion doesn't update those standards until we do.

>>> Also, actually, when you say "NAT's are not routers", there is a lot =
of
>>> ambiguity there :
>>>
>>> Typical case where NAT is configured in a router, which means that th=
is
>>> device, applies NAT rule and route's the packets.=20
> [suresh] Exactly. That is how NATs route. NATs translate IP addresses b=
efore
> forwarding.
>=20
>> Then the part that routes must obey RFC1812 rules. If the part that
>> routes can respond in lieu of the part that NATs, then that's fine. Bu=
t
>> when the part that NATs acts, it can't act like the router.
>>
> [suresh] So, if the part that does "NAT function" tells the part that d=
oes
> "route fucntion" that the router cannot forward the packet=20

That's nonsensical and 1812 does not apply. NAT functions are not
required on routers, and routers do not expect such signals from NAT
functions.

> (Cause: Resource
> constraint or admin restrictions), what error code shoud the part that =
does
> "route function" use when sending ICMP error message back to the sender=
? Are
> you saying this cannot be any of the error codes specified in RFC 1812?=


When caused by a NAT issue, yes, I'm saying it's inappropriate to co-opt
router messages.

=2E..
>> However, in the case of the combined device, it still makes sense to
>> determine WHY an error code is being generated. If because of a routin=
g
>> issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is
>> NOT the guiding document.
>>
> [suresh] Joe - This is really a semantics argument. We have had discuss=
ions in
> the BEHAVE WG on which error code to use and settled on error code 13 a=
s the
> most appropriate. This requirement has been in the draft for 6 months n=
ow.=20

And it's being reviewed by people outside the WG now, which is why it's
being discussed now.

> I will go with whatever the WG decides in the end. DO you think it is r=
eally
> necessary to invent a new ICMP error code for the error cause we are ta=
lking
> about? I think not. My 2c.

Yes, I do. And I think this is necessary for exactly every reason anyone
else does NOT want to generate a new error code. NATs are NOT routers.

Joe


--------------enig2F5E4231C2623E63F6ABEEED
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLP0SE5f5cImnZrsRAlL0AJ0eVzaOns3BkXu05+wPQvf3H9KYXwCfQWVz
rS0dzecDIyNFWHkasTRNPWk=
=TsvC
-----END PGP SIGNATURE-----

--------------enig2F5E4231C2623E63F6ABEEED--






From tsvwg-bounces@ietf.org Tue Apr 24 03:02:23 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgF2V-0002OO-VR; Tue, 24 Apr 2007 03:02:15 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HgF2T-0002OA-Vh
	for tsvwg-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 03:02:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgF2Q-0002Nh-Mm; Tue, 24 Apr 2007 03:02:10 -0400
Received: from gw.openss7.com ([142.179.199.224])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HgF2P-0000y5-Bl; Tue, 24 Apr 2007 03:02:10 -0400
Received: from ns.pigworks.openss7.net
	(IDENT:I/CTbbIQo3l2FGBtcDVyzqPLqgM0uNu2@ns1.evil.openss7.net
	[192.168.9.1])
	by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l3O720l13408;
	Tue, 24 Apr 2007 01:02:00 -0600
Received: (from brian@localhost)
	by ns.pigworks.openss7.net (8.11.6/8.11.6) id l3O720928772;
	Tue, 24 Apr 2007 01:02:00 -0600
Date: Tue, 24 Apr 2007 01:02:00 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
Message-ID: <20070424010200.A28606@openss7.org>
Mail-Followup-To: Joe Touch <touch@ISI.EDU>,
	Pyda Srisuresh <srisuresh@yahoo.com>, behave@ietf.org,
	tsvwg@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>,
	"Mahesh Govind (mgovind)" <mgovind@cisco.com>,
	"Dan Wing (dwing)" <dwing@cisco.com>,
	"Faisal Siyavudeen (fsiyavud)" <fsiyavud@cisco.com>
References: <700710.98945.qm@web33309.mail.mud.yahoo.com>
	<462CFD12.6030004@isi.edu>
Mime-Version: 1.0
Content-Type: application/pgp; x-action=sign; format=text
Content-Disposition: inline; filename="msg.pgp"
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <462CFD12.6030004@isi.edu>;
	from touch@ISI.EDU on Mon, Apr 23, 2007 at 11:38:10AM -0700
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: behave@ietf.org, tsvwg@ietf.org, Pyda Srisuresh <srisuresh@yahoo.com>,
	"Anantha Ramaiah \(ananth\)" <ananth@cisco.com>,
	"Mahesh Govind \(mgovind\)" <mgovind@cisco.com>,
	"Dan Wing \(dwing\)" <dwing@cisco.com>,
	"Faisal Siyavudeen \(fsiyavud\)" <fsiyavud@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe,

Joe Touch wrote:                                 (Mon, 23 Apr 2007 11:38:10)

> >> Then the part that routes must obey RFC1812 rules. If the part that
> >> routes can respond in lieu of the part that NATs, then that's fine. But
> >> when the part that NATs acts, it can't act like the router.
> >>
> > [suresh] So, if the part that does "NAT function" tells the part that does
> > "route fucntion" that the router cannot forward the packet 
> 
> That's nonsensical and 1812 does not apply. NAT functions are not
> required on routers, and routers do not expect such signals from NAT
> functions.

I read this as "routers are not necessarily NATs", which sounds like a
correct assertion.

> > I will go with whatever the WG decides in the end. DO you think it is really
> > necessary to invent a new ICMP error code for the error cause we are talking
> > about? I think not. My 2c.
> 
> Yes, I do. And I think this is necessary for exactly every reason anyone
> else does NOT want to generate a new error code. NATs are NOT routers.

I read this as "NATs are not routers", which sounds like a possibly
incorrect assertion.

I think NATs can (and perhaps must) also be routers (i.e. they can,
and perhaps must, meet the requirements of an Internet router or
Internet host despite their NATishness).

Therefore, for a NAT to use an ICMP error code normally used by routers
or hosts sounds reasonable to me, provided the NAT-free router and host
can interpret the error code as before.

- --brian

- -- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFGLatmMYOP2up1d2URAr1yAJ927uTfbjc96d6VcWGSrlgFY3HCfwCfVau7
dVhz/PdymqR4g5dn/9XOHmM=
=ic4g
-----END PGP SIGNATURE-----





From tsvwg-bounces@ietf.org Tue Apr 24 08:03:42 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgJkA-0006bF-MR; Tue, 24 Apr 2007 08:03:38 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hg36n-0000xM-Nh
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:17:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg36n-0000x1-8F
	for tsvwg@ietf.org; Mon, 23 Apr 2007 14:17:53 -0400
Received: from web33309.mail.mud.yahoo.com ([68.142.206.124])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg36m-00034o-JI
	for tsvwg@ietf.org; Mon, 23 Apr 2007 14:17:53 -0400
Received: (qmail 2722 invoked by uid 60001); 23 Apr 2007 18:17:51 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=Xp9tPQqfd3W8Qptv010Z0hToJgig+bzMBbHe+1VsmXy1PA7Yg55p7LRDaCP+xA3NgdYhJAf6ORv+j66E23psf4zCQN/EfTOERXqTS+IeVRrUJzr/cNKy/Yt3nMk7qOS+AKLCGSOVKoRWxe6UJDzz98jzQQkNkGjJIQpXU3XaRos=;
X-YMail-OSG: 4GBT_2MVM1mYUW4QFcr_r3itaQChpp2PKwe2YHRWeeSAFP15hFMV92bCvBGZitQ0UR7GhtC7h.K_Kcq9H7qK9wkiDuZPoPMu0mqJc4HbrSAt5UY-
Received: from [209.172.74.45] by web33309.mail.mud.yahoo.com via HTTP;
	Mon, 23 Apr 2007 11:17:51 PDT
Date: Mon, 23 Apr 2007 11:17:51 -0700 (PDT)
From: Pyda Srisuresh <srisuresh@yahoo.com>
To: Joe Touch <touch@ISI.EDU>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
In-Reply-To: <462CBF2B.2040100@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <700710.98945.qm@web33309.mail.mud.yahoo.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
X-Mailman-Approved-At: Tue, 24 Apr 2007 08:03:37 -0400
Cc: behave@ietf.org, tsvwg@ietf.org, Pyda Srisuresh <srisuresh@yahoo.com>,
	"Mahesh Govind \(mgovind\)" <mgovind@cisco.com>,
	"Dan Wing \(dwing\)" <dwing@cisco.com>,
	"Faisal Siyavudeen \(fsiyavud\)" <fsiyavud@cisco.com>
Subject: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--- Joe Touch <touch@ISI.EDU> wrote:

> 
> 
> Anantha Ramaiah (ananth) wrote:
> > Firstly, why is this being disussed in tcpm? This doesn't apply to TCP
> > directly. [ even in-directly it might apply to all other transport
> > protocols who can/may want to act on these errors] Maybe tsvwg is more
> > appropriate? 
> 
> That's possible; someone in Behave might start by posting a summary of
> the question there as well.
> 
[suresh] Agree with Ananth's comment. This is likely more applicable to tsvwg
than tcpm. I am replacing tcpm with tsvwg.

> > As far as the current discussion goes, there is a thin line of
> > distinction between hosts and routers, today.
> 
> There may be many devices that do both functions, but to the extent they
> do they must then obey both the host and router requirements.
> 
> > Today's routers do all
> > sort of things which were only done by end-hosts at one point of time.
> 
> Such as? Other than acting like end hosts for connections that terminate
> at routers, which they have always done, and always required
> RFC1122-level support...
> 
> > So any discussion which is based on the semantics of a
> > router/switch/host is IMO, useless, since things have evolved.
> 
> Until the requirements in the IETF are updated to reflect this opinion,
> it is irrelevant.
> 
[suresh] I agree with Ananth. Things have evolved considerably since the
introduction of NATs, web and peer networking. Any discussion based on
semantics and not on present day deployment is not going to be useful, IMHO.

> > Also, actually, when you say "NAT's are not routers", there is a lot of
> > ambiguity there :
> > 
> > Typical case where NAT is configured in a router, which means that this
> > device, applies NAT rule and route's the packets. 
> 
[suresh] Exactly. That is how NATs route. NATs translate IP addresses before
forwarding.

> Then the part that routes must obey RFC1812 rules. If the part that
> routes can respond in lieu of the part that NATs, then that's fine. But
> when the part that NATs acts, it can't act like the router.
> 
[suresh] So, if the part that does "NAT function" tells the part that does
"route fucntion" that the router cannot forward the packet (Cause: Resource
constraint or admin restrictions), what error code shoud the part that does
"route function" use when sending ICMP error message back to the sender? Are
you saying this cannot be any of the error codes specified in RFC 1812?

> > So are you saying :-
> ...
> > - generate a ICMP error code if the error is a result of a "routing
> > operation" and NOT as a result of "NAT operation"? 
> 
> Yes.
> 
> > I really don't see a
> > value in seperating these and it boils down to pure semantic argument,
> > IMO, without considering the characteristics of the deployed Internet
> > today. 
> 
[suresh] Right. Full agree with Ananth. Coulndt have said it better.

> First, there are plenty of devices that do not combine both functions,
> and that's where we're talking about.
> 
> However, in the case of the combined device, it still makes sense to
> determine WHY an error code is being generated. If because of a routing
> issue, then RFC1812 works; if because of a NAT issue, then RFC1812 is
> NOT the guiding document.
> 
[suresh] Joe - This is really a semantics argument. We have had discussions in
the BEHAVE WG on which error code to use and settled on error code 13 as the
most appropriate. This requirement has been in the draft for 6 months now. 

I will go with whatever the WG decides in the end. DO you think it is really
necessary to invent a new ICMP error code for the error cause we are talking
about? I think not. My 2c.

regards,
suresh


> Joe
> 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch@ISI.EDU] 
> >> Sent: Sunday, April 22, 2007 2:12 PM
> >> To: Pyda Srisuresh
> >> Cc: tcpm@ietf.org; behave@ietf.org; Mahesh Govind (mgovind); 
> >> Dan Wing (dwing); Faisal Siyavudeen (fsiyavud)
> >> Subject: Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
> >>
> >>
> >>
> >> Pyda Srisuresh wrote:
> >>> Below is what RFC 1812 has to say about what constitutes a router.
> >>>
> >>>   This memo defines and discusses requirements for devices 
> >> that perform
> >>>   the network layer forwarding function of the Internet 
> >> protocol suite.
> >>>   The Internet community usually refers to such devices as 
> >> IP routers or
> >>>   simply routers.
> >> The rest of that document is what defines what is an Internet router.
> >> Being a device that does network layer forwarding and 
> >> violates any of the rest of that doc means that device is not 
> >> an Internet router.
> >>
> >>> NATs forward IP packets from one network to another. That 
> >> makes NAT a router.
> >>
> >> NATs don't follow the requirement of:
> >> 	- decrement the TTL
> >> 	- do not modify the source or destination IP address
> >> 		(except as per source-routing options)
> >>
> >> ...
> >>> If you insist NAT is not a router, I am not going to argue 
> >> or get into 
> >>> a debate with you on this. I will simply disagree. So do the vast 
> >>> majority of people taht use NATs to connect to public networks.
> >> They can and have disagreed before, but this isn't up for a 
> >> popular vote. It's utterly useless to talk about using any 
> >> sort of IETF standard
> >> - including ICMP type 3 code 13 - and expect the rest of the 
> >> Internet to follow that standard when NATs violate the 
> >> standard of what it means to be a router.
> >>
> >> Joe
> >>
> >>
> > 
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/tcpm
> 
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> 








From tsvwg-bounces@ietf.org Tue Apr 24 09:22:31 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgKyQ-000480-2h; Tue, 24 Apr 2007 09:22:26 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HgKyN-000429-Fq
	for tsvwg-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 09:22:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HgKyM-00040g-QL; Tue, 24 Apr 2007 09:22:22 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HgKyL-00053l-DS; Tue, 24 Apr 2007 09:22:22 -0400
Received: from [127.0.0.1] (pool-71-106-84-92.lsanca.dsl-w.verizon.net
	[71.106.84.92])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l3ODLdu9029256;
	Tue, 24 Apr 2007 06:21:40 -0700 (PDT)
Message-ID: <462E0453.9090509@isi.edu>
Date: Tue, 24 Apr 2007 06:21:23 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>, Pyda Srisuresh <srisuresh@yahoo.com>,
	behave@ietf.org, tsvwg@ietf.org,
	"Anantha Ramaiah (ananth)" <ananth@cisco.com>,
	"Mahesh Govind (mgovind)" <mgovind@cisco.com>,
	"Dan Wing (dwing)" <dwing@cisco.com>,
	"Faisal Siyavudeen (fsiyavud)" <fsiyavud@cisco.com>
Subject: Re: [Tsvwg] Re: [BEHAVE] Re: [tcpm] icmp type 3, code 13
References: <700710.98945.qm@web33309.mail.mud.yahoo.com>
	<462CFD12.6030004@isi.edu> <20070424010200.A28606@openss7.org>
In-Reply-To: <20070424010200.A28606@openss7.org>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig27B56B5FADEE997F88F0227E"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig27B56B5FADEE997F88F0227E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> Joe,
=2E..
>> > Yes, I do. And I think this is necessary for exactly every reason an=
yone
>> > else does NOT want to generate a new error code. NATs are NOT router=
s.
>=20
> I read this as "NATs are not routers", which sounds like a possibly
> incorrect assertion.
>=20
> I think NATs can (and perhaps must) also be routers (i.e. they can,
> and perhaps must, meet the requirements of an Internet router or
> Internet host despite their NATishness).

As per my other note, that is an interesting position, but adds a
requirement that is not already there.

Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment


--------------enig27B56B5FADEE997F88F0227E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGLgRTE5f5cImnZrsRAqWsAJ4rcCOtcwIyWoVyYRXzRnLTkESJHgCeKkOA
79nUrO9GqFDkcDz/S+mXiQs=
=us2x
-----END PGP SIGNATURE-----

--------------enig27B56B5FADEE997F88F0227E--






From tsvwg-bounces@ietf.org Wed Apr 25 09:24:45 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HghUB-0008F1-Fj; Wed, 25 Apr 2007 09:24:43 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HghU9-0008Ew-Sj
	for tsvwg-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 09:24:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HghU9-0008Eo-JC
	for tsvwg@ietf.org; Wed, 25 Apr 2007 09:24:41 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghU7-0007hK-2X
	for tsvwg@ietf.org; Wed, 25 Apr 2007 09:24:41 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3PDOGrv026849 for <tsvwg@ietf.org>; Wed, 25 Apr 2007 16:24:37 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 16:24:35 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Apr 2007 16:24:34 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by
	esebh102.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:24:35 +0300
Received: from [172.21.39.157] (esdhcp039157.research.nokia.com
	[172.21.39.157])
	by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3PDOXGc023224 for <tsvwg@ietf.org>; Wed, 25 Apr 2007 16:24:33 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <5A1E6DB4-9F21-4AEE-9025-F61028A3D034@nokia.com>
References: <E1HZXy6-00046G-Gj@stiedprstage1.ietf.org>
	<5A1E6DB4-9F21-4AEE-9025-F61028A3D034@nokia.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--515707158;
	protocol="application/pkcs7-signature"
Message-Id: <562FCF45-BCC6-405F-A5B6-4A693A50E248@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] start of WGLC for draft-ietf-tsvwg-cc-alt
Date: Wed, 25 Apr 2007 16:24:31 +0300
To: tsvwg WG <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 25 Apr 2007 13:24:35.0164 (UTC)
	FILETIME=[1104F1C0:01C7873D]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-22--515707158
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On 2007-4-10, at 10:12, ext Lars Eggert wrote:
> On 2007-4-5, at 22:50, ext tsvwg-bounces@ietf.org wrote:
>> 	Title		: Specifying New Congestion Control Algorithms
>> 	Author(s)	: S. Floyd, M. Allman
>> 	Filename	: draft-ietf-tsvwg-cc-alt-01.txt
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-01.txt
>
> We're starting the WGLC for this draft now. Please send your  
> reviews by April 24, 2007.

There weren't many comments during WGLC, but the few I saw were  
positive. I'm thus calling rough consensus to publish this as a BCP.  
(If you think I'm misreading the consensus, please speak up now.)

I believe the authors are planning a final revision, to address some  
LC comments?

Lars



--Apple-Mail-22--515707158
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjUxMzI0MzJaMCMGCSqGSIb3DQEJBDEWBBQAiy9W9GQnA9Gj
aoTArzrNxUvkfjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAOowmLqtD8vJMWezoBtT14jaEWASuoAcBH4a2xIBIR4Jt+VZvToY6
XgXJvd8jMK4t5tt0r07XGES0N5uXMiwFbEx40AmQ4jHB2n6sHuV3jaQsNVEa1+N3sBHnkRaPKznF
bGMVaylELJpfrb28bx7eu/117TubdDE1gTD0+QKx6cr/oEjLKiXL2tmfYmUKA1RMa71BQhYdECCp
Kquw1Zuo+yozWUwUtIHhsb0mNL+HDEaNc4LsVjvNuipK2jrx9bp0xWPcOHkt1SwRtmJHKSuZGnxM
S0htuDGNDs5fPFY+q6TJBVBrekxP3U7nVUv8FnvyHtNdrCJueWTZmxrRjcvxiwAAAAAAAA==

--Apple-Mail-22--515707158--





From tsvwg-bounces@ietf.org Thu Apr 26 15:50:17 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh9yp-0006nZ-Tr; Thu, 26 Apr 2007 15:50:15 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1Hh9yd-0006d2-VT
	for tsvwg-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 15:50:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hh9yc-0006b8-R2; Thu, 26 Apr 2007 15:50:02 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Hh9yc-0005LM-Ip; Thu, 26 Apr 2007 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 830DD329C2;
	Thu, 26 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Hh9yc-00069c-DW; Thu, 26 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Hh9yc-00069c-DW@stiedprstage1.ietf.org>
Date: Thu, 26 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-cc-alt-02.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Specifying New Congestion Control Algorithms
	Author(s)	: S. Floyd, M. Allman
	Filename	: draft-ietf-tsvwg-cc-alt-02.txt
	Pages		: 11
	Date		: 2007-4-26
	
The IETF's standard congestion control schemes have been widely
    shown to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP],
    [XCP], and many more).  Using these new congestion control
    schemes in the global Internet has possible ramifications to
    both the traffic using the new congestion control and to traffic
    using the currently standardized congestion control.  Therefore,
    the IETF must proceed with caution when dealing with alternate
    congestion control proposals.  The goal of this document is to
    provide guidance for considering alternate congestion control
    algorithms within the IETF.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-cc-alt-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-26123547.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-cc-alt-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-cc-alt-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-26123547.I-D@ietf.org>


--OtherAccess--

--NextPart--






From tsvwg-bounces@ietf.org Fri Apr 27 08:17:09 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhPNr-0007qn-E0; Fri, 27 Apr 2007 08:17:07 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HhKmG-0004Gh-L5
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 03:22:00 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HhKmG-0004GR-Aw
	for tsvwg@ietf.org; Fri, 27 Apr 2007 03:22:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhK50-0003zu-0I
	for tsvwg@ietf.org; Fri, 27 Apr 2007 02:37:18 -0400
Received: from mail.teledna.com ([220.227.64.150] helo=teledna.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhK4y-0000H6-1L
	for tsvwg@ietf.org; Fri, 27 Apr 2007 02:37:17 -0400
Received: (qmail 19643 invoked from network); 27 Apr 2007 06:14:06 -0000
X-Mail-Scanner: Scanned by qSheff 1.0-r4 (http://www.enderunix.org/qsheff/)
Received: from unknown (HELO ashwin) (qsheff9tee@192.168.1.54)
	by teledna.com with SMTP; 27 Apr 2007 06:14:04 -0000
Message-ID: <001b01c78895$3fc44340$3601a8c0@ashwin>
From: "Ashwin" <ashwin@teledna.com>
To: <tsvwg@ietf.org>
Date: Fri, 27 Apr 2007 11:57:45 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0017_01C788C3.44B08D90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
X-TMDA-Confirmed: Fri, 27 Apr 2007 03:22:00 -0400
X-Mailman-Approved-At: Fri, 27 Apr 2007 08:17:05 -0400
Cc: sctp-impl@external.cisco.com
Subject: [Tsvwg] Can I initiate multiple SCTP associations....
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C788C3.44B08D90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0018_01C788C3.44B08D90"


------=_NextPart_001_0018_01C788C3.44B08D90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello

I have a query related to SCTP.
I just want to know if I can have more than one SCTP association =
originating from the same IP and Port.(Client)
In RFC 2960, it said that there will be a single association between two =
SCTP endpoint. And an SCTP end point is a unique PORT.
I just want a confirmation on this.



Thanks & Regards
Ashwin S
Software Engineer
TeleDNA Communication Pvt. Ltd.=20
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
--------------------------
CONFIDENTIALITY NOTE: The content of this email transmission is =
confidential and property of TeleDNA. The information in this mail is =
privileged and intended only for the use of the entity(s) or the =
individual (s) to which it is addressed. If the reader is not an =
intended recipient, you are hereby notified that any unauthorized =
disclosure, copying, distribution of this electronically transmitted =
information is strictly prohibited. If you are in receipt of this =
electronic communication in error, please immediately notify the sender =
and delete the information.

------=_NextPart_001_0018_01C788C3.44B08D90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff size=3D2>Hello</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>I have a query related to =
SCTP.</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>I just want to know if I can have =
more than one=20
SCTP association originating from the same IP and =
Port.(Client)</FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2>In&nbsp;<FONT color=3D#000000 =
size=3D3><FONT=20
color=3D#0000ff size=3D2>RFC 2960, it said that there will be a=20
single&nbsp;association between two SCTP endpoint. And an SCTP end point =
is a=20
unique PORT.</FONT></FONT></FONT></DIV>
<DIV><FONT color=3D#0000ff size=3D2><FONT color=3D#000000 size=3D3><FONT =
color=3D#0000ff=20
size=3D2>I just want a confirmation on =
this.<BR></DIV></FONT></FONT></FONT>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2>Thanks &amp; Regards<BR>Ashwin =
S<BR>Software=20
Engineer<BR>TeleDNA Communication Pvt. Ltd.=20
<BR>---------------------------------------------------------------------=
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
------------------------------<BR>CONFIDENTIALITY=20
NOTE: The content of this email transmission is confidential and =
property of=20
TeleDNA. The information in this mail is privileged and intended only =
for the=20
use of the entity(s) or the individual (s) to which it is addressed. If =
the=20
reader is not an intended recipient, you are hereby notified that any=20
unauthorized disclosure, copying, distribution of this electronically=20
transmitted information is strictly prohibited. If you are in receipt of =
this=20
electronic communication in error, please immediately notify the sender =
and=20
delete the information.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0018_01C788C3.44B08D90--

------=_NextPart_000_0017_01C788C3.44B08D90
Content-Type: text/x-vcard;
	name="Ashwin S (Business Fax).vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Ashwin S (Business Fax).vcf"

BEGIN:VCARD
VERSION:2.1
N:S;Ashwin
FN:Ashwin S (Business Fax)
ORG:TeleDNA Communications Pvt Ltd.;SMSC Testing
TITLE:Software Engineer
TEL;WORK;VOICE:080-56661107
TEL;HOME;VOICE:080-26488520
TEL;CELL;VOICE:9980 132 150
TEL;WORK;FAX:91-80-56661132
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;080-56661180 / 81;#10, 3rd =
Floor=3D0D=3D0A100 Feet Ring Road=3D0D=3D0ABTM 1st Stage=3D
;Bangalore;Karnataka;560 068;India
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:080-56661180 / 81=3D0D=3D0A#10, =
3rd Floor=3D0D=3D0A100 Feet Ring Road=3D0D=3D0ABTM 1st S=3D
tage=3D0D=3D0ABangalore, Karnataka 560 068=3D0D=3D0AIndia
ADR;HOME;ENCODING=3DQUOTED-PRINTABLE:;;#237, "ASHWINI"=3D0D=3D0A6th A =
Cross, 3rd Main=3D0D=3D0AVijaya Bank Layout=3D0D=3D0ABe=3D
hind IIM(B)=3D0D=3D0ABannerghatta Road;Bangalore;Karnataka;560 076;India
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:#237, "ASHWINI"=3D0D=3D0A6th A =
Cross, 3rd Main=3D0D=3D0AVijaya Bank Layout=3D0D=3D0ABehi=3D
nd IIM(B)=3D0D=3D0ABannerghatta Road=3D0D=3D0ABangalore, Karnataka 560 =
076=3D0D=3D0AIndi=3D
a
X-WAB-GENDER:2
URL;WORK:http://www.teledna.com
EMAIL;PREF;INTERNET:ashwin@teledna.com
REV:20070427T062745Z
END:VCARD

------=_NextPart_000_0017_01C788C3.44B08D90--







From tsvwg-bounces@ietf.org Fri Apr 27 08:37:36 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhPhe-0006jZ-8X; Fri, 27 Apr 2007 08:37:34 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HhPhc-0006Tr-Ht
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 08:37:32 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPhc-0006Pq-3Z
	for tsvwg@ietf.org; Fri, 27 Apr 2007 08:37:32 -0400
Received: from laas.laas.fr ([140.93.0.15])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhPha-0001Ww-Is
	for tsvwg@ietf.org; Fri, 27 Apr 2007 08:37:32 -0400
Received: by laas.laas.fr (8.13.8/8.13.8) with ESMTP
	id l3RCWOZ5015667; Fri, 27 Apr 2007 14:32:26 +0200 (MEST)
Message-ID: <58859.192.16.184.242.1177677145.squirrel@intranet.laas.fr>
Date: Fri, 27 Apr 2007 14:32:25 +0200 (CEST)
From: urtzi@laas.fr
To: tsvwg@ietf.org
User-Agent: SquirrelMail/1.4.6
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Status: No
X-Spam-Score: 0 () 
X-Scanned-By: MIMEDefang at CNRS-LAAS on 140.93.0.15
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: jblanton@masaka.cs.ohiou.edu, k.avrachenkov@sophia.inria.fr,
	mallman@icir.org
Subject: [Tsvwg] Early-retransmit I-D
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

In november we submmited the fourth version of the early retransmit
I-D: http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04.txt

You may check the announcement email and the thread that followed at the
link: http://arcknowledge.com/ietf.tsvwg/2006-12/msg00052.html

The expiration date is approaching, and we would greatly appreciate if the
working-group will reach a consensus on how we should proceed with the
I-D.

Urtzi


>
>
> We recently re-submitted the early retransmit I-D that we pushed along a
> while back:
>
>        Title           : Early Retransmit for TCP and SCTP
>        Author(s)       : M. Allman, et al.
>        Filename        : draft-allman-tcp-early-rexmt-04.txt
>        Pages           : 10
>        Date            : 2006-11-26
>        http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04.txt
>
> We stopped pushing this I-D because some of our analysis of network
> traces seemed to indicate that ER was sort of a crapshoot, failing as
> much as succeeding.  However, given that we never went beyond sort of a
> preliminary assessment and did not publish the results (/ let them stand
> against peer review) we no longer think we should stop the ER draft
> because of these results.  Further, the results were from on particular
> network and it would seem useful to gain a broad understanding of how ER
> works in a variety of environments.
>
> My recollection is that once upon a time the TSVWG had some consensus to
> take on ER as a work item with the intention of publishing it as an
> experimental RFC.  I am not asking the WG that question right now.  But,
> we may ask that question soon, if the chairs are amenable.  Right now we
> just want to alert folks that this draft is out and solicit comments
> From the WG.
>
> Thanks!
>
> allman
>
>








From tsvwg-bounces@ietf.org Fri Apr 27 08:44:43 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhPoZ-0007dJ-5F; Fri, 27 Apr 2007 08:44:43 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HhPoX-0007d5-Ad
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 08:44:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPoX-0007cx-16
	for tsvwg@ietf.org; Fri, 27 Apr 2007 08:44:41 -0400
Received: from jaguar.hughesbpo.net ([61.246.186.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPoS-0003e1-3J
	for tsvwg@ietf.org; Fri, 27 Apr 2007 08:44:41 -0400
Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1])
	by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l3RCg6Sk014911
	for <tsvwg@ietf.org>; Fri, 27 Apr 2007 18:12:06 +0530
Received: from sandesh.hss.hns.com (sandesh [10.203.142.21])
	by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l3RCg42C014877;
	Fri, 27 Apr 2007 18:12:05 +0530
In-Reply-To: <001b01c78895$3fc44340$3601a8c0@ashwin>
To: "Ashwin" <ashwin@teledna.com>
Subject: Re: [Tsvwg] Can I initiate multiple SCTP associations....
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
Message-ID: <OFE701886A.C457FD4B-ON652572CA.0045DF23-652572CA.0045FB65@flextronicssoftware.com>
From: Ashwani Kathuria <ashwani.kathuria@aricent.com>
Date: Fri, 27 Apr 2007 18:18:16 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30,
	2005) at 27/04/2007 06:18:00 PM
Content-Type: multipart/mixed; boundary="=_mixed 0045FB5F652572CA_="
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--=_mixed 0045FB5F652572CA_=
Content-Type: multipart/alternative;
	boundary="=_alternative 0045FB62652572CA_="


--=_alternative 0045FB62652572CA_=
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello=20Ashwin=0D=0A=0D=0ATo=20form=20an=20SCTP=20Association=20the=20fol=
lowing=20tuple=20should=20be=20unique=20for=20that=20=0D=0Aassociation:=
=0D=0A{=20client=20IP,=20client=20port,=20server=20IP,=20server=20port=20=
}=0D=0A=0D=0ASo=20if=20at=20the=20client=20side=202=20sockets=20are=20bou=
nd=20to=20same=20IP=20address=20and=20port,=20=0D=0Athen=20the=20server=
=20sockets=20they=20are=20connecting=20to,=20should=20either=20differ=20i=
n=20IP=20=0D=0Aaddress=20or=20port=20to=20make=20the=20above=20mentioned=
=20tuple=20unique.=0D=0A=0D=0AThanks=20&=20Regards=20-=0D=0AAshwani=20Kat=
huria=0D=0A=20=0D=0AA=20R=20I=20C=20E=20N=20T=0D=0A=20=0D=0AThe=20Preside=
ncy=20Tower=20?A,=20351/2,=20Sector=2014=0D=0AM.G.=20Road=20Gurgaon=20122=
001,=20Haryana,=20India.=0D=0A=20=0D=0AMain=20=20=20=20=20+91=20124.417.6=
333=20=20=20=20=20=20=20=20=20Extn=20:=205218=0D=0AFax=20=20=20=20=20=20+=
91=20124.417.6225=0D=0AMobile=20=20=20+91=20991.142.4546=0D=0Awww.aricent=
.com=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A=0D=0A"Ashwin"=20<ashwin@teledna.com=
>=20=0D=0A04/27/2007=2011:57=20AM=0D=0A=0D=0A=0D=0ATo=0D=0A<tsvwg@ietf.or=
g>=0D=0Acc=0D=0Asctp-impl@external.cisco.com=0D=0ASubject=0D=0A[Tsvwg]=20=
Can=20I=20initiate=20multiple=20SCTP=20associations....=0D=0A=0D=0A=0D=0A=
=0D=0A=0D=0A=0D=0A=0D=0AHello=0D=0A=20=0D=0AI=20have=20a=20query=20relate=
d=20to=20SCTP.=0D=0AI=20just=20want=20to=20know=20if=20I=20can=20have=20m=
ore=20than=20one=20SCTP=20association=20=0D=0Aoriginating=20from=20the=20=
same=20IP=20and=20Port.(Client)=0D=0AIn=20RFC=202960,=20it=20said=20that=
=20there=20will=20be=20a=20single=20association=20between=20two=20=0D=0AS=
CTP=20endpoint.=20And=20an=20SCTP=20end=20point=20is=20a=20unique=20PORT.=
=0D=0AI=20just=20want=20a=20confirmation=20on=20this.=0D=0A=20=0D=0A=20=
=0D=0AThanks=20&=20Regards=0D=0AAshwin=20S=0D=0ASoftware=20Engineer=0D=0A=
TeleDNA=20Communication=20Pvt.=20Ltd.=20=0D=0A---------------------------=
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
------------------------------------------------------------------------=
=0D=0ACONFIDENTIALITY=20NOTE:=20The=20content=20of=20this=20email=20trans=
mission=20is=20=0D=0Aconfidential=20and=20property=20of=20TeleDNA.=20The=
=20information=20in=20this=20mail=20is=20=0D=0Aprivileged=20and=20intende=
d=20only=20for=20the=20use=20of=20the=20entity(s)=20or=20the=20=0D=0Aindi=
vidual=20(s)=20to=20which=20it=20is=20addressed.=20If=20the=20reader=20is=
=20not=20an=20intended=20=0D=0Arecipient,=20you=20are=20hereby=20notified=
=20that=20any=20unauthorized=20disclosure,=20=0D=0Acopying,=20distributio=
n=20of=20this=20electronically=20transmitted=20information=20is=20=0D=0As=
trictly=20prohibited.=20If=20you=20are=20in=20receipt=20of=20this=20elect=
ronic=20=0D=0Acommunication=20in=20error,=20please=20immediately=20notify=
=20the=20sender=20and=20delete=20=0D=0Athe=20information.=0D=0A=0D=0A=0D=
=0A***********************=20=20Aricent-Unclassified=20=20=20************=
***********=0D=0A"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20=
Aricent=20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=
=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p=
rivileged=20or=20confidential=20information=20and=20should=20not=20be=20=
=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20wh=
at=20it=20is=20intended.=20If=20you=20have=20received=20this=20message=20=
in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=
=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notified=
=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20=
altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20Ari=
cent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20aris=
ing=20from=20the=20use=20of=20the=20information=20transmitted=20by=20this=
=20email=20including=20damage=20from=20virus."=0A
--=_alternative 0045FB62652572CA_=
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

=0D=0A<br><font=20size=3D2=20face=3D"sans-serif">Hello=20Ashwin</font>=0D=
=0A<br>=0D=0A<br><font=20size=3D2=20face=3D"sans-serif">To=20form=20an=20=
SCTP=20Association=20the=20following=0D=0Atuple=20should=20be=20unique=20=
for=20that=20association:</font>=0D=0A<br><font=20size=3D2=20face=3D"sans=
-serif">{=20client=20IP,=20client=20port,=20server=20IP,=0D=0Aserver=20po=
rt=20}</font>=0D=0A<br>=0D=0A<br><font=20size=3D2=20face=3D"sans-serif">S=
o=20if=20at=20the=20client=20side=202=20sockets=20are=0D=0Abound=20to=20s=
ame=20IP=20address=20and=20port,=20then=20the=20server=20sockets=20they=
=20are=20connecting=0D=0Ato,=20should=20either=20differ=20in=20IP=20addre=
ss=20or=20port=20to=20make=20the=20above=20mentioned=0D=0Atuple=20unique.=
<br>=0D=0A</font>=0D=0A<table=20width=3D100%>=0D=0A<tr>=0D=0A<td=20width=
=3D100%><font=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">Thanks=20&amp=
;=20Regards=0D=0A-</font>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=20size=
=3D1=20color=3D#5f5f5f=20face=3D"Arial"><b>Ashwani=20Kathuria</b></font>=
=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=20size=3D1=20color=3Dred=20face=
=3D"Arial"><b>&nbsp;</b></font>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=
=20size=3D1=20color=3Dred=20face=3D"Arial"><b>A=20R=20I=20C=20E=20N=20T</=
b></font>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=20size=3D1=20color=3D#5=
f5f5f=20face=3D"Arial">&nbsp;</font>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><f=
ont=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">The=20Presidency=20Towe=
r=20&#8211;A,=20351/2,=0D=0ASector=2014</font>=0D=0A<tr=20valign=3Dtop>=
=0D=0A<td><font=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">M.G.=20Road=
=20Gurgaon=20122001,=20Haryana,=0D=0AIndia.</font>=0D=0A<tr=20valign=3Dto=
p>=0D=0A<td><font=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">&nbsp;</f=
ont>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=20size=3D1=20color=3D#5f5f5f=
=20face=3D"Arial">Main&nbsp;&nbsp;&nbsp;&nbsp;=0D=0A</font><font=20size=
=3D1=20color=3D#606060=20face=3D"Arial">+91=20124.417.6333&nbsp;=20&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Extn=0D=0A:=205218</font>=0D=0A<tr=20=
valign=3Dtop>=0D=0A<td><font=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial=
">Fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=0D=0A</font><font=20size=3D1=20color=
=3D#606060=20face=3D"Arial">+91=20124.417.6225</font>=0D=0A<tr=20valign=
=3Dtop>=0D=0A<td><font=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">Mobi=
le&nbsp;=20&nbsp;</font><font=20size=3D1=20color=3D#606060=20face=3D"Aria=
l">+91=0D=0A991.142.4546</font>=0D=0A<tr=20valign=3Dtop>=0D=0A<td><font=
=20size=3D1=20color=3D#5f5f5f=20face=3D"Arial">www.aricent.com</font></ta=
ble>=0D=0A<br>=0D=0A<p><font=20size=3D3>&nbsp;</font>=0D=0A<br>=0D=0A<br>=
=0D=0A<br>=0D=0A<table=20width=3D100%>=0D=0A<tr=20valign=3Dtop>=0D=0A<td=
=20width=3D40%><font=20size=3D1=20face=3D"sans-serif"><b>&quot;Ashwin&quo=
t;=20&lt;ashwin@teledna.com&gt;</b>=0D=0A</font>=0D=0A<p><font=20size=3D1=
=20face=3D"sans-serif">04/27/2007=2011:57=20AM</font>=0D=0A<br>=0D=0A<td=
=20width=3D59%>=0D=0A<table=20width=3D100%>=0D=0A<tr>=0D=0A<td>=0D=0A<div=
=20align=3Dright><font=20size=3D1=20face=3D"sans-serif">To</font></div>=
=0D=0A<td=20valign=3Dtop><font=20size=3D1=20face=3D"sans-serif">&lt;tsvwg=
@ietf.org&gt;</font>=0D=0A<tr>=0D=0A<td>=0D=0A<div=20align=3Dright><font=
=20size=3D1=20face=3D"sans-serif">cc</font></div>=0D=0A<td=20valign=3Dtop=
><font=20size=3D1=20face=3D"sans-serif">sctp-impl@external.cisco.com</fon=
t>=0D=0A<tr>=0D=0A<td>=0D=0A<div=20align=3Dright><font=20size=3D1=20face=
=3D"sans-serif">Subject</font></div>=0D=0A<td=20valign=3Dtop><font=20size=
=3D1=20face=3D"sans-serif">[Tsvwg]=20Can=20I=20initiate=20multiple=0D=0AS=
CTP=20associations....</font></table>=0D=0A<br>=0D=0A<table>=0D=0A<tr=20v=
align=3Dtop>=0D=0A<td>=0D=0A<td></table>=0D=0A<br></table>=0D=0A<br>=0D=
=0A<br>=0D=0A<br><font=20size=3D2=20color=3Dblue>Hello</font>=0D=0A<br><f=
ont=20size=3D3>&nbsp;</font>=0D=0A<br><font=20size=3D2=20color=3Dblue>I=
=20have=20a=20query=20related=20to=20SCTP.</font>=0D=0A<br><font=20size=
=3D2=20color=3Dblue>I=20just=20want=20to=20know=20if=20I=20can=20have=20m=
ore=20than=0D=0Aone=20SCTP=20association=20originating=20from=20the=20sam=
e=20IP=20and=20Port.(Client)</font>=0D=0A<br><font=20size=3D2=20color=3Db=
lue>In=20RFC=202960,=20it=20said=20that=20there=20will=20be=20a=20single=
=0D=0Aassociation=20between=20two=20SCTP=20endpoint.=20And=20an=20SCTP=20=
end=20point=20is=20a=20unique=0D=0APORT.</font>=0D=0A<br><font=20size=3D2=
=20color=3Dblue>I=20just=20want=20a=20confirmation=20on=20this.</font>=0D=
=0A<br><font=20size=3D3>&nbsp;</font>=0D=0A<br><font=20size=3D3>&nbsp;</f=
ont>=0D=0A<br><font=20size=3D2=20color=3Dblue>Thanks=20&amp;=20Regards<br=
>=0D=0AAshwin=20S<br>=0D=0ASoftware=20Engineer<br>=0D=0ATeleDNA=20Communi=
cation=20Pvt.=20Ltd.=20<br>=0D=0A----------------------------------------=
-------------------------------------------------------------------------=
-------------------------------------------------------------------------=
-----------------------------------------------------------<br>=0D=0ACONF=
IDENTIALITY=20NOTE:=20The=20content=20of=20this=20email=20transmission=20=
is=20confidential=0D=0Aand=20property=20of=20TeleDNA.=20The=20information=
=20in=20this=20mail=20is=20privileged=20and=0D=0Aintended=20only=20for=20=
the=20use=20of=20the=20entity(s)=20or=20the=20individual=20(s)=20to=20whi=
ch=0D=0Ait=20is=20addressed.=20If=20the=20reader=20is=20not=20an=20intend=
ed=20recipient,=20you=20are=20hereby=0D=0Anotified=20that=20any=20unautho=
rized=20disclosure,=20copying,=20distribution=20of=20this=0D=0Aelectronic=
ally=20transmitted=20information=20is=20strictly=20prohibited.=20If=20you=
=20are=0D=0Ain=20receipt=20of=20this=20electronic=20communication=20in=20=
error,=20please=20immediately=0D=0Anotify=20the=20sender=20and=20delete=
=20the=20information.</font>=0D=0A<br><font=20size=3D2=20face=3D"sans-ser=
if"><br>=0D=0A<br>=0D=0A***********************=20&nbsp;Aricent-Unclassif=
ied=20&nbsp;=20***********************</font>=0D=0A<table><tr><td=20bgcol=
or=3D#ffffff><font=20color=3D#000000><pre>"DISCLAIMER:=20This=20message=
=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20fo=
r=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addresse=
d.=20It=20may=20contain=20privileged=20or=20confidential=20information=20=
and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=
=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20have=20re=
ceived=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20origin=
ator=20immediately.=20If=20you=20are=20not=20the=20intended=20recipient,=
=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20from=
=20using,=20copying,=20altering,=20or=20disclosing=20the=20contents=20of=
=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for=20=0Al=
oss=20or=20damage=20arising=20from=20the=20use=20of=20the=20information=
=20transmitted=20by=20this=20email=20including=20damage=20from=20virus."=
=0A</pre></font></td></tr></table>
--=_alternative 0045FB62652572CA_=--
--=_mixed 0045FB5F652572CA_=
Content-Type: application/octet-stream; name="Ashwin S (Business Fax).vcf"
Content-Disposition: attachment; filename="Ashwin S (Business Fax).vcf"
Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlM7QXNod2luDQpGTjpBc2h3aW4gUyAoQnVzaW5l
c3MgRmF4KQ0KT1JHOlRlbGVETkEgQ29tbXVuaWNhdGlvbnMgUHZ0IEx0ZC47U01TQyBUZXN0aW5n
DQpUSVRMRTpTb2Z0d2FyZSBFbmdpbmVlcg0KVEVMO1dPUks7Vk9JQ0U6MDgwLTU2NjYxMTA3DQpU
RUw7SE9NRTtWT0lDRTowODAtMjY0ODg1MjANClRFTDtDRUxMO1ZPSUNFOjk5ODAgMTMyIDE1MA0K
VEVMO1dPUks7RkFYOjkxLTgwLTU2NjYxMTMyDQpBRFI7V09SSztFTkNPRElORz1RVU9URUQtUFJJ
TlRBQkxFOjswODAtNTY2NjExODAgLyA4MTsjMTAsIDNyZCBGbG9vcj0wRD0wQTEwMCBGZWV0IFJp
bmcgUm9hZD0wRD0wQUJUTSAxc3QgU3RhZ2U9DQo7QmFuZ2Fsb3JlO0thcm5hdGFrYTs1NjAgMDY4
O0luZGlhDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MDgwLTU2NjYxMTgw
IC8gODE9MEQ9MEEjMTAsIDNyZCBGbG9vcj0wRD0wQTEwMCBGZWV0IFJpbmcgUm9hZD0wRD0wQUJU
TSAxc3QgUz0NCnRhZ2U9MEQ9MEFCYW5nYWxvcmUsIEthcm5hdGFrYSA1NjAgMDY4PTBEPTBBSW5k
aWENCkFEUjtIT01FO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6OzsjMjM3LCAiQVNIV0lOSSI9
MEQ9MEE2dGggQSBDcm9zcywgM3JkIE1haW49MEQ9MEFWaWpheWEgQmFuayBMYXlvdXQ9MEQ9MEFC
ZT0NCmhpbmQgSUlNKEIpPTBEPTBBQmFubmVyZ2hhdHRhIFJvYWQ7QmFuZ2Fsb3JlO0thcm5hdGFr
YTs1NjAgMDc2O0luZGlhDQpMQUJFTDtIT01FO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6IzIz
NywgIkFTSFdJTkkiPTBEPTBBNnRoIEEgQ3Jvc3MsIDNyZCBNYWluPTBEPTBBVmlqYXlhIEJhbmsg
TGF5b3V0PTBEPTBBQmVoaT0NCm5kIElJTShCKT0wRD0wQUJhbm5lcmdoYXR0YSBSb2FkPTBEPTBB
QmFuZ2Fsb3JlLCBLYXJuYXRha2EgNTYwIDA3Nj0wRD0wQUluZGk9DQphDQpYLVdBQi1HRU5ERVI6
Mg0KVVJMO1dPUks6aHR0cDovL3d3dy50ZWxlZG5hLmNvbQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDph
c2h3aW5AdGVsZWRuYS5jb20NClJFVjoyMDA3MDQyN1QwNjI3NDVaDQpFTkQ6VkNBUkQNCg==

--=_mixed 0045FB5F652572CA_=--





From tsvwg-bounces@ietf.org Fri Apr 27 09:53:40 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhQtE-000595-3T; Fri, 27 Apr 2007 09:53:36 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HhQtC-00052p-Fh
	for tsvwg-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 09:53:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HhQtC-00050w-5H; Fri, 27 Apr 2007 09:53:34 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HhQt9-0000bK-3x; Fri, 27 Apr 2007 09:53:34 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3RDrFQd001089; Fri, 27 Apr 2007 16:53:29 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 16:53:19 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Apr 2007 16:53:14 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by
	esebh101.NOE.Nokia.com over TLS secured channel with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 16:53:09 +0300
Received: from [128.16.65.34] (essapo-nirac2528.europe.nokia.com
	[10.162.252.8])
	by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id
	l3RDr8WD011169; Fri, 27 Apr 2007 16:53:08 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <807BCBC7-A218-475A-826A-20E22ACBA1C4@nokia.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-68--341192691;
	protocol="application/pkcs7-signature"
To: tsvwg WG <tsvwg@ietf.org>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Fri, 27 Apr 2007 14:53:06 +0100
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 27 Apr 2007 13:53:09.0913 (UTC)
	FILETIME=[63EA6090:01C788D3]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1
Subject: [Tsvwg] publication requested: draft-ietf-tsvwg-cc-alt-02
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org


--Apple-Mail-68--341192691
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi, Secretariat (BCC'ed),

TSVWG requests publication of draft-ietf-tsvwg-cc-alt-02 as a BCP RFC.

Lars


Document Shepherd Write-Up

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

The document shepherd for this document Lars Eggert  
(lars.eggert@nokia.com). I have reviewed this document and believe it  
is ready for publication.


> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The document has been presented to the WG during several IETF  
meetings and has been reviewed by a number of key WG members. It has  
also been discussed in the IRTF's ICCRG and the wider research  
community.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

The document has received sufficient review.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

I have no specific concerns regarding this document.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

The consensus was clear, but not overwhelmingly strong.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

This has not happened.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

idnits 2.04.07 claims that there are minor formatting nits (one long  
line and several control characters) but the shepherd is unable to  
locate them in the draft.

>    (1.h)  Has the document split its references into normative and
>           informative?  Are there normative references to documents  
> that
>           are not ready for advancement or are otherwise in an unclear
>           state?  If such normative references exist, what is the
>           strategy for their completion?  Are there normative  
> references
>           that are downward references, as described in [RFC3967]?  If
>           so, list these downward references to support the Area
>           Director in the Last Call procedure for them [RFC3967].

The references are in order.

>    (1.i)  Has the Document Shepherd verified that the document IANA
>           consideration section exists and is consistent with the body
>           of the document?  If the document specifies protocol
>           extensions, are reservations requested in appropriate IANA
>           registries?  Are the IANA registries clearly identified?  If
>           the document creates a new registry, does it define the
>           proposed initial contents of the registry and an allocation
>           procedure for future registrations?  Does it suggest a
>           reasonable name for the new registry?  See [RFC2434].  If  
> the
>           document describes an Expert Review process has Shepherd
>           conferred with the Responsible Area Director so that the  
> IESG
>           can appoint the needed Expert during the IESG Evaluation?

The document has no IANA considerations.

>    (1.j)  Has the Document Shepherd verified that sections of the
>           document that are written in a formal language, such as XML
>           code, BNF rules, MIB definitions, etc., validate  
> correctly in
>           an automated checker?

There are no such sections in the document.

>    (1.k)  The IESG approval announcement includes a Document
>           Announcement Write-Up.  Please provide such a Document
>           Announcement Write-Up?  Recent examples can be found in the
>           "Action" announcements for approved documents.  The approval
>           announcement contains the following sections:
>
>           Technical Summary
>              Relevant content can frequently be found in the abstract
>              and/or introduction of the document.  If not, this may be
>              an indication that there are deficiencies in the abstract
>              or introduction.

The IETF's standard congestion control schemes have been widely shown  
to be inadequate for various environments (e.g., high-speed  
networks). Recent research has yielded many alternate congestion  
control schemes. Using these new congestion control schemes in the  
global Internet has possible ramifications to both the traffic using  
the new congestion control and to traffic using the currently  
standardized congestion control. Therefore, the IETF must proceed  
with caution when dealing with alternate congestion control  
proposals. The goal of this document is to provide guidance for  
considering alternate congestion control algorithms within the IETF.

>           Working Group Summary
>              Was there anything in WG process that is worth  
> noting?  For
>              example, was there controversy about particular points or
>              were there decisions where the consensus was particularly
>              rough?

The WG consensus on this document was clear, but not overwhelmingly  
strong.

>           Document Quality
>              Are there existing implementations of the protocol?   
> Have a
>              significant number of vendors indicated their plan to
>              implement the specification?  Are there any reviewers  
> that
>              merit special mention as having done a thorough review,
>              e.g., one that resulted in important changes or a
>              conclusion that the document had no substantive  
> issues?  If
>              there was a MIB Doctor, Media Type or other expert  
> review,
>              what was its course (briefly)?  In the case of a Media  
> Type
>              review, on what date was the request posted?

The document has been presented to the WG during several IETF  
meetings and has been reviewed by a number of key WG members. It has  
also been discussed in the IRTF's ICCRG and the wider research  
community.

>           Personnel
>              Who is the Document Shepherd for this document?  Who  
> is the
>              Responsible Area Director?

Lars Eggert (lars.eggert@nokia.com) was the document shepherd and  
also reviewed this document for the IESG.
--Apple-Mail-68--341192691
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg
VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+
BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms
FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv
WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz
4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm
rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjcxMzUzMDZaMCMGCSqGSIb3DQEJBDEWBBTeWCobuDBqnXCN
oJgwdoLmbxFnITCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw
DQYJKoZIhvcNAQEBBQAEggEAAwGT0uIgZej+9CbAYBEfwlSwwrWwZFmXHKifmVYck5nJ5LP7nEFk
1V3/4zSoLggTvECMkEVzUs2iWpeSBjOe3yedhtWGjxjSsLnjnoyVDZ5owqihOgwRkz8vfbVJJS4G
aQU21i6MXnZ0IWI8xWwLyYREac8Qn6nlCHqShfmyuIXLvZRBlHoMCBUj/r1EN3BC6nFjKQxWzrhK
zUiJ+/CswlGih8/YKhkOqWIeZtBhGs9KU0ID8JlURVhBGVg6B+BUZ47p6vetdkjtWPjj4SxXxmwS
iwJGXErmtq/mvtexF/McVwQckEg1aHIMuxdJ9oZvUEtqwdnAojVZIpoNuoR2uQAAAAAAAA==

--Apple-Mail-68--341192691--





From tsvwg-bounces@ietf.org Mon Apr 30 14:17:15 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiaQv-0000BB-Uh; Mon, 30 Apr 2007 14:17:09 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HiaQu-00009S-Cv
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 14:17:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HiaQu-00009K-2z; Mon, 30 Apr 2007 14:17:08 -0400
Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HiaQt-0003kA-HI; Mon, 30 Apr 2007 14:17:08 -0400
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144])
	by mail.wrs.com (8.13.6/8.13.6) with ESMTP id l3UIH0T6019423;
	Mon, 30 Apr 2007 11:17:00 -0700 (PDT)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by
	ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 11:16:59 -0700
Received: from [192.168.117.80] ([192.168.117.80]) by
	ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 30 Apr 2007 11:17:00 -0700
In-Reply-To: <20070406211624.DF8781C8DBC@lawyers.icir.org>
References: <20070406211624.DF8781C8DBC@lawyers.icir.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <31BB1FDE-1577-4069-BF40-5C3732FA1CF4@windriver.com>
Content-Transfer-Encoding: 7bit
From: David Borman <david.borman@windriver.com>
Date: Mon, 30 Apr 2007 13:16:57 -0500
To: mallman@icir.org
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 30 Apr 2007 18:17:00.0448 (UTC)
	FILETIME=[BEE39200:01C78B53]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: tcpm@ietf.org, Michael Scharf <michael.scharf@ikr.uni-stuttgart.de>,
	tsvwg@ietf.org
Subject: [Tsvwg] Re: [tcpm] Extending RFC 1323 window scaling? 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

(Catching up on some old email...)

On Apr 6, 2007, at 4:16 PM, Mark Allman wrote:

>
>>   (1) The semantics of the SEG.WND field in the TCP header could be
>>       changed, i. e., the receive window is scaled in <SYN,ACK>
>>       segments under some constraints. Whether or not the receive
>>       window is scaled could be announced explicitly by a flag, or
>>       implicitly, e. g., due to the presence of Quick-Start  
>> options or
>>       other options. However, changing the semantics of the receive
>>       window header field creates interoperation issues with hosts
>>       that do not implement such a modification.
>>
>>   (2) The true amount of free buffer space is announced somehow, and
>>       overwrites the (unscaled) value in the TCP header, which  
>> remains
>>       unscaled in order to be compatible with hosts that do not
>>       implement this mechanism. This requires some new mechanism to
>>       signal a scaled receive window in <SYN,ACK> segments.
>>
>> The proposed new TCP option is a straightforward realization of
>> approach (2).
>
> I am not sure if we need a (2).  As you note, Quick-Start is currently
> the only thing that really runs into a problem and maybe something  
> else
> could.  To be precise, I think we can say that the only place where  
> this
> is a problem is when the initiator of a connection wants to (and can)
> send more than 64KB in the first RTT of the connection.  Unless we
> pretty drastically change the rules it seems that this is going to  
> have
> to be done only with some explicit communication and so using that  
> as an
> implicit signal seems fine to me.  (We clearly botched this in  
> terms of
> Quick-Start because we were too dumb to think of it and you found it
> after publication.)  Further, it is not clear that we need to add new
> functionality like this for something experimental (Quick-Start).   
> But,
> maybe ...
>
> If I were going to take approach (2) I would suggest a two-byte option
> that indicates the value in the standard TCP header is to be scaled.
> Why add another 2 byte window value when one of them is going to be
> ignored?  This fails safe because if a host doesn't understand the new
> ("the window is scaled") option it will think the advertised window is
> unscaled and so less than it really is and so there is no danger in
> running into problems.

I'm not sure I agree.  Yes, it's safe in that if you treat a scaled  
window as unscaled, you will not send more data than they are willing  
to receive.  But if the shift value is large enough, and the initial  
window small enough, you can get a tiny initial window.  E.g., an  
extreme case, if your initial window is 256K, but you have a shift  
value of 14, that'll become a window of 16 bytes, not enough to send  
much of anything until you get a window update.

An alternate way of dealing with this situation where the initial  
window exceeds 64K would be to immediately follow the SYN,ACK with a  
window update; send the two packets out back-to-back.  (Has this  
already been mentioned?)  That would mean that Quick-start wouldn't  
be able to fully act just on the SYN,ACK, but should immediately get  
the window update with the right value, without having to wait for a  
full RTT.  The only down-side would be if the two packets got re- 
ordered, and the ACK with the window update arrived before the  
SYN,ACK.  In that case, the window update would be (and should be)  
dropped, because at a minimum, the scale factor that should be  
applied to it would be unknown (it's in the SYN,ACK).  So, a TCP  
implementation might need to still send out another window update  
when it got back the ACK completing the 3-way handshake, just to be  
sure that the window update got through.

			-David Borman
>
> allman
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm






From tsvwg-bounces@ietf.org Mon Apr 30 15:50:55 2007
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hibtd-0005mF-At; Mon, 30 Apr 2007 15:50:53 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43)
	id 1HibtK-00058e-4X
	for tsvwg-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 15:50:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HibtJ-00057n-JT; Mon, 30 Apr 2007 15:50:33 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HibtI-00032z-Qj; Mon, 30 Apr 2007 15:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B2C632AC7C;
	Mon, 30 Apr 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Hibso-0001lG-G0; Mon, 30 Apr 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Hibso-0001lG-G0@stiedprstage1.ietf.org>
Date: Mon, 30 Apr 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: tsvwg@ietf.org
Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-2960bis-04.txt 
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

--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		: Stream Control Transmission Protocol
	Author(s)	: R. Stewart
	Filename	: draft-ietf-tsvwg-2960bis-04.txt
	Pages		: 150
	Date		: 2007-4-30
	
This document obsoletes RFC2960 [RFC2960] and describes the Stream
   Control Transmission Protocol (SCTP).  SCTP is designed to transport
   PSTN signaling messages over IP networks, but is capable of broader
   applications.

   SCTP is a reliable transport protocol operating on top of a
   connectionless packet network such as IP.  It offers the following
   services to its users:
   --  acknowledged error-free non-duplicated transfer of user data,
   --  data fragmentation to conform to discovered path MTU size,
   --  sequenced delivery of user messages within multiple streams, with
       an option for order-of-arrival delivery of individual user
       messages,
   --  optional bundling of multiple user messages into a single SCTP
       packet, and
   --  network-level fault tolerance through supporting of multi- homing
       at either or both ends of an association.

   The design of SCTP includes appropriate congestion avoidance behavior
   and resistance to flooding and masquerade attacks.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tsvwg-2960bis-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-2960bis-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-4-30145150.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tsvwg-2960bis-04.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-tsvwg-2960bis-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-4-30145150.I-D@ietf.org>


--OtherAccess--

--NextPart--