From tsvwg-bounces@ietf.org Fri Apr 1 09:04:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27661; Fri, 1 Apr 2005 09:04:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMsN-0003U6-7j; Fri, 01 Apr 2005 09:11:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMf1-00073Q-5E; Fri, 01 Apr 2005 08:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMez-00073I-Ic; Fri, 01 Apr 2005 08:58:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27047; Fri, 1 Apr 2005 08:58:01 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMmJ-0003Du-0f; Fri, 01 Apr 2005 09:05:40 -0500 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j31Dvmq4037140; Fri, 1 Apr 2005 05:57:48 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id F368977A6FB; Fri, 1 Apr 2005 08:57:46 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 058042595AA; Fri, 1 Apr 2005 08:57:40 -0500 (EST) To: Sally Floyd From: Mark Allman In-Reply-To: <200503312307.j2VN7QEa090898@cougar.icir.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Ain't Even Done With the Night MIME-Version: 1.0 Date: Fri, 01 Apr 2005 08:57:40 -0500 Message-Id: <20050401135741.058042595AA@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sumitha@tamu.edu, reddy@ee.tamu.edu, eblanton@cs.purdue.edu, tcpm@ietf.org, tsvwg@ietf.org Subject: [Tsvwg] Re: a review for draft-ietf-tcpm-tcp-dcr-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2049269795==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --===============2049269795== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Sally- > I have one suggestion for presentation (a SHOULD, not a MUST), and > that is that the document include an overview of the algorithm before > jumping into the details of Sections 2.1, 2.2, 2.3, and 2.4. That > suggestion, and a few nits, are in the review below. We have received a number of private comments that are similar to this suggestion for a big picture explanation. It's a good idea and we'll endeavor to add such text. We'll also address your smaller issues in our next pass. Thanks a ton for your careful read of the document! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCTVNUWyrrWs4yIs4RAknKAJwKAdPWD7C8PIOljKfJmvqlRx1VhQCfXhSn c9DfIDSzFvpK6ELDgUNlqFQ= =Z3lM -----END PGP SIGNATURE----- --=_bOundary-- --===============2049269795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============2049269795==-- From tsvwg-bounces@ietf.org Fri Apr 1 11:45:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13779; Fri, 1 Apr 2005 11:45:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPNz-0001Sa-Nq; Fri, 01 Apr 2005 11:52:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPEr-0007NZ-NO; Fri, 01 Apr 2005 11:43:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPEq-0007LQ-4Y for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 11:43:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13653 for ; Fri, 1 Apr 2005 11:43:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPMB-0001NJ-GJ for tsvwg@ietf.org; Fri, 01 Apr 2005 11:50:52 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2005 08:43:06 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j31Gh3ZV022355 for ; Fri, 1 Apr 2005 08:43:04 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDO08491; Fri, 1 Apr 2005 08:43:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: tsvwg@ietf.org From: Baker Fred Date: Fri, 1 Apr 2005 08:43:02 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RFC 4041 Requirements X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit I note that RFC 4041 declares that discrimination among packets on the basis of color is no longer to be tolerated in the network. Does this mean that we need to withdraw proposals related to that? :^) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 14:52:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00207; Fri, 1 Apr 2005 14:52:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSJF-0000Nm-BS; Fri, 01 Apr 2005 15:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHS97-0005z6-8X; Fri, 01 Apr 2005 14:49:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHS95-0005z1-CO for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 14:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00012 for ; Fri, 1 Apr 2005 14:49:27 -0500 (EST) 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.33) id 1DHSGR-0000HY-5A for tsvwg@ietf.org; Fri, 01 Apr 2005 14:57:09 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2005 11:49:18 -0800 X-IronPort-AV: i="3.91,141,1110182400"; d="scan'208"; a="625127608:sNHT29504720" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j31JnGZV005353; Fri, 1 Apr 2005 11:49:16 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14575; Fri, 1 Apr 2005 11:49:15 -0800 (PST) Message-Id: <4.3.2.7.2.20050401134709.03aa3510@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Apr 2005 13:49:15 -0600 To: Baker Fred , tsvwg@ietf.org From: "James M. Polk" Subject: Re: [Tsvwg] RFC 4041 Requirements In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 08:43 AM 4/1/2005 -0800, Baker Fred wrote: >I note that RFC 4041 declares that discrimination among packets on the >basis of color is no longer to be tolerated in the network. Does this mean >that we need to withdraw proposals related to that? I think affects optical transport more than anything, as they will have to solve for putting all their bandwidth into a single lambda, thus preventing preferential treatments based on the color of the lasers. >:^) > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 15:58:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16308; Fri, 1 Apr 2005 15:58:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTLR-0005dM-0z; Fri, 01 Apr 2005 16:06:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTA2-0005uo-C9; Fri, 01 Apr 2005 15:54:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTA0-0005tt-46 for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 15:54:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14853 for ; Fri, 1 Apr 2005 15:54:30 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTHN-00055J-L1 for tsvwg@ietf.org; Fri, 01 Apr 2005 16:02:11 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j31Kqf606141; Fri, 1 Apr 2005 12:52:41 -0800 (PST) Message-ID: <424DB50C.7000304@isi.edu> Date: Fri, 01 Apr 2005 12:54:36 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Tsvwg] RFC 4041 Requirements References: <4.3.2.7.2.20050401134709.03aa3510@localhost> In-Reply-To: <4.3.2.7.2.20050401134709.03aa3510@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Baker Fred , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James M. Polk wrote: > At 08:43 AM 4/1/2005 -0800, Baker Fred wrote: > >> I note that RFC 4041 declares that discrimination among packets on the >> basis of color is no longer to be tolerated in the network. Does this >> mean that we need to withdraw proposals related to that? > > I think affects optical transport more than anything, as they will have > to solve for putting all their bandwidth into a single lambda, thus > preventing preferential treatments based on the color of the lasers. Agreed. WDM could be seen as revisiting "separate but equal" ;-) It might affect military nets, though, too - the whole red/black thing becomes moot in achromatic networks ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTbUME5f5cImnZrsRAtqxAJ0UX2LWz47Nv9hjs4miGACXlhhVzgCfX4gK Z/0ccPg40WSSd/dnytQ5Z6U= =Nl47 -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 16:36:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23783; Fri, 1 Apr 2005 16:36:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTvd-00006m-D2; Fri, 01 Apr 2005 16:43:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTnK-0000KM-UH; Fri, 01 Apr 2005 16:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTnI-0000KD-UI for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 16:35:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23679 for ; Fri, 1 Apr 2005 16:35:06 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTug-00005C-Nr for tsvwg@ietf.org; Fri, 01 Apr 2005 16:42:48 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2005 13:34:56 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j31LYs3S025498; Fri, 1 Apr 2005 13:34:54 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDO42638; Fri, 1 Apr 2005 13:34:53 -0800 (PST) In-Reply-To: <200504010025.j310Prj2092458@cougar.icir.org> References: <200504010025.j310Prj2092458@cougar.icir.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Baker Fred Subject: Re: [Tsvwg] Specifying Alternate Semantics for the ECN Field Date: Fri, 1 Apr 2005 13:34:52 -0800 To: Sally Floyd X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Mar 31, 2005, at 4:25 PM, Sally Floyd wrote: > http://www.icir.org/floyd/papers/draft-floyd-ecn-alternates-00a.txt thanks for your considerations. I think you're pretty much dead on. My belief is that re-interpreting a field in a manner differently than it has previously been defined makes life pretty difficult.. We chose to do that once in redefining the TOS byte from a precedence field and a set of bit flags to the DSCP and ECN fields; when we did so, we did so with great care, and only after significant research into what was actually used in the TOS byte in real networks, and provided for backwards compatibility with what we found to exist. My concern with the other ECN proposals I have seen is that they do not take that care. As such, they can only be used in a manner consistent with the RFC status "experimental use" as described in RFC 2026. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 16:41:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24583; Fri, 1 Apr 2005 16:41:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHU0h-0000SR-VV; Fri, 01 Apr 2005 16:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTqD-0000pv-0f; Fri, 01 Apr 2005 16:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTqB-0000pG-7C; Fri, 01 Apr 2005 16:38:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24134; Fri, 1 Apr 2005 16:38:04 -0500 (EST) Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTxZ-0000G7-Pi; Fri, 01 Apr 2005 16:45:46 -0500 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j31LaxPa010755; Fri, 1 Apr 2005 16:36:59 -0500 (EST) Subject: Re: [Tsvwg] RFC 4041 Requirements To: Joe Touch X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 1 Apr 2005 16:35:45 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 04/01/2005 04:37:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: "James M. Polk" , tsvwg-bounces@ietf.org, Baker Fred , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Can we discriminate based on age? And if not, what happens to FIFO queues, which CLEARLY discriminate on packet age? ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- Joe Touch To: "James M. Polk" Sent by: cc: Baker Fred , tsvwg@ietf.org tsvwg-bounces Subject: Re: [Tsvwg] RFC 4041 Requirements 04/01/2005 03:54 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James M. Polk wrote: > At 08:43 AM 4/1/2005 -0800, Baker Fred wrote: > >> I note that RFC 4041 declares that discrimination among packets on the >> basis of color is no longer to be tolerated in the network. Does this >> mean that we need to withdraw proposals related to that? > > I think affects optical transport more than anything, as they will have > to solve for putting all their bandwidth into a single lambda, thus > preventing preferential treatments based on the color of the lasers. Agreed. WDM could be seen as revisiting "separate but equal" ;-) It might affect military nets, though, too - the whole red/black thing becomes moot in achromatic networks ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTbUME5f5cImnZrsRAtqxAJ0UX2LWz47Nv9hjs4miGACXlhhVzgCfX4gK Z/0ccPg40WSSd/dnytQ5Z6U= =Nl47 -----END PGP SIGNATURE----- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 17:04:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26273; Fri, 1 Apr 2005 17:04:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUNJ-0001Iq-Cs; Fri, 01 Apr 2005 17:12:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHU8r-0005e9-Ie; Fri, 01 Apr 2005 16:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHU8o-0005e1-TN for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 16:57:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25850 for ; Fri, 1 Apr 2005 16:57:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUGD-00014M-2k for tsvwg@ietf.org; Fri, 01 Apr 2005 17:05:02 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2005 13:57:13 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j31Lv8ZV008736; Fri, 1 Apr 2005 13:57:08 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDO44889; Fri, 1 Apr 2005 13:57:06 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2d43289410e84915cda98fd31de5d3b4@cisco.com> Content-Transfer-Encoding: 7bit From: Baker Fred Subject: Re: [Tsvwg] RFC 4041 Requirements Date: Fri, 1 Apr 2005 13:57:05 -0800 To: Janet P Gunn X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Apr 1, 2005, at 1:35 PM, Janet P Gunn wrote: > Can we discriminate based on age? And if not, what happens to FIFO > queues, which CLEARLY discriminate on packet age? Age isn't mentioned in the RFC that I saw. So we can still do that - at least until the right to life crowd gets hold of the TTL field. They will be happy with RFC 2304, though. It preserves the randomness inherent in the system. I just noticed, in investigating that, that there remains a really odd case of discrimination present even in the RFC decrying it. The first bullet of section 2.2 indicates that any RFC describing a way to carry images must give careful consideration to the implications of carrying blue images. Having recently thought long and deep about inter-SDO protocols, I was also struck by the fifth bullet (it wasn't painful). It may not be important, given that participants are doomed to spend eternity on dial-up links, but one wonders what the implications are if the messages exchanged propose liaisons or are statements relevant to such liaisons. > On Apr 1, 2005, at 12:54 PM, Joe Touch wrote: >> James M. Polk wrote: >>> At 08:43 AM 4/1/2005 -0800, Baker Fred wrote: >>>> I note that RFC 4041 declares that discrimination among packets on >>>> the basis of color is no longer to be tolerated in the network. >>>> Does this mean that we need to withdraw proposals related to that? >>> >>> I think affects optical transport more than anything, as they will >>> have to solve for putting all their bandwidth into a single lambda, >>> thus preventing preferential treatments based on the color of the >>> lasers. >> >> Agreed. WDM could be seen as revisiting "separate but equal" ;-) >> >> It might affect military nets, though, too - the whole red/black >> thing becomes moot in achromatic networks ;-) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 18:09:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01219; Fri, 1 Apr 2005 18:09:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVNx-0003XI-L5; Fri, 01 Apr 2005 18:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVFe-00018H-MP; Fri, 01 Apr 2005 18:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVFc-000189-Ic; Fri, 01 Apr 2005 18:08:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01064; Fri, 1 Apr 2005 18:08:25 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVN1-0003Vc-9a; Fri, 01 Apr 2005 18:16:08 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j31N7S609443; Fri, 1 Apr 2005 15:07:28 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id PAA25588; Fri, 1 Apr 2005 15:07:28 -0800 (PST) Date: Fri, 1 Apr 2005 15:07:28 -0800 (PST) Message-Id: <200504012307.PAA25588@gra.isi.edu> To: touch@ISI.EDU, jgunn6@csc.com Subject: Re: [Tsvwg] RFC 4041 Requirements X-Sun-Charset: US-ASCII X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: tsvwg@ietf.org, jmpolk@cisco.com, tsvwg-bounces@ietf.org, fred@cisco.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad *> *> *> Can we discriminate based on age? Only if you set the Evil Bit. Bob Braden _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 1 18:15:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02087; Fri, 1 Apr 2005 18:15:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVTS-0003lf-9n; Fri, 01 Apr 2005 18:22:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVKv-0002ob-FZ; Fri, 01 Apr 2005 18:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVKt-0002oU-HM for tsvwg@megatron.ietf.org; Fri, 01 Apr 2005 18:13:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01937 for ; Fri, 1 Apr 2005 18:13:52 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVSI-0003jt-3f for tsvwg@ietf.org; Fri, 01 Apr 2005 18:21:35 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.8) with ESMTP id j31NCqlm013008; Fri, 1 Apr 2005 15:12:52 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200504012312.j31NCqlm013008@cougar.icir.org> To: Baker Fred From: Sally Floyd Subject: Re: [Tsvwg] Specifying Alternate Semantics for the ECN Field Date: Fri, 01 Apr 2005 15:12:52 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >On Mar 31, 2005, at 4:25 PM, Sally Floyd wrote: >> http://www.icir.org/floyd/papers/draft-floyd-ecn-alternates-00a.txt > >thanks for your considerations. I think you're pretty much dead on. Many thanks for the feedback. >My belief is that re-interpreting a field in a manner differently than >it has previously been defined makes life pretty difficult. >... > >My concern with >the other ECN proposals I have seen is that they do not take that care. >As such, they can only be used in a manner consistent with the RFC >status "experimental use" as described in RFC 2026. I am mostly neutral about the various proposals, and about whether they go as "experimental use" or as something else. But it seems to me that the RTECN proposal *could* end up being defined consistently with draft-floyd-ecn-alternates, in a way that was safe to deploy in the Internet. It is not there yet, however, I would say... - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Apr 4 11:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17325; Mon, 4 Apr 2005 11:19:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITUR-0002B4-Kz; Mon, 04 Apr 2005 11:27:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITJx-0005gv-2G; Mon, 04 Apr 2005 11:16:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITJv-0005go-LC for tsvwg@megatron.ietf.org; Mon, 04 Apr 2005 11:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17153 for ; Mon, 4 Apr 2005 11:16:53 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITRr-0001vN-Jo for tsvwg@ietf.org; Mon, 04 Apr 2005 11:25:08 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j34FGTO14571; Mon, 4 Apr 2005 11:16:29 -0400 (EDT) Received: from KCHAN-2K3.nortelnetworks.com (kchan-2k3.us.nortel.com [47.16.72.114]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G4PJP2JY; Mon, 4 Apr 2005 11:16:28 -0400 Message-Id: <6.0.3.0.0.20050404105445.04d3eff8@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 04 Apr 2005 11:15:58 -0400 To: Sally Floyd From: Kwok Ho Chan Subject: Re: [Tsvwg] Specifying Alternate Semantics for the ECN Field In-Reply-To: <200504012312.j31NCqlm013008@cougar.icir.org> References: <200504012312.j31NCqlm013008@cougar.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Baker Fred , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Sally: Thank you very much for the draft-floyd-ecn-alternates-00a.txt. We greatly appreciate all the guidance and advice you have provided. With respect to RTECN proposal: We have been listening and improving on how to accomplish a goal with a simpler method. As many of us are engineers, we continue to make trade-offs trying to provide the best possible solutions. We are trying to have the method we pick being lesser of the evils. We are still making improvements to the RTECN proposal and the co-authors don't think it is ready for the judgement call of which track it should be on and have not indicated that we want such judgement be made at this time. During the 62nd IETF in Minneapolis, we are asking for additional comments so that we can improve this draft. We are still keeping this draft as an individual contribution until it is ready. We understand what we are doing and trying our best for the benefit of the Internet. Thanks! -- Kwok -- At 07:12 PM 4/1/2005, Sally Floyd wrote: > >On Mar 31, 2005, at 4:25 PM, Sally Floyd wrote: > >> http://www.icir.org/floyd/papers/draft-floyd-ecn-alternates-00a.txt > > > >thanks for your considerations. I think you're pretty much dead on. > >Many thanks for the feedback. > > >My belief is that re-interpreting a field in a manner differently than > >it has previously been defined makes life pretty difficult. > >... > > > >My concern with > >the other ECN proposals I have seen is that they do not take that care. > >As such, they can only be used in a manner consistent with the RFC > >status "experimental use" as described in RFC 2026. > >I am mostly neutral about the various proposals, and about whether >they go as "experimental use" or as something else. But it seems >to me that the RTECN proposal *could* end up being defined consistently >with draft-floyd-ecn-alternates, in a way that was safe to deploy >in the Internet. It is not there yet, however, I would say... > >- Sally > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Apr 7 13:27:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16927; Thu, 7 Apr 2005 13:27:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJavr-0003Xs-4g; Thu, 07 Apr 2005 13:36:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJadW-0003HL-Ha; Thu, 07 Apr 2005 13:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJadV-0003HG-9y for tsvwg@megatron.ietf.org; Thu, 07 Apr 2005 13:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16174 for ; Thu, 7 Apr 2005 13:17:41 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJam6-0003BX-B5 for tsvwg@ietf.org; Thu, 07 Apr 2005 13:26:38 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2005 19:17:35 +0200 Received: from xbh-ams-331.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 j37HHUt7007152; Thu, 7 Apr 2005 19:17:32 +0200 (MEST) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 19:17:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2005 19:17:27 +0200 Message-ID: Thread-Topic: RSVP Aggregation over MPLS TE tunnels Thread-Index: AcU7F5MFmbWjis5DRbGTTFyErVhchgAfIirQ From: "Francois Le Faucheur \(flefauch\)" To: "Drake, John E" , "Bruce Davie \(bdavie\)" X-OriginalArrivalTime: 07 Apr 2005 17:17:31.0644 (UTC) FILETIME=[AEA98BC0:01C53B95] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: [Tsvwg] RE: RSVP Aggregation over MPLS TE tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable >> -----Original Message----- >> From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 >> Sent: jeudi 7 avril 2005 04:15 >> To: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) >> Subject: RSVP Aggregation over MPLS TE tunnels >>=20 >> Francois and Bruce, >>=20 >> Does your I-D handle the case of placing aggregate=20 >> reservations, rather >> than individual reservations, over an MPLS TE LSP? Hello John, Yes, it covers that case. Specifically, section 5 "E2E Reservations Applicability" says: =20 " The procedures defined in this document are applicable to many types=20 of E2E RSVP reservations including the following cases:=20 (1) the E2E RSVP reservation is a per-flow reservation where the=20 flow is characterized by the usual 5-tuple=20 (2) the E2E reservation is an aggregate reservation for multiple=20 flows as described in [RSVP-AGG] where the set of flows is=20 characterized by the =20 (3) the E2E reservation is a reservation for an IPSec protected=20 flow. For example, where the flow is characterized by the=20 as described in=20 [RSVP-IPSEC]=20 (4) the E2E reservation is an aggregate reservation for multiple=20 flows and where the set of flows are protected by IPSec=20 (5) the E2E RSVP reservation is itself an RSVP-TE reservation=20 for an E2E TE tunnel, so that LSP Hierarchy is achieved=20 [LSP-HIER]=20 " I believe (2) would be the case you are refering to, right? Cheers Francois >>=20 >> Thanks, >>=20 >> John=20 >>=20 >> John Drake >> Boeing Satellite Systems >> 2300 East Imperial Highway >> El Segundo, CA 90245 >> john.e.drake2@boeing.com >> (412) 370-3108 >>=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Apr 7 21:52:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29166; Thu, 7 Apr 2005 21:52:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiok-0003MZ-Pg; Thu, 07 Apr 2005 22:01:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJibe-0001mB-4X; Thu, 07 Apr 2005 21:48:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiUr-0000Om-42 for tsvwg@megatron.ietf.org; Thu, 07 Apr 2005 21:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28285 for ; Thu, 7 Apr 2005 21:41:18 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJidW-0002yc-82 for tsvwg@ietf.org; Thu, 07 Apr 2005 21:50:18 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA13213; Thu, 7 Apr 2005 20:41:06 -0500 (CDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j381f6708008; Thu, 7 Apr 2005 20:41:06 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 18:41:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2005 18:41:05 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC815BD5F@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: RSVP Aggregation over MPLS TE tunnels Thread-Index: AcU7F5MFmbWjis5DRbGTTFyErVhchgAfIirQAA1prZA= From: "Drake, John E" To: "Francois Le Faucheur \(flefauch\)" , "Bruce Davie \(bdavie\)" X-OriginalArrivalTime: 08 Apr 2005 01:41:05.0801 (UTC) FILETIME=[07B40790:01C53BDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Apr 2005 21:48:20 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] RE: RSVP Aggregation over MPLS TE tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Francois, Very good, thanks. I skimmed sections 3.1 and 3.2 and misunderstood what you meant by E2E reservation. Section 5 defines what you mean by E2E reservation and my one suggestion would be to consider moving the material in section 5 into section 2 (Definitions). Thanks, John=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Thursday, April 07, 2005 10:17 AM > To: Drake, John E; Bruce Davie (bdavie) > Cc: Francois Le Faucheur (flefauch); tsvwg@ietf.org > Subject: RE: RSVP Aggregation over MPLS TE tunnels >=20 > >> -----Original Message----- > >> From: Drake, John E [mailto:John.E.Drake2@boeing.com] > >> Sent: jeudi 7 avril 2005 04:15 > >> To: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) > >> Subject: RSVP Aggregation over MPLS TE tunnels > >> > >> Francois and Bruce, > >> > >> Does your I-D handle the case of placing aggregate > >> reservations, rather > >> than individual reservations, over an MPLS TE LSP? >=20 > Hello John, >=20 > Yes, it covers that case. >=20 > Specifically, section 5 "E2E Reservations Applicability" says: >=20 > " > The procedures defined in this document are applicable to many types > of E2E RSVP reservations including the following cases: > (1) the E2E RSVP reservation is a per-flow reservation where the > flow is characterized by the usual 5-tuple > (2) the E2E reservation is an aggregate reservation for multiple > flows as described in [RSVP-AGG] where the set of flows is > characterized by the DSCP> > (3) the E2E reservation is a reservation for an IPSec protected > flow. For example, where the flow is characterized by the > as described in > [RSVP-IPSEC] > (4) the E2E reservation is an aggregate reservation for multiple > flows and where the set of flows are protected by IPSec > (5) the E2E RSVP reservation is itself an RSVP-TE reservation > for an E2E TE tunnel, so that LSP Hierarchy is achieved > [LSP-HIER] > " >=20 > I believe (2) would be the case you are refering to, right? >=20 > Cheers >=20 > Francois >=20 > >> > >> Thanks, > >> > >> John > >> > >> John Drake > >> Boeing Satellite Systems > >> 2300 East Imperial Highway > >> El Segundo, CA 90245 > >> john.e.drake2@boeing.com > >> (412) 370-3108 > >> _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 05:17:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21206; Fri, 8 Apr 2005 05:17:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpki-0000H1-CW; Fri, 08 Apr 2005 05:26:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJpZm-0006F8-Ca; Fri, 08 Apr 2005 05:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJpZk-0006Dr-1D for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 05:14:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21098 for ; Fri, 8 Apr 2005 05:14:50 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpiS-0000BV-Sw for tsvwg@ietf.org; Fri, 08 Apr 2005 05:23:53 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2005 11:14:42 +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 j389E9tX000298; Fri, 8 Apr 2005 11:14:39 +0200 (MEST) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Apr 2005 11:14:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 11:14:29 +0200 Message-ID: Thread-Topic: RSVP Aggregation over MPLS TE tunnels Thread-Index: AcU7F5MFmbWjis5DRbGTTFyErVhchgAfIirQAA1prZAAFFxhcA== From: "Francois Le Faucheur \(flefauch\)" To: "Drake, John E" , "Bruce Davie \(bdavie\)" X-OriginalArrivalTime: 08 Apr 2005 09:14:35.0712 (UTC) FILETIME=[6212F400:01C53C1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: [Tsvwg] RE: RSVP Aggregation over MPLS TE tunnels X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable John, I see. We will look at how to make the notion of "E2E" reservation clear upfront in the document. Thanks. Francois >> -----Original Message----- >> From: Drake, John E [mailto:John.E.Drake2@boeing.com]=20 >> Sent: vendredi 8 avril 2005 03:41 >> To: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) >> Cc: tsvwg@ietf.org >> Subject: RE: RSVP Aggregation over MPLS TE tunnels >>=20 >> Francois, >>=20 >> Very good, thanks. I skimmed sections 3.1 and 3.2 and misunderstood >> what you meant by E2E reservation. >>=20 >> Section 5 defines what you mean by E2E reservation and my=20 >> one suggestion >> would be to consider moving the material in section 5 into section 2 >> (Definitions). >>=20 >> Thanks, >>=20 >> John=20 >>=20 >> > -----Original Message----- >> > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> > Sent: Thursday, April 07, 2005 10:17 AM >> > To: Drake, John E; Bruce Davie (bdavie) >> > Cc: Francois Le Faucheur (flefauch); tsvwg@ietf.org >> > Subject: RE: RSVP Aggregation over MPLS TE tunnels >> >=20 >> > >> -----Original Message----- >> > >> From: Drake, John E [mailto:John.E.Drake2@boeing.com] >> > >> Sent: jeudi 7 avril 2005 04:15 >> > >> To: Francois Le Faucheur (flefauch); Bruce Davie (bdavie) >> > >> Subject: RSVP Aggregation over MPLS TE tunnels >> > >> >> > >> Francois and Bruce, >> > >> >> > >> Does your I-D handle the case of placing aggregate >> > >> reservations, rather >> > >> than individual reservations, over an MPLS TE LSP? >> >=20 >> > Hello John, >> >=20 >> > Yes, it covers that case. >> >=20 >> > Specifically, section 5 "E2E Reservations Applicability" says: >> >=20 >> > " >> > The procedures defined in this document are applicable to many >> types >> > of E2E RSVP reservations including the following cases: >> > (1) the E2E RSVP reservation is a per-flow reservation where >> the >> > flow is characterized by the usual 5-tuple >> > (2) the E2E reservation is an aggregate reservation for >> multiple >> > flows as described in [RSVP-AGG] where the set=20 >> of flows is >> > characterized by the > destination address, >> > DSCP> >> > (3) the E2E reservation is a reservation for an=20 >> IPSec protected >> > flow. For example, where the flow is=20 >> characterized by the >> > as=20 >> described in >> > [RSVP-IPSEC] >> > (4) the E2E reservation is an aggregate reservation for >> multiple >> > flows and where the set of flows are protected by IPSec >> > (5) the E2E RSVP reservation is itself an RSVP-TE=20 >> reservation >> > for an E2E TE tunnel, so that LSP Hierarchy is achieved >> > [LSP-HIER] >> > " >> >=20 >> > I believe (2) would be the case you are refering to, right? >> >=20 >> > Cheers >> >=20 >> > Francois >> >=20 >> > >> >> > >> Thanks, >> > >> >> > >> John >> > >> >> > >> John Drake >> > >> Boeing Satellite Systems >> > >> 2300 East Imperial Highway >> > >> El Segundo, CA 90245 >> > >> john.e.drake2@boeing.com >> > >> (412) 370-3108 >> > >> >>=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 14:49:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22012; Fri, 8 Apr 2005 14:49:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJygi-0005Lp-RP; Fri, 08 Apr 2005 14:58:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyXD-0000FG-Eg; Fri, 08 Apr 2005 14:48:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyXA-0000FB-36 for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 14:48:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21966 for ; Fri, 8 Apr 2005 14:48:46 -0400 (EDT) Message-Id: <200504081848.OAA21966@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyfx-0005LC-Ku for tsvwg@ietf.org; Fri, 08 Apr 2005 14:57:54 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJyX2-0008sX-HC; Fri, 08 Apr 2005 18:48:40 +0000 To: tsvwg@ietf.org Date: Fri, 08 Apr 2005 11:48:39 -0700 From: Allison Mankin X-Spam-Score: 0.8 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b Cc: jon.peterson@neustar.biz, mankin@psg.com Subject: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 441502cf25997484ff0b8b79626c6b69 Transport Area WG (tsvwg) Monday, March 7 at 1530-1730 ============================= CHAIRS: Allison Mankin Jon Peterson Matt Zekauskas acted as scribe and produced these minutes. Thank you to Matt for the usual excellent reporting. A prize to the first person who finds the message about Paris hidden in the minutes below (by this co-chair). AGENDA Charter Discussion (chairs) Quickstart Update (Sally Floyd) (5 mins) draft-amit-quick-start-04.txt RSVP over MPLS-TE/DS-TE (Bruce Davie) (10 mins) draft-lefaucheur-rsvp-dste-01.txt RSVP IPSec (Bruce Davie) (10 mins) draft-lefaucheur-rsvp-ipsec-00.txt SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins) draft-tuexen-sctp-auth-chunk-03.txt draft-stewart-tsvwg-sctpthreat-02.txt SCTP Implementer's Guide (Randall Stewart) (10 mins) draft-ietf-tsvwg-sctpimpguide-13.txt TCP MIB (Matt Mathis) (10 mins) draft-ietf-tsvwg-tcp-mib-extension-06.txt Real-time Congestion Notification (Jozef Babiarz) (10 mins) draft-babiarz-tsvwg-rtecn-03.txt Diffserv Service Class (Kwok Ho Chan) (10 mins) draft-ietf-tsvwg-diffserv-service-classes-00.txt Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins) draft-chan-tsvwg-diffserv-class-aggr-01.txt MLPP Update (Fred Baker/James Polk) (15 mins) draft-ietf-tsvwg-mlpp-that-works-00.txt draft-ietf-tsvwg-mlef-concerns-00.txt draft-ietf-tsvwg-rsvp-bw-reduction-00.txt draft-baker-tsvwg-vpn-signaled-preemption.02.txt Quickstart Update (Sally Floyd) Sally quickly reviewed Quickstart. Quickstart IP option, requested rate & TTL in SYN. Routers may decrement request, and decrement RTT if they understand. SYNACK has RTT measurement and rate. The sender knows if all routers approve of the rate request. There were three main changes: the addition of a citation (discussion of router algorithms), and a discussion of misbehaving middleboxes, and a section on attacks on quickstart. The citation is for a paper that evaluates a whole range of router algorithms, from a minimum algorithm, to "extreme Quickstart", as well as a discussion of how to size your bandwidth request at the start. The attacks on Quickstart include attacking a router by bombarding it with many packets with Quickstart requests (router can rate-limit); Attack Quickstart itself by sending many requests that are not used (again, the router must have a mechanism to limit requests); won't hurt folks that don't want to use Quickstart. If have a misbehaving middlebox, something that rewrites the IP TTL, it will interfere with Quickstart (you can't tell if all routers agree to the request). There's no good answer to this one, it's just noted in the draft. Sally asked for feedback, and thinks it can be WGLC as experimental. There were a couple of "ship it"s from the audience. Jon said that if no other feedback, will issue WGLC. Allison said that they would like to see a couple of reviews from the WG during WGLC on the mailing list. Please contribute to the value of the WGLC. RSVP over MPLS-TE/DS-TE (Francois LeFaucheur) (10 mins) The key change to the draft is a closer alignment with the LSP hierarchy draft in the MPLS WG, which we agreed to do at the last meeting. They requested feedback from MPLS WG. They got some feedback, but at this stage, mostly suggestion for clarifications, nothing major. An appendix was added for informational purposes. A use case, how the aggregation solution can fit together with a VOIP architecture. The authors want to have accepted as a WG document; they feel it is pretty stable now. Jon asked for opinions. Fred Baker and James Polk both said they thought it should be a WG document. Jon asked for a hum. In favor of adopting: opposed: Jon declared a consensus to adopt this document as a working group item. Francois asked what were the concerns of those opposed. Joe Touch said that given silence of the room, individual submission seems in order instead of a working group submission. It's hard to say the document came out of the WG, if there is no support. Jon felt that there was substantial enough response to the hum that it should be a WG item. Any other opinions? Joe commented that the apathy is deafening. Allison proposed making a review group for RSVP. TSVWG is a big catch-all group, and so there can be a majority that doesn't care. However, we don't want to do a lot of work in an ad-hoc manner. RSVP also has some legacy issues, and Allison isn't comfortable spinning up a WG for this. In the use of this review group, we can do better than the not long enough face-to-face meeting sessions and times. Presentations have been more devoted to discussion of apathy than necessarily getting at the needed comment and review so one hopes that a review group will elicit the in depth consideration that is sought, while also sending onto the mailing list the public results in summary, very promptly. If this is useful, we might choose to create in addition review groups for other topics, for instance for the next up SCTP implementation guide. Rsvps for rsvp group a moi... People that are interested in working on RSVP should send a message to the chairs. There are a lot of RSVP workers around, some from NSIS. This is not the best environment for active discussion, and we need to improve. So identify yourself in person over the next few days or by email to the chairs. The chairs will name an RSVP review group of the active RSVP people, and get you activated. Melinda Shore said that she wasn't apathetic; wasn't sure what to say except "uh huh". She thinks this work should be done. Why? To get through IESG, has to go through WGLC. There were calls of "not trues" from audience. Joe wanted to know if there were any standards here, or was this document informational? He thought Allison's point was well taken; get a group of people, and show that there is energy. if so, then we can make a decision about it being a working group document. If no one reads it except the authors, and there is no one to review the document it shouldn't be here. Tom Phelan said that he was not apathetic, not an author, and has given lots of feedback to the authors. Like Melinda, he didn't know what to say except uhhuh. Francois noted that many others outside group have read the document and commented on it. Allison noted that there has been discussion both in past meetings and on the mailing list. There are a lot of different topics in the group, and an a RSVP discussion group is one way to move forward; she didn't think there was a big problem. RSVP IPSec (Francois LeFaucheur) (10 mins) See slides. Looking for aggregation solutions for RSVP, in the context of IPSEC VPNs. Hide and aggregate reservations on IPSEC tunnels, given a core cloud that supports diffserv. We want end-to-end RSVP reservations. These must be hidden in core inside IPsec tunnels. But once you hide them, to support right e2e reservation, need to reserve resource for aggregate traffic carried over the IPsec tunnels. They thought problem was solved with existing RFCs - 2207 & 3175. Looking harder, that is not the case. 2207 is RSVP extensions for IPSec flows, but it doesn't address aggregation. 3175 describes aggregation of RSVP. However, it doesn't support IPSec between aggregator and deaggregator. This draft: do both at same time. Francois showed a picture, and a new packet format that has both bits of information necessary. (See slides.) The remaining open items: * Add text delineating the responsibilities of aggregators & deaggregators. There are no specific issues, there is only some explanation needed. * Add text about how to handle dynamic updates of security associations. There may be an elegant solution: change the SPI to renew the association. Give a mechanism to do it without deallocating and reallocating resources. Right now there is a discussion in the middle of the security section, and it needs to be moved. This is new work, the authors would like feedback. They would also like to progress the work, hopefully here. Allison asked if the authors had ever viewed the RSVP security analysis document from the NSIS group. They should review it, and look at the security piece. 2207 was done a while ago, and it's security review might not be good enough. Allison asked for the issues to be put onto the mailing list, and get discussion going. SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins) The origin of document is a paper by T. Aura P. Nikander and G Camarillo analyzing SCTP from protocol point of view, and looking at implementations. Given that paper, we changed some things in the protocol, and listed these threads in the ID, and added some other possible attacks. Michael then went through the threats at high level. * Address camping or stealing. Attacker guesses port number the victim will use next, and the victim must be multihomed. Path verification procedure in the implementation guide will prevent, and random port number selection makes it harder. * Association hijacking. Attacker must take over IP addresses. Gets a VTAGs in cookie according to the original RFC 2960. Implementer's guide now requires what is in cookie are random numbers, not real tags, so vtags still protect against blind attacker. * Association hijacking #2. If application doesn't pay attention to restart, it doesn't realize endpoint may have changed. Pay attention to notifications. * Bombing attack (1). Trick server into sending packets to a victim. Only works if victim doesn't understand SCTP. (If it did, it will send an ABORT.) Server isn't paying attention to ICMP. Attacker is also spoofing acknowledgements. The implementer's guide now says how to handle ICMP messages. If you get acks for data you have never sent, abort the association. Finally, do the path verification procedure to make sure the IP address is correct. * Bombing II. Send INIT give address of victim. Get cookie that you send to endpoint. Now the path verification mechanism is itself used as an attack. Have a low number of heartbeats that send at any time. Want a high number for preventing attacks, but here want to limit. The Implementer's guide says to limit the hartbeats to a "maxburst" parameter. * Association redirection. Same info in two different places in the packet... but some implementations only use the common header. Can get receiver of the packet into an unstable state. The implementer's guide says to drop the packet if the numbers don't match. In summary, some attacks are not possible if you implement new procedures. Some can be limited in time by tuning appropriate parameters. The authors are interested in if someone has more attacks or ideas... such that we can list and analyze. They are not interested in attacks against implementations (bugs) all protocol related. any questions... Jon asked if Gonzalo (who has written a lot on SCTP) thinks it is good. He gave it a thumbs up :) Next Michael turned to the chunk authentication draft. An SCTP extension on dynamic IP (LIP) has been stable for 2 years, but not progressed due to security concerns. This draft is the missing security part. With LIP one can change the address of an association. This draft provides a mechanism to ensure that chunks have been sent from an endpoint that you think they came from. At the beginning of the SCTP association, exchange some material so can verify. This does not address man-in-the-middle attacks from the beginning of the connection (but that is true without LIP too). LIP will be required to use this extension. (See slides.) Michael asked if we can we adopt this draft. It is needed to progress the other document. There were no comments. Jon asked for a hum, in favor of adoption as an official working group document. opposed? Jon declares consensus (within room) to adopt. SCTP Implementer's Guide (Randall Stewart) (10 mins) There are two outstanding issues. First, one that is just on the implementer's list: PPID field, and text change for byte order. There was lots of discussion, and we have a wording proposal. Second, Armando and Randy (Stewart) were supposed to put in a note regarding Karn's algorithm and RTT. Doing that now. After both of these go in it's ready for WGLC. It is an informational document. Original idea with Scott Bradner, is that it's a way forward to get a 2960bis. Start up a bis once this gets into the RFC Editor's queue. We'd like to set up some RFC2960bis ground rules. It's up to the ADs, but what we'd prefer, is that when we open up the bis (after the implementer's guide is in the RFC Editor's queue), only changes in the implementer's guide are applied to 2960. E.g.: wording, missed references to adler-32 checksum. But no field day on let's add "X". At end result would be obsolete 2960 and 3309 (the checksum change), and the new draft would cycle back at Proposed. We would move it forward after a couple of more interops (but not until the implementer's guide is in the RFC Editor's queue). Jon felt that, speaking personally, it was a well thought out way to go forward. Randy said he had lived through three WGLC and three IESG LC, and he doesn't want to do it again. Jon said that if there are any outstanding issues, get them to Randy quickly. TCP ESTATS MIB (Matt Mathis) (10 mins) Matt reviewed the motivation for the MIB. TCP already measures lots of stuff, and knows where bottlenecks are. We added explicit instrumentation on what causes TCP to stop sending data controls to support useful workarounds. The big motivation is a hard end-to-end diagnostic problem. With TCP, symptoms scale with RTT. Tests in local paths pass, move to longer paths and they can fail. This leads to false logic and lots of "buck passing". The ESTATS MIB would let you rescale properties of short path to longer path. (See slides for details.) The latest revision is 06. We haven't changed details of objects, but did change the structure of the MIB. There are three sets of required variables: * state vars * performance instrumentation * first tier diagnostic instrumentation There are also three sets of optional variables (focus on where problems are). * path (loss, reordering, dup, etc) * stack (impact and state of control algs) e.g. for cwnd validation * app (is app stalling or tcp?) And a little table of writeable controls * limit cwnd and limit rwind: can do instead of starving tcp for buffer space. (starving: interferes with recovery alg, retrans, and app that doesn't have stable perf (eg disk seeks causing dry spells) * ssthresh: for slow-start. like limited sstart. The TCP roadmap was helpful in this rewrite. The big open tech issue: there have been two Industrial implementers looking at the MIB. They have commented that there is too much required, that may make it unimplemented in practice. It's easy to juggle variables between tables. There are also SMI representation issues. We need help - the duration object has proven problematic. Want high precision for short flows. MIB uses 0 based counters. All counters start at O; can always look at stats, but then need duration object, which could be around for weeks and months. Need more than 32 bits of microseconds, anyway. We also want to delta on duration, so compute rates. That means no time-of-day numbers in duration... because of discontinuities in clock adjustments. Allison: do you have an SNMP expert? Should we ask for volunteers here? Dan Romascanu volunteers. In addition, big worry is if we have overlooked something obvious. 65 page MIB, and description is terse. Allison mentions that Dan Romascanu has experience writing for extension in the future. Fred Baker noted that he doesn't know anything about mibs, but if you have a 65 page MIB, and descriptions are terse, this causes concern. If I can think of algorithm that can be described, and want... can mail in object. Find myself wondering how many objects are specific to one implementation or another, and not general. Matt said they are pretty careful about that. My background is BSD, and this was done with Linux, so we believe it can be done at least twice. As much as possible, objects are described in terms of standards (RFCs) or TCP state vars. Fred said that older TCPs had SRTT... more recent ones keep mean RTT and variance in RTT. There are differences in way mean and variance are calculated. Start high and average down, or start at initial RTT of SYN/ACK, and end up with different things. He's concerned. How standardize something like that? The RTO calculation is on standards track, the MIB refers to that RFC. Ones that do something different are not compliant. Matt is getting tired of this project; he will get more implementer's experience, and get MIB doctor review, and hopes to have WGLC sometime this summer. Allison thought that we need MIB advice right now. We've go a volunteer to help with MIB formalisms; do that in parallel with additional implementers and researchers. There is a formal thing called "MIB doctor review", which happens after WGLC; a second round. So, take Dan's advice now, and go through a round of MIB formalism first. There were no other comments. Real-time Congestion Notification (Jozef Babiarz) (10 mins) Jozef started with a quick status update. Sally is reviewing. The semantics have been changed to align with 3168. Added a token bucket example, but it is an example; vendors are free to use whatever they want for marking. A description of ECN marking behavior has been added. A description of mis-marking or cheating detection was added. Jozef then compared 3168 semantics to what is proposed in this draft. (See slides.) Two levels of congestion versus 1 level in 3168. Use a real-time measurement technique to detect congestion, versus AQM in 3168. The next steps include cleaning up the text so that ECN semantics are uniformly described; describe how ECN capable and non-ECN capable endpoints interact; address how real-time inelastic ECN-capable flow will react when it encounters a non-diffserv router that supports 3168. Looking for feedback and comments. David Black volunteered to be a reviewer. This draft is related to trouble he's making in NSIS. NSIS has draft that is proposing to signal and react to congestion. He thinks the use cases are RT, but it's not clear. ECN is a candidate mechanism for what they want to do, and this may be related. The draft is the RMD draft in NSIS. Look for the congestion signaling support in it. Second Sally's comment: figuring out how this works when you have just 3168 in a router is crucial. Sally followed up, and said she needed to get back to an old chore, writing an ID for requirements for alternate semantics to ECN. There have been a number of proposals. Think that the requirements are one of (1) only deployable in closed environment (and not safe for general use) (2) provide some mechanism that makes sure that traffic that requires alternate ECN semantics only encounters routers that support semantics (perhaps something like Quickstart) (3) if traffic happens to encounter older router 3168... that the end node response is TCP-friendly. Colin Perkins noted that a companion draft was mentioned that tried to define an RTP payload format for ECN. Will that go to AVT, or discuss here. Jozef was not planning to bring the draft forward at this time; he wants to "socialize it" and decide. If there is interest, let's talk offline. Colin mentioned that he was AVT co-chair. He wanted to make sure that it was reviewed by people that understood RTP as well as the TSV community. Brian Carpenter, as the guardian of the "diffserv flame", said that way the draft is written it is not immediately apparent that it is intimately associated with diffserv; but the draft only makes sense in a diffserv context. The presumption is that EF DS is being used for this traffic. That's part of the mechanism for knowing that it is not regular ECN. However, it could also could be a new PHB (association of a diffserv codepoint with the new ECN behavior). The discussion of that issue should be in this draft, and if you can run this simultaneously with EF PHB and no ECN. It gets complicated needs a discussion. Also realize that we mucked around with transport philosophy in DS... the TOS byte doesn't exist. If David becomes a reviewer, he would find that. Gorry Fairhust didn't quite get a strong case for 2 levels, which seems to be main point. Is there a use case? Jozef said that the companion draft describes how to use it for admission control. There are a bunch of uses: admission control, calls with high precedence, preemption, ... and we felt that 2 levels would address. Perhaps we need text to say how someone would use this if they only want one level. Fred Baker asked if Jozef had followed a comment related to this that he made on the mailing list. Jozef said that he got part, had a partial response, and wanted to talk. Fred said that he was wondering how to use this in a world with different people having different policies. It gives us a measurement, but what do we do with the measurement. It may be that someone else needs to do something -- a different SIP proxy, or in some different space. It's not clear how the application can be depended on to handle that. This is something that draft needs to go into, and not just say "application's problem". Jozef asked if it's more appropriate for a separate draft, describing use. There is mechanism here. Policy will depend on the application, and how to use. This needs to be stated and guidance given, but a separate draft seems more appropriate. Fred thought that might be, but RFC 3247 has updates to EF to make it predictable. If traffic is experiencing marks, predictability goes away. Perhaps a different draft, or an appendix, but there must be guidance for real applications. James Polk agreed. You've mentioned that one or more of these indications could provide for session pre-emption. How? Jozef stated that the marking is passed to the end points. They can send to the network manager controlling preemption. Flows indicate that they have reached the 2nd level of congestion. The manager can select those flows, and check policy. If they can be preempted, then they can be removed. James asked if a interface has 1000 flows, and reaches capacity, is this second level? If all those flows are marked, all endpoints may react at the same time. Tell server to tell router? Jozef says that one way with a centralized manager that gets all these, and it can then decide which to kill. David said that is exactly where NSIS RMD is headed; we need to rationalize and do it once. Stephen Norys from BT had another question about 2 levels. In particular, how do you cope with toggling between levels? If the algorithm is vendor dependent; different vendors could produce different answers, and the stream may switch back and forth between the two levels. Think you want some kind of ramp effect, rather than just 2 levels. Georgios Karagiannis, an author of the NSIS draft resource management in diffserv: Related to David's remark... on Thursday we will discuss different alternatives, only one of them is this one. Allison noted that it is reasonable for people to go to NSIS on Thursday. It would be good to have more discussion. This is only part of the RMD work. Resolved: Jozef and the RMD folks are to talk about their work's potential overlap. Diffserv Service Class (Kwok Ho Chan) (10 mins) This is the fourth version, but first as WG item. The notion of administrative service classes has been removed; the network control class (because of the first change) is now just routing and network control, everything else is just a standard class; the multimedia conferencing discussion changed from "elastic flows" to rate-adaptive flows, since they are really inelastic flows that can change rate; the ring clipping discussion has been moved to the appendix. Updated references. The authors feel all outstanding issues have been resolved, and would like to start WGLC. No comments. Allison asked for the opinion of group on this, by a hum. Jon and Allison reserve right to review it prior to WGLC, because they haven't done the chairs' review yet. Those that support WGLC at this time for this document, which has been at four or five meetings now, please hum: Those that don't support, or oppose it, please hum: Allison declares consensus towards moving to LC good. Will review it, and look towards moving it forward. Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins) This is an extension of the last draft: how to aggregate service classes if you don't need detail. Want to allow less-granular treatment where not needed, but preserve end-to-end notion of service requirements that application wants. After discussions, think four treatment aggregates are the right number. Network control, real time, assured elastic, and elastic. Would like feedback on the number, and the names. The draft would provide guidance as to how perform aggregation, and could be used as a foundation for indications between providers. Not sure how yet... See slides for detail. Next steps are to cleanup guidelines on aggregation, and add a discussion about using MPLS to express aggregates. We would like comments back. Jon said it would be good to see mailing list discussion. MLPP Update (Fred Baker/James Polk) (15 mins) Four drafts. First, the MLEF concerns draft has been posted as a WG document pursuant to discussion last time. This changed the draft handle only. Second, our MLPP proposal which is RSVP based. We did a minor update and submitted as a WG draft. There were errors in the appendix with respect to SIP call flows; they have been fixed. Other than that it's the same. Third, at last meeting, James talked about RSVP bandwidth reduction thing. This identified a bug in RFC 3181 when it comes to dealing with aggregate reservations. If I need to preempt call within reservation, it has me tear down and set up with new number. This has a giant hole... this draft suggests that one simply reduce bandwidth. "accept if doesn't exceed X", and the endpoint changes codec or whatever is the right thing. This draft considers backwards compatibility. Fourth, the last draft, is a use case for bw reduction thing. A VPN network with multiple levels of VPNing. This is still an individual submission. The draft posits that VPN router might be two boxes. Talk about what crosses the private interface between them. The other 3 pretty sure about. This one needs work; dinner tomorrow night is a discussion of this draft with others that are interested. we want: We want the first three to move forward. mlef-concerns -> informational mlpp that works: informational or BCP bw-reduction -> proposed. it's a protocol. As to the last one... If the way we get people to read & comment is to go to last call, I would like to go to last call. We want people to read & comment. So LC to informational? Mike Pierce: object vehemently to MLEF concerns going anywhere. The MLEF concerns document is to object to and provide comments on draft that myself and Steve Silverman wrote on MLEF. We have seen it.. and responded to it two years ago. We have made changes. To show you how bad it is... look in the draft reference section. It references the Jan. 2004 version that has concerns with. However, the MLEF document has been revised twice, and this draft doesn't reference updates, much less recognize modifications made to MLEF. The MLEF concerns actual title is "MLEF without capacity admission does not satisfy MLPP requirements", but we said that from the beginning. The version from way back when that was referred to... included explicit statement that it would not work without call admission control. We strengthened that statement. Yet this doc keeps arguing that point. In addition, this document contains a large number of technical inaccuracies. For example, g709 increasing throughput in face of loss. It is theoretically possible for a codec to do that, but this one doesn't. It talks about having 3 specific rates... Jon: don't want to take exception, but this is a more detailed discussion than we have time for. But we need to have the discussion. Mike objects to the document proceeding, and is not sure how it to WG status; his recollection is that there was no agreement. Jon believe there was consensus, and the first time that Mr. Baker spoke to us about it, there was strong consensus for this work. James Polk: to last point, about ILBC not being variable... Alan Durek wrote part of that. He is the author of that protocol. He is who helped write section. Mike said it's not in rfcs, though. Scott Bradner agreed that this particular document that was reviewed at ieprep was a very important document in it's day. However, he's not sure if needs to be RFC, unless it is recast as "concerns about non-admission controlled attempts at priority". It is an instructive document, but not sure it deals with the alternatives on table today. Would agree that it should fade out, but strongly support moving the others forward. Jon asked for Fred to comment. Fred stated that when the document was first published, he didn't expect it to be an RFC. He could go either way. James said that one of reasons why we regenerated this six months ago or so is that we had a couple other customers, other than us government, that wanted to promote diffserv-based QoS using that mechanism. So we wanted to have the concerns documented. He agreed with Scott that the scope ought to be broader. Fred said that he heard that if this document is to become an RFC at all, the working group must tell him what to see. Jon said that he believed the working group requested that rather than document the problems with a specific proposal, speak to general design principles that are objectionable. Scott agreed. Jon noted that we are out of time; clearly there should be more discussion on issues. Jon invited Mike to bring technical objections to list. Jon then declared the meeting to be closed. ------- End of Forwarded Message _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 16:00:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06874; Fri, 8 Apr 2005 16:00:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJznA-00035T-Cr; Fri, 08 Apr 2005 16:09:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzRn-00071N-Tg; Fri, 08 Apr 2005 15:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzRm-00071A-H5 for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 15:47:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02210 for ; Fri, 8 Apr 2005 15:47:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzab-00016w-1h for tsvwg@ietf.org; Fri, 08 Apr 2005 15:56:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Apr 2005 12:47:08 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j38Jl6ZV006704; Fri, 8 Apr 2005 12:47:07 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA21147; Fri, 8 Apr 2005 12:47:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20050408144050.03444f00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Apr 2005 14:47:05 -0600 To: mankin@psg.com, tsvwg@ietf.org From: "James M. Polk" Subject: Re: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated) In-Reply-To: <200504081848.OAA21966@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.9 (+) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Chairs I'm not sure I agree with the minutes regarding the (heated) MLEF Concerns discussion. I believe I agreed with Scott when he said this is a worthy document to move forward *IF* it were broadened to a larger problem area than just the US Gov's desire for MLEF for MLPP networks. I believe what was agreed was that I (with Fred) would rewrite the Intro and conclusion sections of the ID to make its applicability wider, but that the core of the ID was on the right track. Obviously there will need to be a review of the core of the ID if the rewritten sections change what should be in the core of the doc. comments BTW - you hid the Paris comment well, as I haven't found it yet At 11:48 AM 4/8/2005 -0700, Allison Mankin wrote: >Transport Area WG (tsvwg) > >Monday, March 7 at 1530-1730 >============================= > >CHAIRS: Allison Mankin > Jon Peterson > > >MLPP Update (Fred Baker/James Polk) (15 mins) > >Four drafts. > >First, the MLEF concerns draft has been posted as a WG document >pursuant to discussion last time. This changed the draft handle only. > >Second, our MLPP proposal which is RSVP based. We did a minor update >and submitted as a WG draft. There were errors in the appendix with >respect to SIP call flows; they have been fixed. Other than that >it's the same. > >Third, at last meeting, James talked about RSVP bandwidth reduction thing. >This identified a bug in RFC 3181 when it comes to dealing with aggregate >reservations. If I need to preempt call within reservation, it has me >tear down and set up with new number. This has a giant hole... >this draft suggests that one simply reduce bandwidth. "accept if doesn't >exceed X", and the endpoint changes codec or whatever is the right thing. >This draft considers backwards compatibility. > >Fourth, the last draft, is a use case for bw reduction thing. >A VPN network with multiple levels of VPNing. This is still >an individual submission. The draft posits that VPN router >might be two boxes. Talk about what crosses the private interface >between them. > > >The other 3 pretty sure about. This one needs work; dinner tomorrow >night is a discussion of this draft with others that are interested. > >we want: > >We want the first three to move forward. >mlef-concerns -> informational >mlpp that works: informational or BCP >bw-reduction -> proposed. it's a protocol. > >As to the last one... If the way we get people to read & comment >is to go to last call, I would like to go to last call. We >want people to read & comment. So LC to informational? > >Mike Pierce: object vehemently to MLEF concerns going anywhere. >The MLEF concerns document is to object to and provide comments on draft >that myself and Steve Silverman wrote on MLEF. We have seen it.. >and responded to it two years ago. We have made changes. >To show you how bad it is... look in the draft reference section. >It references the Jan. 2004 version that has concerns with. >However, the MLEF document has been revised twice, and this draft >doesn't reference updates, much less recognize modifications made to MLEF. > >The MLEF concerns actual title is >"MLEF without capacity admission does not satisfy MLPP requirements", >but we said that from the beginning. >The version from way back when that was referred to... included >explicit statement that it would not work without call admission control. >We strengthened that statement. Yet this doc keeps arguing that point. > >In addition, this document contains a large number of technical inaccuracies. >For example, g709 increasing throughput in face of loss. >It is theoretically possible for a codec to do that, but this one doesn't. >It talks about having 3 specific rates... > >Jon: don't want to take exception, but this is a more detailed discussion >than we have time for. > >But we need to have the discussion. Mike objects to the document >proceeding, and is not sure how it to WG status; his recollection is >that there was no agreement. > >Jon believe there was consensus, and the first time that Mr. Baker >spoke to us about it, there was strong consensus for this work. > >James Polk: to last point, about ILBC not being variable... >Alan Durek wrote part of that. He is the author of that protocol. >He is who helped write section. > >Mike said it's not in rfcs, though. > >Scott Bradner agreed that this particular document that was reviewed >at ieprep was a very important document in it's day. However, he's >not sure if needs to be RFC, unless it is recast as >"concerns about non-admission controlled attempts at priority". >It is an instructive document, but not sure it deals with the alternatives >on table today. Would agree that it should fade out, but strongly support >moving the others forward. > >Jon asked for Fred to comment. Fred stated that when the >document was first published, he didn't expect it to be an RFC. >He could go either way. > >James said that one of reasons why we regenerated this six months >ago or so is that we had a couple other customers, other than us government, >that wanted to promote diffserv-based QoS using that mechanism. So we wanted >to have the concerns documented. He agreed with Scott that the >scope ought to be broader. > >Fred said that he heard that if this document is to become an RFC at all, >the working group must tell him what to see. > >Jon said that he believed the working group requested that rather than >document the problems with a specific proposal, speak to general design >principles that are objectionable. > >Scott agreed. > >Jon noted that we are out of time; clearly there should be more discussion >on issues. Jon invited Mike to bring technical objections to list. Jon >then declared the meeting to be closed. > > > >------- End of Forwarded Message > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 16:14:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08599; Fri, 8 Apr 2005 16:14:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK00g-00044N-4q; Fri, 08 Apr 2005 16:23:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzrj-0007SN-UP; Fri, 08 Apr 2005 16:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzrh-0007SI-Ru for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 16:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08580 for ; Fri, 8 Apr 2005 16:14:04 -0400 (EDT) Message-Id: <200504082014.QAA08580@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK00X-00043y-7z for tsvwg@ietf.org; Fri, 08 Apr 2005 16:23:13 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJzrg-000KqV-1c; Fri, 08 Apr 2005 20:14:04 +0000 To: "James M. Polk" Subject: Re: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated) In-reply-to: Your message of Fri, 08 Apr 2005 14:47:05 -0600. <4.3.2.7.2.20050408144050.03444f00@localhost> Date: Fri, 08 Apr 2005 13:14:04 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tsvwg@ietf.org, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 James, > I'm not sure I agree with the minutes regarding the (heated) MLEF Concerns > discussion. I believe I agreed with Scott when he said this is a worthy > document to move forward *IF* it were broadened to a larger problem area > than just the US Gov's desire for MLEF for MLPP networks. > > I believe what was agreed was that I (with Fred) would rewrite the Intro > and conclusion sections of the ID to make its applicability wider, but that > the core of the ID was on the right track. Obviously there will need to be > a review of the core of the ID if the rewritten sections change what should > be in the core of the doc. > comments > I think the minutes words are *consistent with your recollection of not killing the draft, but broadening its applicability. While doing that, it needs to have some specific technical points in the interior addressed as well - Mike was supposed to send specific points to the list in the form of a constructive document review. But if others think we need the minutes to say so (instead of just this email thread), we could add that "It was resolved James would revise the draft to give it applicability to a larger problem area, and to update it - in addition a constructive document review was promised from Mike Pierce." > BTW - you hid the Paris comment well, as I haven't found it yet It's like a puzzle message, not really a comment. Allison _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 17:24:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13517; Fri, 8 Apr 2005 17:24:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK16h-0007Sv-7V; Fri, 08 Apr 2005 17:33:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0uY-0005NF-9w; Fri, 08 Apr 2005 17:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0uU-0005N6-JZ for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 17:21:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13367 for ; Fri, 8 Apr 2005 17:20:59 -0400 (EDT) Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK13I-0007Fu-NL for tsvwg@ietf.org; Fri, 08 Apr 2005 17:30:10 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j38LKmxZ007886; Fri, 8 Apr 2005 17:20:54 -0400 (EDT) Subject: Re: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated) To: jon.peterson@neustar.biz, mankin@psg.com, tsvwg@ietf.org, jmpolk@cisco.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Fri, 8 Apr 2005 17:19:25 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 04/08/2005 05:21:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 As an "interested observer", I definitely remember an agreement to remove the direct references to Mike and Steve's document. My notes at the time say: "As expected, Mike Pierce objected vehemently to "What's wrong with MLEF" being a working group draft. Scott suggested retitling it and rewording it to address "what;'s wrong with addressing per hop behavior without addressing call admission". Everyone seemed satisfied with that." Janet ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "James M. Polk" cc: jon.peterson@neustar.biz, mankin@psg.com Sent by: Subject: Re: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated) tsvwg-bounces 04/08/2005 04:47 PM Chairs I'm not sure I agree with the minutes regarding the (heated) MLEF Concerns discussion. I believe I agreed with Scott when he said this is a worthy document to move forward *IF* it were broadened to a larger problem area than just the US Gov's desire for MLEF for MLPP networks. I believe what was agreed was that I (with Fred) would rewrite the Intro and conclusion sections of the ID to make its applicability wider, but that the core of the ID was on the right track. Obviously there will need to be a review of the core of the ID if the rewritten sections change what should be in the core of the doc. comments BTW - you hid the Paris comment well, as I haven't found it yet At 11:48 AM 4/8/2005 -0700, Allison Mankin wrote: >Transport Area WG (tsvwg) > >Monday, March 7 at 1530-1730 >============================= > >CHAIRS: Allison Mankin > Jon Peterson > > >MLPP Update (Fred Baker/James Polk) (15 mins) > >Four drafts. > >First, the MLEF concerns draft has been posted as a WG document >pursuant to discussion last time. This changed the draft handle only. > >Second, our MLPP proposal which is RSVP based. We did a minor update >and submitted as a WG draft. There were errors in the appendix with >respect to SIP call flows; they have been fixed. Other than that >it's the same. > >Third, at last meeting, James talked about RSVP bandwidth reduction thing. >This identified a bug in RFC 3181 when it comes to dealing with aggregate >reservations. If I need to preempt call within reservation, it has me >tear down and set up with new number. This has a giant hole... >this draft suggests that one simply reduce bandwidth. "accept if doesn't >exceed X", and the endpoint changes codec or whatever is the right thing. >This draft considers backwards compatibility. > >Fourth, the last draft, is a use case for bw reduction thing. >A VPN network with multiple levels of VPNing. This is still >an individual submission. The draft posits that VPN router >might be two boxes. Talk about what crosses the private interface >between them. > > >The other 3 pretty sure about. This one needs work; dinner tomorrow >night is a discussion of this draft with others that are interested. > >we want: > >We want the first three to move forward. >mlef-concerns -> informational >mlpp that works: informational or BCP >bw-reduction -> proposed. it's a protocol. > >As to the last one... If the way we get people to read & comment >is to go to last call, I would like to go to last call. We >want people to read & comment. So LC to informational? > >Mike Pierce: object vehemently to MLEF concerns going anywhere. >The MLEF concerns document is to object to and provide comments on draft >that myself and Steve Silverman wrote on MLEF. We have seen it.. >and responded to it two years ago. We have made changes. >To show you how bad it is... look in the draft reference section. >It references the Jan. 2004 version that has concerns with. >However, the MLEF document has been revised twice, and this draft >doesn't reference updates, much less recognize modifications made to MLEF. > >The MLEF concerns actual title is >"MLEF without capacity admission does not satisfy MLPP requirements", >but we said that from the beginning. >The version from way back when that was referred to... included >explicit statement that it would not work without call admission control. >We strengthened that statement. Yet this doc keeps arguing that point. > >In addition, this document contains a large number of technical inaccuracies. >For example, g709 increasing throughput in face of loss. >It is theoretically possible for a codec to do that, but this one doesn't. >It talks about having 3 specific rates... > >Jon: don't want to take exception, but this is a more detailed discussion >than we have time for. > >But we need to have the discussion. Mike objects to the document >proceeding, and is not sure how it to WG status; his recollection is >that there was no agreement. > >Jon believe there was consensus, and the first time that Mr. Baker >spoke to us about it, there was strong consensus for this work. > >James Polk: to last point, about ILBC not being variable... >Alan Durek wrote part of that. He is the author of that protocol. >He is who helped write section. > >Mike said it's not in rfcs, though. > >Scott Bradner agreed that this particular document that was reviewed >at ieprep was a very important document in it's day. However, he's >not sure if needs to be RFC, unless it is recast as >"concerns about non-admission controlled attempts at priority". >It is an instructive document, but not sure it deals with the alternatives >on table today. Would agree that it should fade out, but strongly support >moving the others forward. > >Jon asked for Fred to comment. Fred stated that when the >document was first published, he didn't expect it to be an RFC. >He could go either way. > >James said that one of reasons why we regenerated this six months >ago or so is that we had a couple other customers, other than us government, >that wanted to promote diffserv-based QoS using that mechanism. So we wanted >to have the concerns documented. He agreed with Scott that the >scope ought to be broader. > >Fred said that he heard that if this document is to become an RFC at all, >the working group must tell him what to see. > >Jon said that he believed the working group requested that rather than >document the problems with a specific proposal, speak to general design >principles that are objectionable. > >Scott agreed. > >Jon noted that we are out of time; clearly there should be more discussion >on issues. Jon invited Mike to bring technical objections to list. Jon >then declared the meeting to be closed. > > > >------- End of Forwarded Message > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Apr 8 23:06:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05763; Fri, 8 Apr 2005 23:06:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK6S1-0005Dm-An; Fri, 08 Apr 2005 23:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK6Iq-0006Op-7e; Fri, 08 Apr 2005 23:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK6HH-00066x-4r for tsvwg@megatron.ietf.org; Fri, 08 Apr 2005 23:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05603 for ; Fri, 8 Apr 2005 23:04:53 -0400 (EDT) Message-Id: <200504090304.XAA05603@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK6Q9-00056S-4a for tsvwg@ietf.org; Fri, 08 Apr 2005 23:14:06 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DK6HE-000L2C-Q7; Sat, 09 Apr 2005 03:04:52 +0000 To: tsvwg@ietf.org Date: Fri, 08 Apr 2005 20:04:52 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Matthew Luckie Subject: [Tsvwg] re: IETF 62 Proceedings - TSVWG meeting (can be updated) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Allison Mankin wrote: > A prize to the first person who finds the message about > Paris hidden in the minutes below (by this co-chair). A number of people found there was a pretty obvious clue to the location of the hidden message, the French phrase "Rsvps for rsvp group a moi.." in the very wordy paragraph on the RSVP review group. But the actual message about Paris mentions Paris, and it is hidden in the first letter of each line of that paragraph. Matthew Luckie wins a glass of wine in Paris (or next IETF he makes it to) for finding it. See the message. Allison P.S. Think about joining the RSVP review group. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Apr 14 09:43:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12056; Thu, 14 Apr 2005 09:43:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4mo-0007tk-HE; Thu, 14 Apr 2005 09:53:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4az-00025D-UE; Thu, 14 Apr 2005 09:41:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4ay-00023W-Hn for tsvwg@megatron.ietf.org; Thu, 14 Apr 2005 09:41:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11765 for ; Thu, 14 Apr 2005 09:41:06 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM4kh-0007mT-8N for tsvwg@ietf.org; Thu, 14 Apr 2005 09:51:28 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by atlrel7.hp.com (Postfix) with ESMTP id 127F71B8A3 for ; Thu, 14 Apr 2005 09:41:04 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id B2C602336; Thu, 14 Apr 2005 09:41:03 -0400 (EDT) Received: from galen.zko.hp.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j3EDf3d0001319747; Thu, 14 Apr 2005 09:41:03 -0400 (EDT) From: Vlad Yasevich To: tsvwg@ietf.org Content-Type: text/plain Organization: Linux and Open Source Lab Date: Thu, 14 Apr 2005 09:41:03 -0400 Message-Id: <1113486063.20830.105.camel@galen.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP API Q: sctp_sendmsg and association id X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hello all I was curious why was sctp_sendmsg() defined such that a user can't use sctp association id instead of the destination address and port? The current definition of sctp_sendmsg() as defined is sctpsocket draft does not take association id as an argument, while sctp_recvmsg() can return it as part of sctp_sndrcvinfo() structure. I found that when writing cross-platform applications, it is easier to use the library functions instead of system calls as it makes portability simpler. However, I found that this useful feature was missing. Additionally, sometimes it is much easier to track and use association ids what sending and receiving messages instead of the address/port pairs. Also, on some implementaions, using association ID improves performance when using a lot (1000+) associations on a single endpoint. -vlad _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Apr 26 08:23:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03066 for ; Tue, 26 Apr 2005 08:23:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQPIX-0002eJ-K2 for tsvwg-archive@ietf.org; Tue, 26 Apr 2005 08:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQP4D-0007Ln-FV; Tue, 26 Apr 2005 08:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhpO-0005fQ-1m for tsvwg@megatron.ietf.org; Thu, 21 Apr 2005 15:59:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05674 for ; Thu, 21 Apr 2005 15:59:03 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOi0k-0001zg-J2 for tsvwg@ietf.org; Thu, 21 Apr 2005 16:10:57 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j3LJwoh0004462; Thu, 21 Apr 2005 15:58:50 -0400 (EDT) (envelope-from randall@lakerest.net) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <42680764.5080708@lakerest.net> Date: Thu, 21 Apr 2005 16:04:52 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vlad Yasevich Subject: Re: [Tsvwg] SCTP API Q: sctp_sendmsg and association id References: <1113486063.20830.105.camel@galen.zko.hp.com> In-Reply-To: <1113486063.20830.105.camel@galen.zko.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Apr 2005 08:21:27 -0400 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Vlad Yasevich wrote: > Hello all > > I was curious why was sctp_sendmsg() defined such that a user can't use > sctp association id instead of the destination address and port? > > The current definition of sctp_sendmsg() as defined is sctpsocket draft > does not take association id as an argument, while sctp_recvmsg() can > return it as part of sctp_sndrcvinfo() structure. > > I found that when writing cross-platform applications, it is easier to > use the library functions instead of system calls as it makes > portability simpler. However, I found that this useful feature was > missing. > > Additionally, sometimes it is much easier to track and use association > ids what sending and receiving messages instead of the address/port > pairs. Also, on some implementaions, using association ID improves > performance when using a lot (1000+) associations on a single endpoint. Yep... thats because most impl hash the assoc id.. and it is also why sctp_send was defined.. it takes a sndrcv_info .. R > > -vlad > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Apr 27 07:58:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28810 for ; Wed, 27 Apr 2005 07:58:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQlNh-0000re-1F for tsvwg-archive@ietf.org; Wed, 27 Apr 2005 08:11:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQl81-0006bH-Mt; Wed, 27 Apr 2005 07:54:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQl7z-0006bC-OF for tsvwg@megatron.ietf.org; Wed, 27 Apr 2005 07:54:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28661 for ; Wed, 27 Apr 2005 07:54:50 -0400 (EDT) Received: from web26203.mail.ukl.yahoo.com ([217.12.10.240]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQlKa-0000oh-Kx for tsvwg@ietf.org; Wed, 27 Apr 2005 08:07:56 -0400 Received: (qmail 40898 invoked by uid 60001); 27 Apr 2005 11:54:37 -0000 Message-ID: <20050427115437.40896.qmail@web26203.mail.ukl.yahoo.com> Received: from [194.237.142.10] by web26203.mail.ukl.yahoo.com via HTTP; Wed, 27 Apr 2005 13:54:37 CEST Date: Wed, 27 Apr 2005 13:54:37 +0200 (CEST) From: Salvatore Loreto To: randall@lakerest.net, tsvwg@ietf.org, giuseppe demarco In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA28661 Subject: [Tsvwg] SCTP Dynamic Address Reconfiguration X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Hi all, I know the rationale of Dynamic Address Reconfiguration is not the mobility, but it seems to become a valid solution for mobility. in your opinion is it possible carrying a SACK information in the same SCTP packet carrying an ASCONF chunk ? This could be useful in "congestion control" of a mobile with single nic. I think the scenario with a Mobile with a single nic (no multihomed) will not an unusual Mobile configuration so this case must be study in deep. So from a performance point of view I don't agree with par. 4.3.2 and 4.4 of draft-ietf-tsvwg-addip-sctp-11.txt br /Sal =09 ___________________________________=20 Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: Audibles, Avatar, Webc= am, Giochi, Rubrica=85 Scaricalo ora!=20 http://it.messenger.yahoo.it _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Apr 27 14:19:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08657 for ; Wed, 27 Apr 2005 14:19:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQrLE-0002WM-DR for tsvwg-archive@ietf.org; Wed, 27 Apr 2005 14:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQr5i-00022w-Fl; Wed, 27 Apr 2005 14:16:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQr5g-00022q-Hk for tsvwg@megatron.ietf.org; Wed, 27 Apr 2005 14:16:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08386 for ; Wed, 27 Apr 2005 14:16:49 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQrIJ-0002SN-Qn for tsvwg@ietf.org; Wed, 27 Apr 2005 14:29:58 -0400 Received: from [192.168.1.100] (p508F423C.dip.t-dialin.net [80.143.66.60]) by ilsa.franken.de (Postfix) with ESMTP id 824A4245D2; Wed, 27 Apr 2005 20:16:31 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <20050427115437.40896.qmail@web26203.mail.ukl.yahoo.com> References: <20050427115437.40896.qmail@web26203.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Subject: Re: [Tsvwg] SCTP Dynamic Address Reconfiguration Date: Wed, 27 Apr 2005 20:16:24 +0200 To: salvatore.loreto@ieee.org X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, randall@lakerest.net, giuseppe demarco X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Hi Salvatore, see my comments in-line. Best regards Michael On Apr 27, 2005, at 13:54 Uhr, Salvatore Loreto wrote: > Hi all, > > I know the rationale of Dynamic Address > Reconfiguration is not the mobility, but it seems to > become a valid solution for mobility. > > in your opinion is it possible carrying a SACK > information in the same SCTP packet carrying an ASCONF > chunk ? Why not? You can bundle them. > This could be useful in "congestion control" of a > mobile with single nic. > > I think the scenario with a Mobile with a single nic > (no multihomed) will not an unusual Mobile > configuration so this case must be study in deep. > > So from a performance point of view I don't agree with > par. 4.3.2 and 4.4 of > draft-ietf-tsvwg-addip-sctp-11.txt I do not see what these paragraphs have to do with performance. Could you be a bit more precise? > > > br > /Sal > > > =09 > ___________________________________ > Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: Audibles, Avatar,=20= > Webcam, Giochi, Rubrica=85 Scaricalo ora! > http://it.messenger.yahoo.it > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Apr 27 16:42:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04587 for ; Wed, 27 Apr 2005 16:42:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQtZI-0001QC-Ec for tsvwg-archive@ietf.org; Wed, 27 Apr 2005 16:55:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQtMN-0001lW-Rv; Wed, 27 Apr 2005 16:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQtMK-0001lH-6Y for tsvwg@megatron.ietf.org; Wed, 27 Apr 2005 16:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04534 for ; Wed, 27 Apr 2005 16:42:09 -0400 (EDT) Received: from web26201.mail.ukl.yahoo.com ([217.12.10.238]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQtZ1-0001PT-7j for tsvwg@ietf.org; Wed, 27 Apr 2005 16:55:20 -0400 Received: (qmail 60697 invoked by uid 60001); 27 Apr 2005 20:41:59 -0000 Message-ID: <20050427204159.60695.qmail@web26201.mail.ukl.yahoo.com> Received: from [82.53.90.125] by web26201.mail.ukl.yahoo.com via HTTP; Wed, 27 Apr 2005 22:41:59 CEST Date: Wed, 27 Apr 2005 22:41:59 +0200 (CEST) From: Salvatore Loreto Subject: Re: [Tsvwg] SCTP Dynamic Address Reconfiguration To: Michael Tuexen In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 2.9 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA04534 Cc: tsvwg@ietf.org, randall@lakerest.net, giuseppe demarco X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable about the performance par. 4.3.2 "the receiver of such a chunk MUST always firs use the source address found in the IP headere in looking up the association. ... only if the lookup fails using the source address from the IP header..." in this way the receiver spend an RTO trying to send to an IP address not any more valid. The sender can't send any data to this new address before the reception of ASCONF-ACK, see D2) in page 23, (so I was supposing it doesn't carrying SACK information in the same SCTP packet of ASCONF chunk, but you say it is possilbe, so I was wrong) so the time the association can restant exchanges data is RTO+RTT/2? par. 4.4 "A sender should only send a set primary request to an address that is already considered part of the association"...=20 is it enough insert the set primary just after the ASCONF chunk ? In some way must be possible indicate the sender can have just one IP address in an association... Maybe it can be done in INIT chunk... what do you think about? /sal --- Michael Tuexen wrote: > Hi Salvatore, > see my comments in-line. > Best regards > Michael >=20 > On Apr 27, 2005, at 13:54 Uhr, Salvatore Loreto > wrote: >=20 > > Hi all, > > > > I know the rationale of Dynamic Address > > Reconfiguration is not the mobility, but it seems > to > > become a valid solution for mobility. > > > > in your opinion is it possible carrying a SACK > > information in the same SCTP packet carrying an > ASCONF > > chunk ? > Why not? You can bundle them. > > This could be useful in "congestion control" of a > > mobile with single nic. > > > > I think the scenario with a Mobile with a single > nic > > (no multihomed) will not an unusual Mobile > > configuration so this case must be study in deep. > > > > So from a performance point of view I don't agree > with > > par. 4.3.2 and 4.4 of > > draft-ietf-tsvwg-addip-sctp-11.txt > I do not see what these paragraphs have to do with > performance. > Could you be a bit more precise? > > > > > > br > > /Sal > > > > > > =09 > > ___________________________________ > > Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: > Audibles, Avatar,=20 > > Webcam, Giochi, Rubrica=85 Scaricalo ora! > > http://it.messenger.yahoo.it > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 =09 ___________________________________=20 Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: Audibles, Avatar, Webc= am, Giochi, Rubrica=85 Scaricalo ora!=20 http://it.messenger.yahoo.it _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Apr 28 02:46:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12983 for ; Thu, 28 Apr 2005 02:46:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR2zp-0002v2-HK for tsvwg-archive@ietf.org; Thu, 28 Apr 2005 02:59:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR2kj-0003eQ-1P; Thu, 28 Apr 2005 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR2kg-0003eL-Vg for tsvwg@megatron.ietf.org; Thu, 28 Apr 2005 02:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12662 for ; Thu, 28 Apr 2005 02:43:57 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR2xU-0002mK-2B for tsvwg@ietf.org; Thu, 28 Apr 2005 02:57:13 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j3S6hgCR022791 for ; Thu, 28 Apr 2005 01:43:43 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id MAA29752; Thu, 28 Apr 2005 12:03:37 -0500 (GMT) Message-ID: <42708751.5050506@axesb2.usa.alcatel.com> Date: Thu, 28 Apr 2005 12:18:49 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: [Tsvwg] SCTP - Processing of INIT in Established state References: <1113486063.20830.105.camel@galen.zko.hp.com> <42680764.5080708@lakerest.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit As per section 5.2.2, when INIT is received in ESTABLISHED state, INIT ACK should be sent with the new InitTag and Verification Tag set to the InitTag received in INIT. At that time, is it not required to send notification to upper layer about this? When the new association gets established and it notifies the upper layer after the SCTP Comm Up, does the upper layer has to update its association ID with the new one and initiate the close of the old association? When there is no action taken by upper layer after getting SCTP Comm Up in SCTP already established state, later whenever it tries to send message, SCTP returns failure. Please any one of you guide us in this case. thanks, Bhanu Randall Stewart wrote: > Vlad Yasevich wrote: > >> Hello all >> >> I was curious why was sctp_sendmsg() defined such that a user can't use >> sctp association id instead of the destination address and port? >> >> The current definition of sctp_sendmsg() as defined is sctpsocket draft >> does not take association id as an argument, while sctp_recvmsg() can >> return it as part of sctp_sndrcvinfo() structure. >> >> I found that when writing cross-platform applications, it is easier to >> use the library functions instead of system calls as it makes >> portability simpler. However, I found that this useful feature was >> missing. >> >> Additionally, sometimes it is much easier to track and use association >> ids what sending and receiving messages instead of the address/port >> pairs. Also, on some implementaions, using association ID improves >> performance when using a lot (1000+) associations on a single endpoint. > > > Yep... thats because most impl hash the assoc id.. > > and it is also why sctp_send was defined.. it takes a > sndrcv_info .. > > R > >> >> -vlad >> >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Apr 28 17:52:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28260 for ; Thu, 28 Apr 2005 17:52:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRH8k-0006xa-WB for tsvwg-archive@ietf.org; Thu, 28 Apr 2005 18:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRGuF-0003x9-Ki; Thu, 28 Apr 2005 17:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRGuD-0003x4-Rk for tsvwg@megatron.ietf.org; Thu, 28 Apr 2005 17:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28017 for ; Thu, 28 Apr 2005 17:50:43 -0400 (EDT) Received: from web26207.mail.ukl.yahoo.com ([217.12.10.244]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DRH79-0006uV-LG for tsvwg@ietf.org; Thu, 28 Apr 2005 18:04:08 -0400 Received: (qmail 46829 invoked by uid 60001); 28 Apr 2005 21:50:31 -0000 Message-ID: <20050428215031.46827.qmail@web26207.mail.ukl.yahoo.com> Received: from [82.49.78.148] by web26207.mail.ukl.yahoo.com via HTTP; Thu, 28 Apr 2005 23:50:31 CEST Date: Thu, 28 Apr 2005 23:50:31 +0200 (CEST) From: Salvatore Loreto To: tsvwg@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Tsvwg] Handoff for a mobile with a single NIC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618207159==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============0618207159== Content-Type: multipart/alternative; boundary="0-909728887-1114725031=:45599" --0-909728887-1114725031=:45599 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA28017 Content-Transfer-Encoding: quoted-printable hi all, I'm thinking about this and I can see various scenario: 1) during the association INIT, the MN says in same way (one bit in Chunk= Flag) it can use only one IP Address at the time.=20 So during the handoff the CN already know it and MUST use directly the ne= w IP addres just after the ADDCONF chunk 2) the MN says in same way (one bit in Chunk Flag) when sending the ADDCO= NF chunk, the new IP it wants adds to the association it is the only vali= d for the assocaiton The main problema is: is it right reduce the CWND value to 2 for the new path? If the old and the newa attachment points of MN to the Internet are close= to each other, mostly only the last hop (the wireless hop) to the MN wil= l change. thank you in advance Sal =09 --------------------------------- Nuovo Yahoo! Messenger E' molto pi=F9 divertente: Audibles, Avatar, Webca= m, Giochi, Rubrica=85 Scaricalo ora!=20 --0-909728887-1114725031=:45599 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA28017 Content-Transfer-Encoding: quoted-printable

hi all,

I'm thinking about this and I can see various scenario:

1) during the association INIT, the MN says in same way (one bit in Ch= unk Flag) it can use only one IP Address at the time.
So during the h= andoff the CN already know it and MUST use directly the new IP = addres just after the ADDCONF chunk

2) the MN says in same way (one bit in Chunk Flag) when sending the AD= DCONF chunk, the new IP it wants adds to the association it is the only v= alid for the assocaiton

The main problema is:

is it right reduce the CWND value to 2 for the new path?
If the old= and the newa attachment points of MN to the Internet are close to each o= ther, mostly only the last hop (the wireless hop) to the MN will change.<= BR>

thank you in advance

Sal

=09 =09

Nuovo Yahoo! = Messenger E' molto pi=F9 divertente: Audibles, Avatar, Webcam, Gi= ochi, Rubrica=85 Scaricalo ora!=20 --0-909728887-1114725031=:45599-- --===============0618207159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0618207159==-- From tsvwg-bounces@ietf.org Thu Apr 28 21:32:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16492 for ; Thu, 28 Apr 2005 21:32:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRKa3-00080t-57 for tsvwg-archive@ietf.org; Thu, 28 Apr 2005 21:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRKKg-0008FZ-OL; Thu, 28 Apr 2005 21:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRKKf-0008Cz-4P for tsvwg@megatron.ietf.org; Thu, 28 Apr 2005 21:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16369 for ; Thu, 28 Apr 2005 21:30:15 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRKXc-0007tt-4B for tsvwg@ietf.org; Thu, 28 Apr 2005 21:43:41 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3T1UBId091560 for ; Thu, 28 Apr 2005 18:30:11 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 312BC77A70A for ; Thu, 28 Apr 2005 21:30:09 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8C9A62647E1 for ; Thu, 28 Apr 2005 21:30:08 -0400 (EDT) To: tsvwg@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Jack and Diane MIME-Version: 1.0 Date: Thu, 28 Apr 2005 21:30:08 -0400 Message-Id: <20050429013008.8C9A62647E1@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [Tsvwg] Mark Allman: [tcpm] WGLC for TCP roadmap X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0049298273==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e --===============0049298273== Content-Type: multipart/signed; boundary="===_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --===_bOundary Content-Type: multipart/mixed; boundary="==_bOundary" --==_bOundary Content-Type: text/plain Folks- Per the attached note, TCPM is now having a WGLC on the TCP roadmap and since this group has been interested in such issues we thought we'd let everyone know. Comments and discussion to the TCPM list (tcpm@ietf.org), please. Thanks! allman --==_bOundary Content-Type: message/rfc822 Content-Disposition: attachment; filename=4023 Content-Description: forwarded message Return-Path: tcpm-bounces@ietf.org Delivery-Date: Wed Apr 27 12:25:55 2005 Return-Path: X-Original-To: mallman@guns.icir.org Delivered-To: mallman@guns.icir.org Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by guns.icir.org (Postfix) with ESMTP id B39E677A6E3 for ; Wed, 27 Apr 2005 12:25:54 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3RGPrib066358; Wed, 27 Apr 2005 09:25:53 -0700 (PDT) (envelope-from tcpm-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQpKj-0007CN-VC; Wed, 27 Apr 2005 12:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQpKi-0007Av-6R for tcpm@megatron.ietf.org; Wed, 27 Apr 2005 12:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29940 for ; Wed, 27 Apr 2005 12:24:13 -0400 (EDT) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQpXL-0000GN-Oz for tcpm@ietf.org; Wed, 27 Apr 2005 12:37:23 -0400 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.11/8.12.8) with ESMTP id j3RGOAVt066322 for ; Wed, 27 Apr 2005 09:24:10 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 5904377A6E3 for ; Wed, 27 Apr 2005 12:24:09 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lady Picture Show MIME-Version: 1.0 Date: Wed, 27 Apr 2005 12:24:09 -0400 Message-Id: <20050427162409.5904377A6E3@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [tcpm] WGLC for TCP roadmap X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1505452195==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org X-ClamAV: OK X-SpamProbe: GOOD 0.0000000 ab0f7ba95094c144741ac551989c61d3 X-mallman-sequence: icir tcpm --===============1505452195== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Folks- Ted and I would like to start a WG last call on the TCP roadmap document: Title : A Roadmap for TCP Specification Documents Author(s) : M. Duke, et al. Filename : draft-ietf-tcpm-tcp-roadmap-03.txt Pages : 36 Date : 2005-4-26 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-03.txt which is slated for informational. Our understanding is that all feedback to date is reflected in this version and that there are no known outstanding issues. But, it'd be great if folks can verify that and in general give this one more look. Please send feedback (even if just of the form "yep, looks good"). Let's do the standard two week WGLC - so comments will be due by May 12th. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCb7ypWyrrWs4yIs4RApLZAKCOES4x+jAItk0l7Iu16dWla62+YQCgnALO F+3glvtV4aLe5ox3VbGAV3U= =4OVe -----END PGP SIGNATURE----- --=_bOundary-- --===============1505452195== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1505452195==-- --==_bOundary-- --===_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFCcY4gWyrrWs4yIs4RApxmAKCPHpgD3FhEGCrfq4eza6PYbmrJ6wCfQA0c Vi7N7H8m+iBnBmFJHQM/aT0= =JtF2 -----END PGP SIGNATURE----- --===_bOundary-- --===============0049298273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0049298273==-- From mailman-bounces@ietf.org Mon May 2 06:01:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21953 for ; Mon, 2 May 2005 06:01:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSXy4-0006Sl-VM for tsvwg-archive@ietf.org; Mon, 02 May 2005 06:16:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSXL4-0006NY-5U for tsvwg-archive@ietf.org; Mon, 02 May 2005 05:35:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 May 2005 05:25:04 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From tsvwg-bounces@ietf.org Tue May 3 05:51:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25262 for ; Tue, 3 May 2005 05:51:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuHQ-0003na-TT for tsvwg-archive@ietf.org; Tue, 03 May 2005 06:05:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStz9-0005SK-Jd; Tue, 03 May 2005 05:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DStz7-0005SC-E5 for tsvwg@megatron.ietf.org; Tue, 03 May 2005 05:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24835 for ; Tue, 3 May 2005 05:46:30 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuCx-0003fd-Gx for tsvwg@ietf.org; Tue, 03 May 2005 06:00:53 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j439kLoO020025; Tue, 3 May 2005 05:46:22 -0400 (EDT) (envelope-from randall@lakerest.net) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <427749CC.6050606@lakerest.net> Date: Tue, 03 May 2005 05:52:12 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bhanu Subject: Re: [Tsvwg] SCTP - Processing of INIT in Established state References: <1113486063.20830.105.camel@galen.zko.hp.com> <42680764.5080708@lakerest.net> <42708751.5050506@axesb2.usa.alcatel.com> In-Reply-To: <42708751.5050506@axesb2.usa.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit bhanu wrote: > As per section 5.2.2, when INIT is received in ESTABLISHED state, INIT > ACK should be sent with the new InitTag and Verification Tag set to the > InitTag received in INIT. At that time, is it not required to send > notification to upper layer about this? When the new association gets > established and it notifies the upper layer after the SCTP Comm Up, does > the upper layer has to update its association ID with the new one and > initiate the close of the old association? Hmm.. this is an interesting point.. and its NOT a comm-up in this case.. but instead a restart notification... and this may be a missing piece in the restart-notification. Since the tag will change the assoc-id will too.. the APP right now would have to keep track of IP addresses and ports in addition to the assoc-id's.. and then when a "restart" comes up figure this out.. It would not be that hard to add a old_asocid/new_asocid field to the restart-notification... that way implementations that DO NOT change the assoc-id can just set them to the same.. but those that do will save the app a lot of trouble.. R > When there is no action taken by upper layer after getting SCTP Comm Up > in SCTP already established state, later whenever it tries to send > message, SCTP returns failure. Please any one of you guide us in this case. > > thanks, > Bhanu > > Randall Stewart wrote: > >> Vlad Yasevich wrote: >> >>> Hello all >>> >>> I was curious why was sctp_sendmsg() defined such that a user can't use >>> sctp association id instead of the destination address and port? >>> >>> The current definition of sctp_sendmsg() as defined is sctpsocket draft >>> does not take association id as an argument, while sctp_recvmsg() can >>> return it as part of sctp_sndrcvinfo() structure. >>> >>> I found that when writing cross-platform applications, it is easier to >>> use the library functions instead of system calls as it makes >>> portability simpler. However, I found that this useful feature was >>> missing. >>> >>> Additionally, sometimes it is much easier to track and use association >>> ids what sending and receiving messages instead of the address/port >>> pairs. Also, on some implementaions, using association ID improves >>> performance when using a lot (1000+) associations on a single endpoint. >> >> >> >> Yep... thats because most impl hash the assoc id.. >> >> and it is also why sctp_send was defined.. it takes a >> sndrcv_info .. >> >> R >> >>> >>> -vlad >>> >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >> > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 3 05:59:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25818 for ; Tue, 3 May 2005 05:59:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuPk-00040G-8C for tsvwg-archive@ietf.org; Tue, 03 May 2005 06:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSu8f-00005r-IT; Tue, 03 May 2005 05:56:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSu8d-0008VE-Mw for tsvwg@megatron.ietf.org; Tue, 03 May 2005 05:56:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25693 for ; Tue, 3 May 2005 05:56:21 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuMV-0003wT-4u for tsvwg@ietf.org; Tue, 03 May 2005 06:10:43 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j439u5oO020114; Tue, 3 May 2005 05:56:05 -0400 (EDT) (envelope-from randall@lakerest.net) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <42774C14.1020107@lakerest.net> Date: Tue, 03 May 2005 06:01:56 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP Dynamic Address Reconfiguration References: <20050427115437.40896.qmail@web26203.mail.ukl.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id j439u5oO020114 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: salvatore.loreto@ieee.org, tsvwg@ietf.org, giuseppe demarco X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Michael Tuexen wrote: > Hi Salvatore, > see my comments in-line. > Best regards > Michael >=20 > On Apr 27, 2005, at 13:54 Uhr, Salvatore Loreto wrote: >=20 >> Hi all, >> >> I know the rationale of Dynamic Address >> Reconfiguration is not the mobility, but it seems to >> become a valid solution for mobility. >> >> in your opinion is it possible carrying a SACK >> information in the same SCTP packet carrying an ASCONF >> chunk ? >=20 > Why not? You can bundle them. I agree here.. if you want to include a SACK you bundle it with the ACONF... no problem... you can also bundle DATA if you so desire... >=20 >> This could be useful in "congestion control" of a >> mobile with single nic. >> >> I think the scenario with a Mobile with a single nic >> (no multihomed) will not an unusual Mobile >> configuration so this case must be study in deep. >> >> So from a performance point of view I don't agree with >> par. 4.3.2 and 4.4 of >> draft-ietf-tsvwg-addip-sctp-11.txt >=20 > I do not see what these paragraphs have to do with performance. > Could you be a bit more precise? >=20 And all 4.4 does is make it so you must ORDER the add-address BEFORE the set-primary.. it does not mean you can't use it. if you are also thinking of performance based on lookup of the association... realize that most implementations use the V-tag as a hash.. so I doubt very much they will even worry about using the source address.. other than to verify that the lookup-address is in the association being reconfigured.. and with the new requirment to auth the packet.. the auth would fail unless you know the secrets.. so I don't see an issue. R >> >> >> br >> /Sal >> >> >> =20 >> ___________________________________ >> Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: Audibles, Avatar,=20 >> Webcam, Giochi, Rubrica=85 Scaricalo ora! >> http://it.messenger.yahoo.it >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 >=20 >=20 --=20 Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 3 06:39:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28746 for ; Tue, 3 May 2005 06:39:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSv1s-0004qT-9D for tsvwg-archive@ietf.org; Tue, 03 May 2005 06:53:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSujw-0003ft-Ic; Tue, 03 May 2005 06:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSuju-0003fo-S4 for tsvwg@megatron.ietf.org; Tue, 03 May 2005 06:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28245 for ; Tue, 3 May 2005 06:34:52 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuxl-0004i3-JM for tsvwg@ietf.org; Tue, 03 May 2005 06:49:14 -0400 Received: from sunmail2.sfbay.sun.com ([129.149.246.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j43AYFi7002112; Tue, 3 May 2005 04:34:15 -0600 (MDT) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j43AYDG20300; Tue, 3 May 2005 03:34:13 -0700 (PDT) Message-ID: <427753A2.4010306@sun.com> Date: Tue, 03 May 2005 18:34:10 +0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7.6) Gecko/20050323 X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw MIME-Version: 1.0 To: Randall Stewart Subject: Re: [Tsvwg] SCTP - Processing of INIT in Established state References: <1113486063.20830.105.camel@galen.zko.hp.com> <42680764.5080708@lakerest.net> <42708751.5050506@axesb2.usa.alcatel.com> <427749CC.6050606@lakerest.net> In-Reply-To: <427749CC.6050606@lakerest.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: SCTP Implementors , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit This thread should probably be discussed in the sctp-impl list (cc'ed) instead. Randall Stewart wrote: > Hmm.. this is an interesting point.. and its NOT a comm-up in this > case.. but instead a restart notification... and this > may be a missing piece in the restart-notification. Since the > tag will change the assoc-id will too.. the APP right now would > have to keep track of IP addresses and ports in addition > to the assoc-id's.. and then when a "restart" comes up figure > this out.. I think the preferred implementation is to use the same assoc-id for the restarted association, as this may not be a fatal event to the app. Then the app just needs to know that somehow the association is restarted. If this is not OK with the app, it can terminate the association. If it is OK, it can continue to use the assoc-id. Requiring the app to use a new assoc-id is unnecessary. Maybe this behavior should be specified in the SCTP API draft. > It would not be that hard to add a old_asocid/new_asocid field > to the restart-notification... that way implementations that > DO NOT change the assoc-id can just set them to the same.. but > those that do will save the app a lot of trouble.. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu May 5 00:10:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21046 for ; Thu, 5 May 2005 00:10:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTXvB-00018e-CU for tsvwg-archive@ietf.org; Thu, 05 May 2005 00:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTXdr-0005Ew-PU; Thu, 05 May 2005 00:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTXdq-0005Er-GB for tsvwg@megatron.ietf.org; Thu, 05 May 2005 00:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20674 for ; Thu, 5 May 2005 00:07:11 -0400 (EDT) Received: from dontaku.fit.ac.jp ([150.43.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTXs3-0000vl-VT for tsvwg@ietf.org; Thu, 05 May 2005 00:21:56 -0400 Received: from dontaku.fit.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.fit.ac.jp (Postfix) with ESMTP id 4421414C01C; Thu, 5 May 2005 13:06:52 +0900 (JST) Received: from [150.43.233.162] (nausica.ce.fit.ac.jp [150.43.233.162]) by dontaku.fit.ac.jp (Postfix) with ESMTP id 2E05414C018; Thu, 5 May 2005 13:06:52 +0900 (JST) Message-ID: <42799B75.9040001@unisa.it> Date: Thu, 05 May 2005 13:05:09 +0900 From: giuseppe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart , tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP Dynamic Address Reconfiguration References: <20050427115437.40896.qmail@web26203.mail.ukl.yahoo.com> <42774C14.1020107@lakerest.net> In-Reply-To: <42774C14.1020107@lakerest.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Randall Stewart wrote: > Michael Tuexen wrote: > >> Hi Salvatore, >> see my comments in-line. >> Best regards >> Michael >> >> On Apr 27, 2005, at 13:54 Uhr, Salvatore Loreto wrote: >> >>> Hi all, >>> >>> I know the rationale of Dynamic Address >>> Reconfiguration is not the mobility, but it seems to >>> become a valid solution for mobility. >>> >>> in your opinion is it possible carrying a SACK >>> information in the same SCTP packet carrying an ASCONF >>> chunk ? >> >> >> Why not? You can bundle them. > > > I agree here.. if you want to include a SACK you bundle > it with the ACONF... no problem... you can also > bundle DATA if you so desire... > >> >>> This could be useful in "congestion control" of a >>> mobile with single nic. >>> >>> I think the scenario with a Mobile with a single nic >>> (no multihomed) will not an unusual Mobile >>> configuration so this case must be study in deep. >>> >>> So from a performance point of view I don't agree with >>> par. 4.3.2 and 4.4 of >>> draft-ietf-tsvwg-addip-sctp-11.txt >> >> >> I do not see what these paragraphs have to do with performance. >> Could you be a bit more precise? >> > > And all 4.4 does is make it so you must ORDER the add-address > BEFORE the set-primary.. it does not mean you can't use it. > > if you are also thinking of performance based on lookup of > the association... realize that most implementations use the > V-tag as a hash.. so I doubt very much they will even worry > about using the source address.. other than to verify that > the lookup-address is in the association being reconfigured.. and > with the new requirment to auth the packet.. the auth would > fail unless you know the secrets.. so I don't see an issue. > > R > >>> >>> >>> br >>> /Sal >>> >>> >>> ___________________________________ >>> Nuovo Yahoo! Messenger: E' molto pi=F9 divertente: Audibles, Avatar,=20 >>> Webcam, Giochi, Rubrica=85 Scaricalo ora! >>> http://it.messenger.yahoo.it >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >> >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> >> > > An other issue on this topic could be the need of multipath in mobile=20 scenario. For double-nic equipped terminal, maybe it'll be useful, to increase=20 reliability and throughput. Moreover, multipath could be useful for fast movements and returning of mobile node into the previous=20 network. But, maybe this will add some buffering stuff at the AP... G --=20 ---------------------- ---------------------- Giuseppe De Marco, Ph.D. Dipartimento di Ingegneria=20 dell'Informazione e Ingegneria Elettrica DIIIE, University of Salerno via ponte don Melillo 1, Fisciano, Salerno tel: +39 089 964012 email: gdemarco@unisa.it Department of Information and=20 Communication Engineering=20 Faculty of Information Engineering=20 Fukuoka Institute of Technology (FIT) 3-30-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-0295=20 Japan email: demarco@fit.ac.jp -------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 10 14:48:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01709 for ; Tue, 10 May 2005 14:48:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVa21-0006Gi-R8 for tsvwg-archive@ietf.org; Tue, 10 May 2005 15:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZj5-00034q-9h; Tue, 10 May 2005 14:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVZj3-000348-Lx for tsvwg@megatron.ietf.org; Tue, 10 May 2005 14:45:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01475 for ; Tue, 10 May 2005 14:44:59 -0400 (EDT) Received: from mxfep01.bredband.com ([195.54.107.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVZyK-0005uH-8x for tsvwg@ietf.org; Tue, 10 May 2005 15:00:54 -0400 Received: from s-213-115-124-91.sme.bredbandsbolaget.se ([213.115.124.91] [213.115.124.91]) by mxfep01.bredband.com with ESMTP id <20050510184431.SAQY24425.mxfep01.bredband.com@s-213-115-124-91.sme.bredbandsbolaget.se>; Tue, 10 May 2005 20:44:31 +0200 From: Anders Torger To: Randall Stewart Date: Tue, 10 May 2005 20:44:26 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505102044.26181.torger@ludd.luth.se> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit One problem with sctp_assoc_t is that there is no clear definition of what the values can be. The only thing I can find out from draft-ietf-tsvwg-sctpsocket-10.txt is that zero is not a valid value for an association, but any other value may be. It would be great if the API draft would specify some facts/rules about sctp_assoc_t and association ID. I *think* this is true, and I'd like that it was mentioned more clearly in the draft: - sctp_assoc_t is an integer of unspecified size and may be signed or unsigned - a valid association has an id != 0 (that is both positive and negative sctp_assoc_t are valid values). - a one-to-one socket has no association id - a peeled off socket will lose its association id (the file descriptor should be used for future reference), and the old id may be immediately re-used by a new one-to-many association. In lksctp, it seems like one-to-one sockets have an association id anyway, which is equal to the file descriptor value, while in Solaris 10 a random value is provided as association id in events on one-to-one sockets. I would prefer if the API draft would specify that the OS must set the association id to zero in returned events for one-to-one sockets instead of allowing it to contain a random value like in Solaris 10, or something that might be usable like in lksctp. This will make the API safer (=bugs in user code is easier detected). When mixing one-to-many and one-to-one sockets there can often be a need to provide a single space of handles for associations to upper layers within the application. Handles which work for both one-to-many sockets and one-to-one sockets, and does not change at peeloff. This is a bit of a pain, since file descriptor values can collide with association id values, and association id is lost at peeloff. But I don't think there is much one can do about it. Virtual handles unrelated to file descriptors and sctp_assoc_t combined with a lookup table is necessary for that. I had an idea that one could define rules for sctp_assoc_t such that valid one-to-many association ids would be outside the range of valid file descriptors, and give one-to-one sockets an association id equal to the file descriptor value, and that way provide a single handle space without the need for virtual handles and lookup tables in user-space. However, it breaks with peeloff, since then the association id would have to change. Therefore my suggestion is simply to clarify what the current rules are. /Anders Torger _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 11 17:39:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28779 for ; Wed, 11 May 2005 17:39:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzBF-0002Rs-Lc for tsvwg-archive@ietf.org; Wed, 11 May 2005 17:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyue-0001iE-4z; Wed, 11 May 2005 17:38:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyub-0001i6-Gp for tsvwg@megatron.ietf.org; Wed, 11 May 2005 17:38:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28716 for ; Wed, 11 May 2005 17:38:34 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzAB-0002KQ-JR for tsvwg@ietf.org; Wed, 11 May 2005 17:54:44 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4BLcLpQ005124 for ; Wed, 11 May 2005 17:38:21 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4BLcLnM133226 for ; Wed, 11 May 2005 17:38:21 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4BLcLxl030841 for ; Wed, 11 May 2005 17:38:21 -0400 Received: from [127.0.0.1] (IBM-2RI44RCU0TC.beaverton.ibm.com [9.47.18.105]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4BLcJvB030754; Wed, 11 May 2005 17:38:20 -0400 Message-ID: <42827B4B.1070009@us.ibm.com> Date: Wed, 11 May 2005 14:38:19 -0700 From: Sridhar Samudrala User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Torger Subject: Re: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t References: <200505102044.26181.torger@ludd.luth.se> In-Reply-To: <200505102044.26181.torger@ludd.luth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org, Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit I think sctp-impl is the right mailing list for SCTP implementation specific discussions. So i am adding sctp-impl to the CC list. I would like to clarify how associd is currently defined and implemented in linux SCTP(lksctp). - sctp_assoc_t is defined as signed 32 bit value. - The valid values of associd are 1-0x7fffffff. - They don't have any relationship with file descriptors. - All associations have a associd irrespective of whether they belong to 1-1 or 1-many style sockets. - The associd will not change when the association is peeled-off to a different socket. Thanks Sridhar Anders Torger wrote: >One problem with sctp_assoc_t is that there is no clear definition of >what the values can be. > >The only thing I can find out from draft-ietf-tsvwg-sctpsocket-10.txt is >that zero is not a valid value for an association, but any other value >may be. > >It would be great if the API draft would specify some facts/rules about >sctp_assoc_t and association ID. I *think* this is true, and I'd like >that it was mentioned more clearly in the draft: > > - sctp_assoc_t is an integer of unspecified size and may be signed or > unsigned > - a valid association has an id != 0 (that is both positive and > negative sctp_assoc_t are valid values). > - a one-to-one socket has no association id > - a peeled off socket will lose its association id (the file descriptor > should be used for future reference), and the old id may be > immediately re-used by a new one-to-many association. > >In lksctp, it seems like one-to-one sockets have an association id >anyway, which is equal to the file descriptor value, while in Solaris >10 a random value is provided as association id in events on one-to-one >sockets. > >I would prefer if the API draft would specify that the OS must set the >association id to zero in returned events for one-to-one sockets >instead of allowing it to contain a random value like in Solaris 10, or >something that might be usable like in lksctp. This will make the API >safer (=bugs in user code is easier detected). > >When mixing one-to-many and one-to-one sockets there can often be a need >to provide a single space of handles for associations to upper layers >within the application. Handles which work for both one-to-many sockets >and one-to-one sockets, and does not change at peeloff. This is a bit >of a pain, since file descriptor values can collide with association id >values, and association id is lost at peeloff. But I don't think there >is much one can do about it. Virtual handles unrelated to file >descriptors and sctp_assoc_t combined with a lookup table is necessary >for that. > >I had an idea that one could define rules for sctp_assoc_t such that >valid one-to-many association ids would be outside the range of valid >file descriptors, and give one-to-one sockets an association id equal >to the file descriptor value, and that way provide a single handle >space without the need for virtual handles and lookup tables in >user-space. However, it breaks with peeloff, since then the association >id would have to change. Therefore my suggestion is simply to clarify >what the current rules are. > >/Anders Torger > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 11 17:59:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00848 for ; Wed, 11 May 2005 17:59:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzUo-0003jt-GS for tsvwg-archive@ietf.org; Wed, 11 May 2005 18:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzE9-00080l-9i; Wed, 11 May 2005 17:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzE3-0007xY-GS for tsvwg@megatron.ietf.org; Wed, 11 May 2005 17:58:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00768 for ; Wed, 11 May 2005 17:58:39 -0400 (EDT) Received: from mxfep01.bredband.com ([195.54.107.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzTd-0003hh-Hp for tsvwg@ietf.org; Wed, 11 May 2005 18:14:50 -0400 Received: from static-213-115-124-91.sme.bredbandsbolaget.se ([213.115.124.91] [213.115.124.91]) by mxfep01.bredband.com with ESMTP id <20050511215828.ZIPT24425.mxfep01.bredband.com@static-213-115-124-91.sme.bredbandsbolaget.se>; Wed, 11 May 2005 23:58:28 +0200 From: Anders Torger To: Sridhar Samudrala Subject: Re: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t Date: Wed, 11 May 2005 23:58:23 +0200 User-Agent: KMail/1.7.2 References: <200505102044.26181.torger@ludd.luth.se> <42827B4B.1070009@us.ibm.com> In-Reply-To: <42827B4B.1070009@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505112358.23485.torger@ludd.luth.se> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org, Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Ok, but if I have understood the API draft correctly, it is not possible to get or access a one-to-one socket with an sctp_assoc_t, thus the association id would be hidden for the user. It seems to me however, that in lksctp, the association id is indeed visible in (for example) notifications for one-to-one sockets, although it says in the API draft that the value should be "ignored". On Solaris 10, a seemingly random value is delivered instead. I would prefer the lksctp model, or that the value is set to zero. In any case, it is not clear how it should work in the API draft. I also like the model where sctp_assoc_t is signed, and that only positive values are valid associations, in that way looking a bit like file descriptors, and making it possible to make functions that return sctp_assoc_t giving either a valid (>0), undefined (=0) or error (<0) as result. It is also nice that the association id is kept at peeloff, avoiding that the id would be re-used by another one-to-many association before the original socket has closed. Also this is not specified how it should work in the API draft. /Anders Torger On Wednesday 11 May 2005 23.38, Sridhar Samudrala wrote: > I think sctp-impl is the right mailing list for SCTP implementation > specific discussions. So i am adding sctp-impl to the CC list. > > I would like to clarify how associd is currently defined and > implemented in linux SCTP(lksctp). > - sctp_assoc_t is defined as signed 32 bit value. > - The valid values of associd are 1-0x7fffffff. > - They don't have any relationship with file descriptors. > - All associations have a associd irrespective of whether they belong > to 1-1 or 1-many style sockets. > - The associd will not change when the association is peeled-off to > a different socket. > > Thanks > Sridhar > > Anders Torger wrote: > >One problem with sctp_assoc_t is that there is no clear definition > > of what the values can be. > > > >The only thing I can find out from > > draft-ietf-tsvwg-sctpsocket-10.txt is that zero is not a valid > > value for an association, but any other value may be. > > > >It would be great if the API draft would specify some facts/rules > > about sctp_assoc_t and association ID. I *think* this is true, and > > I'd like that it was mentioned more clearly in the draft: > > > > - sctp_assoc_t is an integer of unspecified size and may be signed > > or unsigned > > - a valid association has an id != 0 (that is both positive and > > negative sctp_assoc_t are valid values). > > - a one-to-one socket has no association id > > - a peeled off socket will lose its association id (the file > > descriptor should be used for future reference), and the old id may > > be immediately re-used by a new one-to-many association. > > > >In lksctp, it seems like one-to-one sockets have an association id > >anyway, which is equal to the file descriptor value, while in > > Solaris 10 a random value is provided as association id in events > > on one-to-one sockets. > > > >I would prefer if the API draft would specify that the OS must set > > the association id to zero in returned events for one-to-one > > sockets instead of allowing it to contain a random value like in > > Solaris 10, or something that might be usable like in lksctp. This > > will make the API safer (=bugs in user code is easier detected). > > > >When mixing one-to-many and one-to-one sockets there can often be a > > need to provide a single space of handles for associations to upper > > layers within the application. Handles which work for both > > one-to-many sockets and one-to-one sockets, and does not change at > > peeloff. This is a bit of a pain, since file descriptor values can > > collide with association id values, and association id is lost at > > peeloff. But I don't think there is much one can do about it. > > Virtual handles unrelated to file descriptors and sctp_assoc_t > > combined with a lookup table is necessary for that. > > > >I had an idea that one could define rules for sctp_assoc_t such that > >valid one-to-many association ids would be outside the range of > > valid file descriptors, and give one-to-one sockets an association > > id equal to the file descriptor value, and that way provide a > > single handle space without the need for virtual handles and lookup > > tables in user-space. However, it breaks with peeloff, since then > > the association id would have to change. Therefore my suggestion is > > simply to clarify what the current rules are. > > > >/Anders Torger > > > >_______________________________________________ > >tsvwg mailing list > >tsvwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 11 18:27:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04409 for ; Wed, 11 May 2005 18:27:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzvm-0005Uz-V7 for tsvwg-archive@ietf.org; Wed, 11 May 2005 18:43:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzZo-0004wN-9W; Wed, 11 May 2005 18:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVzZj-0004w9-VT for tsvwg@megatron.ietf.org; Wed, 11 May 2005 18:21:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03488 for ; Wed, 11 May 2005 18:21:04 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVzpL-0004tg-4Y for tsvwg@ietf.org; Wed, 11 May 2005 18:37:15 -0400 Received: from [10.10.0.31] (c-24-13-174-21.hsd1.il.comcast.net[24.13.174.21]) by comcast.net (sccrmhc12) with ESMTP id <2005051122204401200r4jhqe>; Wed, 11 May 2005 22:20:55 +0000 Message-ID: <42828539.1030203@ieee.org> Date: Wed, 11 May 2005 17:20:41 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sridhar Samudrala Subject: Re: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t References: <200505102044.26181.torger@ludd.luth.se> <42827B4B.1070009@us.ibm.com> In-Reply-To: <42827B4B.1070009@us.ibm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org, Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369061426==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a This is a cryptographically signed message in MIME format. --===============1369061426== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060001020609010502070201" This is a cryptographically signed message in MIME format. --------------ms060001020609010502070201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sridhar Samudrala wrote: > I think sctp-impl is the right mailing list for SCTP implementation > specific discussions. So i am adding sctp-impl to the CC list. The following are also true for our BSD stack, except that sctp_assoc_t is an unsigned, non-zero 32-bit value. regards, --peter > I would like to clarify how associd is currently defined and implemented > in linux SCTP(lksctp). > - sctp_assoc_t is defined as signed 32 bit value. > - The valid values of associd are 1-0x7fffffff. > - They don't have any relationship with file descriptors. > - All associations have a associd irrespective of whether they belong > to 1-1 or 1-many style sockets. > - The associd will not change when the association is peeled-off to > a different socket. > > Thanks > Sridhar > > > Anders Torger wrote: > >> One problem with sctp_assoc_t is that there is no clear definition of >> what the values can be. >> >> The only thing I can find out from draft-ietf-tsvwg-sctpsocket-10.txt >> is that zero is not a valid value for an association, but any other >> value may be. >> >> It would be great if the API draft would specify some facts/rules >> about sctp_assoc_t and association ID. I *think* this is true, and I'd >> like that it was mentioned more clearly in the draft: >> >> - sctp_assoc_t is an integer of unspecified size and may be signed or >> unsigned >> - a valid association has an id != 0 (that is both positive and >> negative sctp_assoc_t are valid values). >> - a one-to-one socket has no association id >> - a peeled off socket will lose its association id (the file descriptor >> should be used for future reference), and the old id may be >> immediately re-used by a new one-to-many association. >> >> In lksctp, it seems like one-to-one sockets have an association id >> anyway, which is equal to the file descriptor value, while in Solaris >> 10 a random value is provided as association id in events on >> one-to-one sockets. >> >> I would prefer if the API draft would specify that the OS must set the >> association id to zero in returned events for one-to-one sockets >> instead of allowing it to contain a random value like in Solaris 10, >> or something that might be usable like in lksctp. This will make the >> API safer (=bugs in user code is easier detected). >> >> When mixing one-to-many and one-to-one sockets there can often be a >> need to provide a single space of handles for associations to upper >> layers within the application. Handles which work for both one-to-many >> sockets and one-to-one sockets, and does not change at peeloff. This >> is a bit of a pain, since file descriptor values can collide with >> association id values, and association id is lost at peeloff. But I >> don't think there is much one can do about it. Virtual handles >> unrelated to file descriptors and sctp_assoc_t combined with a lookup >> table is necessary for that. >> >> I had an idea that one could define rules for sctp_assoc_t such that >> valid one-to-many association ids would be outside the range of valid >> file descriptors, and give one-to-one sockets an association id equal >> to the file descriptor value, and that way provide a single handle >> space without the need for virtual handles and lookup tables in >> user-space. However, it breaks with peeloff, since then the >> association id would have to change. Therefore my suggestion is simply >> to clarify what the current rules are. >> >> /Anders Torger >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> >> > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > --------------ms060001020609010502070201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAw4N5TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjE2MTcyMjMyWhcNMDYwMjE2MTcyMjMy WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkJ4Av 1WhkKpIYhf/0i0gyxjt7EJTVwEqu4IAdRbdPmW0PtU4CnPEExg0OK83Pj+aoSPNt7pPEU88d S3V0cdxg73NbLBR/tZWh6q0K7i+Z4u/Qr4JtxkxumOnvHkeA4+1p9HHR6IzvIs24eiaXAqW1 ZSHdgwx6uqsK6H9mk51UoQI1QGl3Wdw6mSeBlIR3O5hOzMjXPMCCjJGhFZYrpSCHwUCh9tgt Km/uJgfZpSH5yW6XdVeZR0SQj4KMrRkmhPCPM2IPv3NLq0uv8H0swFnLAeQnR5j4wR544Dt9 WIly9Fsd7mmZlmBnywl/E/FvM8/Gm5eOglgngebh3fNVXKOnAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AJkyBoxpqV933q1JmykuDuUydcGoUBse4oyuVgyME2N653V+kPi0UN/qqspXevqrjubIK2Fh Qp+5fjBdzl64J3aOD8WuYy7uSIm76RmfX6Yn1PuR/sFiJGJiG0qF4VfbwS7phAaml0E1mbKi /hjA+3I/hhYzZLM5HvGgBh8o5TsJMIIC0TCCAjqgAwIBAgIDDg3lMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTAy MTYxNzIyMzJaFw0wNjAyMTYxNzIyMzJaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAKQngC/VaGQqkhiF//SLSDLGO3sQlNXASq7ggB1Ft0+ZbQ+1 TgKc8QTGDQ4rzc+P5qhI823uk8RTzx1LdXRx3GDvc1ssFH+1laHqrQruL5ni79Cvgm3GTG6Y 6e8eR4Dj7Wn0cdHojO8izbh6JpcCpbVlId2DDHq6qwrof2aTnVShAjVAaXdZ3DqZJ4GUhHc7 mE7MyNc8wIKMkaEVliulIIfBQKH22C0qb+4mB9mlIfnJbpd1V5lHRJCPgoytGSaE8I8zYg+/ c0urS6/wfSzAWcsB5CdHmPjBHnjgO31YiXL0Wx3uaZmWYGfLCX8T8W8zz8abl46CWCeB5uHd 81Vco6cCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAmTIGjGmpX3ferUmbKS4O5TJ1wahQGx7ijK5WDIwT Y3rndX6Q+LRQ3+qqyld6+quO5sgrYWFCn7l+MF3OXrgndo4Pxa5jLu5IibvpGZ9fpifU+5H+ wWIkYmIbSoXhV9vBLumEBqaXQTWZsqL+GMD7cj+GFjNkszke8aAGHyjlOwkwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAw4N5TAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA1MTEyMjIwNDFaMCMGCSqGSIb3DQEJ BDEWBBRpXBpWllkwGo4PGsB91j6iXGtFBjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDDg3lMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw4N5TANBgkqhkiG9w0BAQEFAASCAQAAU8HW kFjHKr026MbCbtFLEZn4g5zEW+Vc15daKbDQctPDoutWxtFRZwXGHxixI5DmwSVjZrNVF8c5 2EdFdgG660hv4FmgPibFamSLnv/lPu0y60AjBy6InaJVZ6XOI7EMqSDnUkovpVBRd/GqolQd uY911hBKPuIPlfNrx1z7BCACxvHnwK05q17ND7E939GPwq9QsybXIn170qXEXgYMizllJkLJ PTCx5d+JEWdDVOOe60b28+6CUDGsXhNyQYvmRByWFzq706emcmSsYKEfGqfW3/sly/zrN3Uu 6N6078RxUVaM5BVqDLn/oqJa3ah3zFvAN9rg6wWJ1oANl7g8AAAAAAAA --------------ms060001020609010502070201-- --===============1369061426== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1369061426==-- From tsvwg-bounces@ietf.org Thu May 12 05:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10098 for ; Thu, 12 May 2005 05:50:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWAaV-0004L6-7u for tsvwg-archive@ietf.org; Thu, 12 May 2005 06:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWAIK-0007S1-Kn; Thu, 12 May 2005 05:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWAIG-0007Rs-Iw for tsvwg@megatron.ietf.org; Thu, 12 May 2005 05:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09973 for ; Thu, 12 May 2005 05:47:46 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWAXv-0004FJ-Kh for tsvwg@ietf.org; Thu, 12 May 2005 06:04:02 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j4C9hu4n011384; Thu, 12 May 2005 05:43:57 -0400 (EDT) (envelope-from randall@lakerest.net) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <428326B5.7080708@lakerest.net> Date: Thu, 12 May 2005 05:49:41 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Torger Subject: Re: [Tsvwg] Sockets API suggestion concerning sctp_assoc_t References: <200505102044.26181.torger@ludd.luth.se> <42827B4B.1070009@us.ibm.com> <200505112358.23485.torger@ludd.luth.se> In-Reply-To: <200505112358.23485.torger@ludd.luth.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Anders: I will also add a couple of items.. in addition to what Peter said in his subsequent posting... this time I read all the posts before replying :-D So we have these true for BSD - sctp_assoc_t is defined as signed 32 bit value. - The valid values of associd are 1-0xffffffff. (This is different) - They don't have any relationship with file descriptors. - All associations have a associd irrespective of whether they belong to 1-1 or 1-many style sockets. - The associd will not change when the association is peeled-off to a different socket. --- And----- - Association id's are time-waited... this means that an associd will NOT be reused for 2 MSL's after the association has been terminated. - We do, currently, have an issue with assoc-id's that we need to discuss (has Kacheong mentioned earlier but I have been to busy to get to :-D) which is when an association restarts it will experience a associd change... I won't go in to why, I will save it for the other thread :-D Anders Torger wrote: > Ok, but if I have understood the API draft correctly, it is not possible > to get or access a one-to-one socket with an sctp_assoc_t, thus the > association id would be hidden for the user. Unfortunately there are notes in the document that specify that the assoc-id is ignored for 1-2-1.. but I think this restriction should be removed. To me, it would make more sense from an application point of view to be able to have an assoc-id even on 1-2-1 sockets.. In order to get the association id of any assoc I have always used the SCTP_PEER_ADDR_PARAMS with one of the assoc's addresses. This then returns an assoic-id.. kind of a handy way to translate the address ---> assoc_id :-) > > It seems to me however, that in lksctp, the association id is indeed > visible in (for example) notifications for one-to-one sockets, although > it says in the API draft that the value should be "ignored". On Solaris > 10, a seemingly random value is delivered instead. It would also be visiable in BSD as well.. in all cases we populate this field... notifications, options etc... > > I would prefer the lksctp model, or that the value is set to zero. In > any case, it is not clear how it should work in the API draft. It seems to me having the field is a good thing.. > > I also like the model where sctp_assoc_t is signed, and that only > positive values are valid associations, in that way looking a bit like > file descriptors, and making it possible to make functions that return > sctp_assoc_t giving either a valid (>0), undefined (=0) or error (<0) > as result. Hmm.. I see your point... but this seg-way's in to how an implementation uses the assoc-id... and so join me on the other thread to voice your concerns (hopefully you are on the sctp-impl list)... > > It is also nice that the association id is kept at peeloff, avoiding > that the id would be re-used by another one-to-many association before > the original socket has closed. Also this is not specified how it > should work in the API draft. Hmm. yes maybe more specific info is needed... lets have the other conversation and see where we end up at :-D R > > /Anders Torger > > On Wednesday 11 May 2005 23.38, Sridhar Samudrala wrote: > >>I think sctp-impl is the right mailing list for SCTP implementation >>specific discussions. So i am adding sctp-impl to the CC list. >> >>I would like to clarify how associd is currently defined and >>implemented in linux SCTP(lksctp). >>- sctp_assoc_t is defined as signed 32 bit value. >>- The valid values of associd are 1-0x7fffffff. >>- They don't have any relationship with file descriptors. >>- All associations have a associd irrespective of whether they belong >> to 1-1 or 1-many style sockets. >>- The associd will not change when the association is peeled-off to >> a different socket. >> >>Thanks >>Sridhar >> >>Anders Torger wrote: >> >>>One problem with sctp_assoc_t is that there is no clear definition >>>of what the values can be. >>> >>>The only thing I can find out from >>>draft-ietf-tsvwg-sctpsocket-10.txt is that zero is not a valid >>>value for an association, but any other value may be. >>> >>>It would be great if the API draft would specify some facts/rules >>>about sctp_assoc_t and association ID. I *think* this is true, and >>>I'd like that it was mentioned more clearly in the draft: >>> >>>- sctp_assoc_t is an integer of unspecified size and may be signed >>>or unsigned >>>- a valid association has an id != 0 (that is both positive and >>> negative sctp_assoc_t are valid values). >>>- a one-to-one socket has no association id >>>- a peeled off socket will lose its association id (the file >>>descriptor should be used for future reference), and the old id may >>>be immediately re-used by a new one-to-many association. >>> >>>In lksctp, it seems like one-to-one sockets have an association id >>>anyway, which is equal to the file descriptor value, while in >>>Solaris 10 a random value is provided as association id in events >>>on one-to-one sockets. >>> >>>I would prefer if the API draft would specify that the OS must set >>>the association id to zero in returned events for one-to-one >>>sockets instead of allowing it to contain a random value like in >>>Solaris 10, or something that might be usable like in lksctp. This >>>will make the API safer (=bugs in user code is easier detected). >>> >>>When mixing one-to-many and one-to-one sockets there can often be a >>>need to provide a single space of handles for associations to upper >>>layers within the application. Handles which work for both >>>one-to-many sockets and one-to-one sockets, and does not change at >>>peeloff. This is a bit of a pain, since file descriptor values can >>>collide with association id values, and association id is lost at >>>peeloff. But I don't think there is much one can do about it. >>>Virtual handles unrelated to file descriptors and sctp_assoc_t >>>combined with a lookup table is necessary for that. >>> >>>I had an idea that one could define rules for sctp_assoc_t such that >>>valid one-to-many association ids would be outside the range of >>>valid file descriptors, and give one-to-one sockets an association >>>id equal to the file descriptor value, and that way provide a >>>single handle space without the need for virtual handles and lookup >>>tables in user-space. However, it breaks with peeloff, since then >>>the association id would have to change. Therefore my suggestion is >>>simply to clarify what the current rules are. >>> >>>/Anders Torger >>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon May 16 15:34:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29170 for ; Mon, 16 May 2005 15:34:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlcx-0001xh-KZ for tsvwg-archive@ietf.org; Mon, 16 May 2005 15:51:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlKb-0005Nf-Bg; Mon, 16 May 2005 15:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlKZ-0005ND-Jh for tsvwg@megatron.ietf.org; Mon, 16 May 2005 15:32:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29006 for ; Mon, 16 May 2005 15:32:45 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlb9-0001u2-MQ for tsvwg@ietf.org; Mon, 16 May 2005 15:49:57 -0400 Received: from [10.0.1.65] (maxp25.dialup.abdn.ac.uk [139.133.201.184]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4GJVZHd003774 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 16 May 2005 20:31:39 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 15 May 2005 22:32:42 +0100 From: Gorry Fairhurst To: , Message-ID: 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-Score: 0.4 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk Subject: [Tsvwg] Draft-floyd-ecn-alternates-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Sally, So I read the above document, and it initially talks about whether alternative semantics can harm existing conforming sessions, that seems like the right place to start. Remarking 11 to another value is not allowed. This seems right. This leaves some options for remarking to indicate congestion: 1) Remarking to '11'. That is: 01 -> 11 or 10 -> 11 This is the currently expected norm for ECN. Remarking 00 to 11 is odd, but seems safe. 2) Alternatively, a different behaviour may arise if a router remarked: 01 -> 10 or 10 -> 01 This seems a potential candidate for another behaviour, possibly to signal something (less than normal congestion, or at least different to 11) to an end host. This remarking doesn't ensure a a full congestion response as in 11. If however "ECN-NONCE" were used at the end-hosts, this remarking would be interpreted as congestion signalling - safe for the network, but perhaps an expected (more severe) outcome. You don't say it, but I wonder if it should also be said it that it is illegal to remark *from* 00? - Remarking 00 -> 01 (or 00 -> 10) allows a non-ECN capable packet to pretend to be ECN-capable, and thereby possibly by-pass early discard, by suggesting to the router that remarking will likely have an effect (be honoured, even though the end host didn't specify ECN support). Best wishes, Gorry _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon May 16 16:17:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13957 for ; Mon, 16 May 2005 16:17:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmIV-0007fb-Iv for tsvwg-archive@ietf.org; Mon, 16 May 2005 16:34:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlve-0006MR-5A; Mon, 16 May 2005 16:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXlvb-0006M6-Rd for tsvwg@megatron.ietf.org; Mon, 16 May 2005 16:11:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11409 for ; Mon, 16 May 2005 16:11:01 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmCB-0006ce-Vg for tsvwg@ietf.org; Mon, 16 May 2005 16:28:13 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j4GKAtDu050863; Mon, 16 May 2005 13:10:55 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200505162010.j4GKAtDu050863@cougar.icir.org> To: Gorry Fairhurst From: Sally Floyd Date: Mon, 16 May 2005 13:10:55 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: Draft-floyd-ecn-alternates-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Gorry - >You don't say it, but I wonder if it should also be said it that it is >illegal to remark *from* 00? >- Remarking 00 -> 01 (or 00 -> 10) allows a non-ECN capable packet to >pretend to be ECN-capable, and thereby possibly by-pass early discard, by >suggesting to the router that remarking will likely have an effect (be >honoured, even though the end host didn't specify ECN support). Ah dear, probably you are right. I will add that to the document. Thanks, - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon May 16 16:19:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14664 for ; Mon, 16 May 2005 16:19:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmJx-0007tZ-K4 for tsvwg-archive@ietf.org; Mon, 16 May 2005 16:36:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXm2N-0002O9-Ej; Mon, 16 May 2005 16:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXm2M-0002Mk-70 for tsvwg@megatron.ietf.org; Mon, 16 May 2005 16:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14172 for ; Mon, 16 May 2005 16:17:59 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXmIw-0007kD-Mo for tsvwg@ietf.org; Mon, 16 May 2005 16:35:11 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id j4GKHuZo050919; Mon, 16 May 2005 13:17:56 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200505162017.j4GKHuZo050919@cougar.icir.org> To: Gorry Fairhurst From: Sally Floyd Date: Mon, 16 May 2005 13:17:56 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tsvwg@ietf.org Subject: [Tsvwg] Re: Draft-floyd-ecn-alternates-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >2) Alternatively, a different behaviour may arise if a router remarked: >01 -> 10 or 10 -> 01 >This seems a potential candidate for another behaviour, possibly to signal >something (less than normal congestion, or at least different to 11) to an >end host. This remarking doesn't ensure a a full congestion response as in >11. If however "ECN-NONCE" were used at the end-hosts, this remarking would >be interpreted as congestion signalling - safe for the network, but perhaps >an expected (more severe) outcome. And you are right, this one would need a note. If the sender is signalling the use of alternate semantics, then this one should not be a problem. The problem would occur if this was done on a packet where the sender was using the default ECN semantics. In this case, the sender might interpret this as a receiver lying when it reports that the packet was not ECN-marked, because the receiver can't return the correct nonce that verifies that the packet in fact wasn't ECN-marked. So if the router remarks 01 -> 10 or 10 -> 01, the router should be *quite* sure that the packet comes from a sender that is using the alternate ECN semantics. Yes? - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 17 07:02:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08017 for ; Tue, 17 May 2005 07:02:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY07B-0006ne-S5 for tsvwg-archive@ietf.org; Tue, 17 May 2005 07:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzoP-0007YZ-SJ; Tue, 17 May 2005 07:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzoO-0007YT-4q for tsvwg@megatron.ietf.org; Tue, 17 May 2005 07:00:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07784 for ; Tue, 17 May 2005 07:00:28 -0400 (EDT) Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY056-0006e2-IB for tsvwg@ietf.org; Tue, 17 May 2005 07:17:50 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id j4HAxIOo021091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 May 2005 11:59:19 +0100 (BST) Message-ID: <4289CE86.6090805@erg.abdn.ac.uk> Date: Tue, 17 May 2005 11:59:18 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd Subject: Re: [Tsvwg] Re: Draft-floyd-ecn-alternates-00.txt References: <200505162017.j4GKHuZo050919@cougar.icir.org> In-Reply-To: <200505162017.j4GKHuZo050919@cougar.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Sally Floyd wrote: >>2) Alternatively, a different behaviour may arise if a router remarked: >>01 -> 10 or 10 -> 01 >>This seems a potential candidate for another behaviour, possibly to signal >>something (less than normal congestion, or at least different to 11) to an >>end host. This remarking doesn't ensure a a full congestion response as in >>11. If however "ECN-NONCE" were used at the end-hosts, this remarking would >>be interpreted as congestion signalling - safe for the network, but perhaps >>an expected (more severe) outcome. > > > And you are right, this one would need a note. > > If the sender is signalling the use of alternate semantics, then this > one should not be a problem. > I agree. > The problem would occur if this was done on a packet where the > sender was using the default ECN semantics. In this case, the > sender might interpret this as a receiver lying when it reports > that the packet was not ECN-marked, because the receiver can't > return the correct nonce that verifies that the packet in fact > wasn't ECN-marked. So if the router remarks 01 -> 10 or 10 -> 01, > the router should be *quite* sure that the packet comes from a sender > that is using the alternate ECN semantics. > > Yes? > Yes! - Otherwise it should use the default of drop or remark to '11'. > - Sally > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 17 11:23:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05612 for ; Tue, 17 May 2005 11:23:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY4BB-00054d-6c for tsvwg-archive@ietf.org; Tue, 17 May 2005 11:40:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY3rE-0002L6-R0; Tue, 17 May 2005 11:19:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXutZ-0000X3-M7 for tsvwg@megatron.ietf.org; Tue, 17 May 2005 01:45:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19705 for ; Tue, 17 May 2005 01:45:32 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXvAD-0006rQ-FH for tsvwg@ietf.org; Tue, 17 May 2005 02:02:48 -0400 Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4H5j6mg000617 for ; Tue, 17 May 2005 00:45:12 -0500 (CDT) Received: from [10.255.1.118] by axes-mach01.axes-mach01.usa.alcatel.com (8.11.7p1+Sun/SMI-SVR4) id j4HGE6e25541; Tue, 17 May 2005 11:14:22 -0500 (GMT) Message-ID: <42898666.3050006@axes-mach01.usa.alcatel.com> Date: Tue, 17 May 2005 11:21:34 +0530 From: Subhashini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: [Tsvwg] With/Without Heartbeat - outstanding data chunks References: <200505162017.j4GKHuZo050919@cougar.icir.org> In-Reply-To: <200505162017.j4GKHuZo050919@cougar.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 May 2005 11:19:43 -0400 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi All, When Heartbeat is enabled: ================== Whenever any data chunk is transmitted, T3-rtx timer is started, if not running already. When we fail to get SACK for the data chunk, it is marked for retransmission and error counter is incremented. Also, we reset this error count, whenever any SACK or Heartbeat Ack is received. If no SACK or Heartbeat Ack, once the error counter reaches the maximum value, communication lost notification is given to the peer and association is closed. In this case, suppose Heartbeat/Heartbeat Acks are exchanged without fail and if data chunks are not unacknowledged, upper layer will not be notified and there will not be any change in the association state. What is the other possibility to find out the unacknowledgement of data chunks and closing the association? Do we need to assume that, if the peer is able to acknowldge the heartbeat, it should be acknowledging the data chunk also? When Heartbeat is not enabled: ===================== In this case, since only the SACK is the only way of acknowledging the data chunk, the error counter will reach the maximum value and close the association. Please clarify. thanks, Subhashini ... _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 17 14:58:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26181 for ; Tue, 17 May 2005 14:58:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY7Y6-0000Fg-T1 for tsvwg-archive@ietf.org; Tue, 17 May 2005 15:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7FV-0003vk-OP; Tue, 17 May 2005 14:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7FT-0003vf-OK for tsvwg@megatron.ietf.org; Tue, 17 May 2005 14:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26076 for ; Tue, 17 May 2005 14:56:57 -0400 (EDT) Received: from pun.isi.edu ([128.9.160.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY7WG-0000E9-GR for tsvwg@ietf.org; Tue, 17 May 2005 15:14:21 -0400 Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4HIuQat021163; Tue, 17 May 2005 11:56:26 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4HIuPOq021160; Tue, 17 May 2005 11:56:25 -0700 (PDT) (envelope-from faber) Date: Tue, 17 May 2005 11:56:25 -0700 From: Ted Faber To: Subhashini Subject: Re: [Tsvwg] With/Without Heartbeat - outstanding data chunks Message-ID: <20050517185625.GA21028@pun.isi.edu> References: <200505162017.j4GKHuZo050919@cougar.icir.org> <42898666.3050006@axes-mach01.usa.alcatel.com> Mime-Version: 1.0 In-Reply-To: <42898666.3050006@axes-mach01.usa.alcatel.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170848303==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============1170848303== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 17, 2005 at 11:21:34AM +0530, Subhashini wrote: > Hi All, > > When Heartbeat is enabled: [...] > > Please clarify. You first. Supplying some context would help someone who isn't you answer your question. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCij5ZaUz3f+Zf+XsRAqb9AJ4h7iobtD6B5MY05XgWITz3tNlRxQCgnPsy R91VyRxg+oCbuRN9UyooFQ4= =lzuH -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- --===============1170848303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1170848303==-- From tsvwg-bounces@ietf.org Tue May 17 15:07:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27393 for ; Tue, 17 May 2005 15:07:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY7gn-0000iY-UL for tsvwg-archive@ietf.org; Tue, 17 May 2005 15:25:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7Os-00066t-RH; Tue, 17 May 2005 15:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7Or-00066o-2N for tsvwg@megatron.ietf.org; Tue, 17 May 2005 15:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27184 for ; Tue, 17 May 2005 15:06:38 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY7fd-0000gs-Tp for tsvwg@ietf.org; Tue, 17 May 2005 15:24:03 -0400 Received: from [192.168.1.10] (p508F782F.dip.t-dialin.net [80.143.120.47]) by ilsa.franken.de (Postfix) with ESMTP id 83883245CE; Tue, 17 May 2005 21:06:34 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <42898666.3050006@axes-mach01.usa.alcatel.com> References: <200505162017.j4GKHuZo050919@cougar.icir.org> <42898666.3050006@axes-mach01.usa.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A2F52BB-FEE9-45EC-8194-83AAFCABCEFE@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] With/Without Heartbeat - outstanding data chunks Date: Tue, 17 May 2005 21:06:32 +0200 To: Subhashini X-Mailer: Apple Mail (2.730) X-Spam-Score: 3.0 (+++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hi Subhashini, see my comments in-line. Best regards Michael On May 17, 2005, at 7:51 AM, Subhashini wrote: > Hi All, > > When Heartbeat is enabled: > ================== > Whenever any data chunk is transmitted, T3-rtx timer is started, > if not running already. When we fail to get SACK for the data > chunk, it is marked for retransmission and error counter is > incremented. Also, we reset this error count, whenever any SACK or > Heartbeat Ack is received. If no SACK or Heartbeat Ack, once the > error counter reaches the maximum value, communication lost > notification is given to the peer and association is closed. In > this case, suppose Heartbeat/Heartbeat Acks are exchanged without > fail and if data chunks are not unacknowledged, upper layer will > not be notified and there will not be any change in the association > state. What is the other possibility to find out the That is correct. But the SCTP implementation on the receiving side is broken if it responds to HB with HB-ACKs but does not send SACK in response to DATA chunks. > unacknowledgement of data chunks and closing the association? Do we > need to assume that, if the peer is able to acknowldge the > heartbeat, it should be acknowledging the data chunk also? This is the correct behaviour. If you want more, you need application level heartbeats... > > When Heartbeat is not enabled: > ===================== > In this case, since only the SACK is the only way of acknowledging > the data chunk, the error counter will reach the maximum value and > close the association. Correct. > > Please clarify. > > thanks, > Subhashini ... > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 18 03:35:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13880 for ; Wed, 18 May 2005 03:35:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYJMI-00025I-T7 for tsvwg-archive@ietf.org; Wed, 18 May 2005 03:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJ2j-00080Q-MA; Wed, 18 May 2005 03:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYJ2h-000803-Vr for tsvwg@megatron.ietf.org; Wed, 18 May 2005 03:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13635 for ; Wed, 18 May 2005 03:32:33 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYJJa-0001v3-KF for tsvwg@ietf.org; Wed, 18 May 2005 03:50:04 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j4I7WPZI013061; Wed, 18 May 2005 09:32:25 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j4I7WOXX022316; Wed, 18 May 2005 09:32:24 +0200 Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id j4I7WOi3027144; Wed, 18 May 2005 09:32:24 +0200 Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 18 May 2005 09:27:04 +0200 Message-ID: From: Schruefer Wolfgang To: "'Subhashini'" Subject: RE: [Tsvwg] With/Without Heartbeat - outstanding data chunks Date: Wed, 18 May 2005 09:32:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi Subhashini, even if heartbeat is enabled, by default a heartbeat is sent only to *IDLE* addresses, RFC2960 says: " By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). A destination transport address is considered "idle" if no new chunk ... has been sent to it ..." In this case the association would close any time if DATA chunks are not acknowledged. Best regards, Wolfgang > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > On Behalf Of Subhashini > Sent: Tuesday, May 17, 2005 7:52 AM > To: tsvwg@ietf.org > Subject: [Tsvwg] With/Without Heartbeat - outstanding data chunks > > Hi All, > > When Heartbeat is enabled: > ================== > Whenever any data chunk is transmitted, T3-rtx timer is > started, if not running already. When we fail to get SACK for > the data chunk, it is marked for retransmission and error > counter is incremented. Also, we reset this error count, > whenever any SACK or Heartbeat Ack is received. > If no SACK or Heartbeat Ack, once the error counter reaches > the maximum value, communication lost notification is given > to the peer and association is closed. In this case, suppose > Heartbeat/Heartbeat Acks are exchanged without fail and if > data chunks are not unacknowledged, upper layer will not be > notified and there will not be any change in the association > state. What is the other possibility to find out the > unacknowledgement of data chunks and closing the association? > Do we need to assume that, if the peer is able to acknowldge > the heartbeat, it should be acknowledging the data chunk also? > > When Heartbeat is not enabled: > ===================== > In this case, since only the SACK is the only way of > acknowledging the data chunk, the error counter will reach > the maximum value and close the association. > > Please clarify. > > thanks, > Subhashini ... > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri May 20 13:08:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08616 for ; Fri, 20 May 2005 13:08:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZBGL-00080G-7A for tsvwg-archive@ietf.org; Fri, 20 May 2005 13:26:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAx8-0004HW-88; Fri, 20 May 2005 13:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNEx-0005dU-VP for tsvwg@megatron.ietf.org; Wed, 18 May 2005 08:01:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10025 for ; Wed, 18 May 2005 08:01:30 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYNVu-0000lo-KZ for tsvwg@ietf.org; Wed, 18 May 2005 08:19:03 -0400 Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4IC1GCR003829; Wed, 18 May 2005 07:01:17 -0500 (CDT) Received: from [10.255.1.118] by axes-mach01.axes-mach01.usa.alcatel.com (8.11.7p1+Sun/SMI-SVR4) id j4IMU6e16784; Wed, 18 May 2005 17:30:16 -0500 (GMT) Message-ID: <428B3009.2060408@axes-mach01.usa.alcatel.com> Date: Wed, 18 May 2005 17:37:37 +0530 From: Subhashini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Schruefer Wolfgang Subject: Re: [Tsvwg] With/Without Heartbeat - outstanding data chunks References: In-Reply-To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Fri, 20 May 2005 13:06:24 -0400 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1518749329==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c This is a multi-part message in MIME format. --===============1518749329== Content-Type: multipart/alternative; boundary="------------040709090004080204090406" This is a multi-part message in MIME format. --------------040709090004080204090406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Wolfgang, My case is little different. As you said, Heartbeat is sent only to the Idle destination address. If that destination does not respond with SACK for the data chunks received for the time greater than Heartbeat interval, HB will be sent to it and in case, if HB ACK is received for that destination, but no SACK for the old data chunks received, what do we conclude was my question. But, as per Michael in the previous response, this behaviour depends on the destination side SCTP implementation. Also, as he said, we have to depend on the application level Heartbeat and ACK. thanks, Subhashini ... Schruefer Wolfgang wrote: >Hi Subhashini, > >even if heartbeat is enabled, by default a heartbeat is sent only to *IDLE* addresses, RFC2960 says: > > " By default, an SCTP endpoint shall monitor the reachability of the > idle destination transport address(es) of its peer by sending a > HEARTBEAT chunk periodically to the destination transport > address(es). > A destination transport address is considered "idle" if no new chunk > ... has been sent to it ..." > >In this case the association would close any time if DATA chunks are not acknowledged. > >Best regards, >Wolfgang > > > >>-----Original Message----- >>From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] >>On Behalf Of Subhashini >>Sent: Tuesday, May 17, 2005 7:52 AM >>To: tsvwg@ietf.org >>Subject: [Tsvwg] With/Without Heartbeat - outstanding data chunks >> >>Hi All, >> >>When Heartbeat is enabled: >>================== >> Whenever any data chunk is transmitted, T3-rtx timer is >>started, if not running already. When we fail to get SACK for >>the data chunk, it is marked for retransmission and error >>counter is incremented. Also, we reset this error count, >>whenever any SACK or Heartbeat Ack is received. >>If no SACK or Heartbeat Ack, once the error counter reaches >>the maximum value, communication lost notification is given >>to the peer and association is closed. In this case, suppose >>Heartbeat/Heartbeat Acks are exchanged without fail and if >>data chunks are not unacknowledged, upper layer will not be >>notified and there will not be any change in the association >>state. What is the other possibility to find out the >>unacknowledgement of data chunks and closing the association? >>Do we need to assume that, if the peer is able to acknowldge >>the heartbeat, it should be acknowledging the data chunk also? >> >>When Heartbeat is not enabled: >>===================== >>In this case, since only the SACK is the only way of >>acknowledging the data chunk, the error counter will reach >>the maximum value and close the association. >> >>Please clarify. >> >>thanks, >>Subhashini ... >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >> >> >> > > > > --------------040709090004080204090406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Wolfgang,

  My case is little different. As you said, Heartbeat is sent only to the Idle destination address.
  If that destination does not respond with SACK for the data chunks received for the time greater than Heartbeat interval, HB will be sent to it and in case, if HB ACK is received for that destination, but no SACK for the old data chunks received, what do we conclude was my question. But, as per Michael in the previous response, this behaviour depends on the destination side SCTP implementation. Also, as he said, we have to depend on the application level Heartbeat and ACK.

thanks,
Subhashini ...

Schruefer Wolfgang wrote:
Hi Subhashini,

even if heartbeat is enabled, by default a heartbeat is sent only to *IDLE* addresses, RFC2960 says:

   " By default, an SCTP endpoint shall monitor the reachability of the
   idle destination transport address(es) of its peer by sending a
   HEARTBEAT chunk periodically to the destination transport
   address(es).
   A destination transport address is considered "idle" if no new chunk
   ... has been sent to it ..."

In this case the association would close any time if DATA chunks are not acknowledged.

Best regards,
Wolfgang

  
-----Original Message-----
From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] 
On Behalf Of Subhashini
Sent: Tuesday, May 17, 2005 7:52 AM
To: tsvwg@ietf.org
Subject: [Tsvwg] With/Without Heartbeat - outstanding data chunks

Hi All,

When Heartbeat is enabled:
==================
  Whenever any data chunk is transmitted, T3-rtx timer is 
started, if not running already. When we fail to get SACK for 
the data chunk, it is marked for retransmission and error 
counter is incremented. Also, we reset this error count, 
whenever any SACK or Heartbeat Ack is received. 
If no SACK or Heartbeat Ack, once the error counter reaches 
the maximum value, communication lost notification is given 
to the peer and association is closed. In this case, suppose 
Heartbeat/Heartbeat Acks are exchanged without fail and if 
data chunks are not unacknowledged, upper layer will not be 
notified and there will not be any change in the association 
state. What is the other possibility to find out the 
unacknowledgement of data chunks and closing the association? 
Do we need to assume that, if the peer is able to acknowldge 
the heartbeat, it should be acknowledging the data chunk also?

When Heartbeat is not enabled:
=====================
In this case, since only the SACK is the only way of 
acknowledging the data chunk, the error counter will reach 
the maximum value and close the association.

Please clarify.

thanks,
Subhashini ...

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

--------------040709090004080204090406-- --===============1518749329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1518749329==-- From tsvwg-bounces@ietf.org Mon May 23 10:37:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29755 for ; Mon, 23 May 2005 10:37:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaELy-0005vq-1L for tsvwg-archive@ietf.org; Mon, 23 May 2005 10:56:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaE1C-0003yr-JH; Mon, 23 May 2005 10:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaE1B-0003yD-Ez for tsvwg@megatron.ietf.org; Mon, 23 May 2005 10:34:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29526 for ; Mon, 23 May 2005 10:34:55 -0400 (EDT) Received: from adsl-065-005-216-181.sip.cae.bellsouth.net ([65.5.216.181] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEJ9-0005qy-07 for tsvwg@ietf.org; Mon, 23 May 2005 10:53:33 -0400 Received: from localhost (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with SMTP id j4NEYr4n082227 for ; Mon, 23 May 2005 10:34:53 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) X-Authentication-Warning: stewart.stewart.chicago.il.us: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4291EB60.8030701@stewart.chicago.il.us> Date: Mon, 23 May 2005 10:40:32 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050330 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSWG References: <20050506133611.818AF77A9DB@guns.icir.org> <427F40E5.8090101@lakerest.net> In-Reply-To: <427F40E5.8090101@lakerest.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: A question on two methods of Fast Retransmit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Greetings: Mark, Vern and I have had a recent discussion on SCTP's 4 missing reports to do a fast retransmit vesus 3 missing reports in TCP... I think the conclusion we have reached is that we really should have done SCTP's FR algorithm the same as TCP.. aka 3 missing reports.. So.. thinking about this.. we probably should add it to the implementors guide and correct this to be as Mark says... and yes I am overdue in getting the "last 2 items" into the impelmentors guide :-9 I have some time this week.. so hopefully I will get the other two items (per Minn) and this one.. and we can get that in for last call.. Comments??? R Randall Stewart wrote: > MarK > Comments below... > > Mark Allman wrote: > >> Randall- >> >> I can explain the TCP cases. I am not sure I remember or ever knew why >> SCTP uses the constant it uses. >> >> To trip FR in TCP takes 3 or 4 *duplicate* ACKs. Just for the sake of >> simplicity, say we're doing delayed ACKs and ACKing the even numbered >> packets. So, the cases look like this... >> >> Case #1 >> ------- >> >> This is the receiver's behavior after receiving packets up to 56 in >> order (58 being pulled out of the air) and we'll assume that packet 60 >> is lost: >> >> packet 57 arrives, in order, delay ACK >> packet 58 arrives, in order, ACK 59 (next expected) >> packet 59 arrives, in order, delay ACK >> packet 61 arrives, trigger ACK for packet 60 (next expected) >> if using SACK packet 61 will be SACKed >> packet 61 arrives, trigger ACK for packet 60 >> (maybe SACK for 60-61) >> packet 62 arrives, trigger ACK for packet 60 >> (maybe SACK for 60-62) >> packet 61 arrives, trigger ACK for packet 60 > > You mean 63? > >> (maybe SACK for 60-61) > > > So the above would be something like this for > SCTP: > > --------59----------> > --------61----------> > <----SACK(ca-59, 61-61) > Cnt=1 > --------62----------> > <----SACK(ca-59, 61-62) > Cnt=2 > --------63----------> > <----SACK(ca-59, 61-63) > Cnt=3 > --------64----------> > <----SACK(ca-59, 61-64) > Cnt=4 > FR happens----60------> > > >> >> So, to trip FR we send 4 ACKs with the same ACK number - and they >> correspond to 4 "missing reports", as well. >> >> Case #2 >> ------- >> >> Rather than losing 60, assume 59 is lost. >> >> packet 57 arrives, in order, delay ACK >> packet 58 arrives, in order, ACK 59 (next expected) >> packet 60 arrives, trigger ACK for packet 59 (next expected) >> if using SACK packet 60 will be SACKed >> packet 61 arrives, trigger ACK for packet 59 >> (maybe SACK for 60-61) >> packet 62 arrives, trigger ACK for packet 59 >> (maybe SACK for 60-62) >> > > And SCTP's case would be: > -------58-------> > <---SACK(ca=58) > -------60-------> > <----SACK(ca=58, 60-60) > Cnt=1 > -------61-------> > <----SACK(ca=58, 60-61) > Cnt=2 > -------62-------> > <----SACK(ca=58, 60-62) > Cnt=3 > -------63-------> > <----SACK(ca=58, 60-63) > Cnt=4 > FR happens ----60--------> > > > So in both cases SCTP waits one extra packet to FR... > > >> So, in this case we trip FR on 4 ACKs with the same ACK number but they >> only correspond to 3 "missing reports". >> >> >> The key is because of the delayed ACK in the first case the first >> "missing report" changes the cumulative ACK point because there is an >> ACK currently being delayed. In the second case there is no ACK being >> delayed and so the first missing report holds the ACK point constant. >> >> I am not sure this is a "corner case". I think each case is probably >> just as likely as the other. It just depends on where the loss hits. >> >> IMO, case #2 is the best path. But, there isn't really a way to >> disambiguate things in non-SACK TCP. In SCTP, since SACK is Just There, >> I think you can just say 3 "missing reports" and leave it at that. That >> seems much cleaner to me. (And, I think it would be nice to say this >> for SACK TCP, as well.) >> >> Does that help? > > > Yep... I think basically Paul is correct.. we got the wording > wrong ... and it shoudl be 3 missing reports.. > > Vern?? > > R > >> >> allman >> >> >> > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 24 04:35:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07189 for ; Tue, 24 May 2005 04:35:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaVBI-0000rc-QX for tsvwg-archive@ietf.org; Tue, 24 May 2005 04:54:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUpU-0005Fd-Gj; Tue, 24 May 2005 04:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUpS-0005FY-GA for tsvwg@megatron.ietf.org; Tue, 24 May 2005 04:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06936 for ; Tue, 24 May 2005 04:31:56 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaV7a-0000jo-MK for tsvwg@ietf.org; Tue, 24 May 2005 04:50:43 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4O8Vjmg017856 for ; Tue, 24 May 2005 03:31:46 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id NAA04062; Tue, 24 May 2005 13:51:25 -0500 (GMT) Message-ID: <4292E7A6.6060001@axesb2.usa.alcatel.com> Date: Tue, 24 May 2005 14:06:54 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Tsvwg] SCTP - HB/HB-ack processing X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hai all.. When a Heartbeat or Heartbeat-Ack is received without any information, what action need to be taken. Please clarify. Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue May 24 15:21:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04263 for ; Tue, 24 May 2005 15:21:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DafGl-00012P-Vv for tsvwg-archive@ietf.org; Tue, 24 May 2005 15:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daex6-0002gs-Ud; Tue, 24 May 2005 15:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daex5-0002gn-9x for tsvwg@megatron.ietf.org; Tue, 24 May 2005 15:20:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04060 for ; Tue, 24 May 2005 15:20:29 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DafFJ-0000yC-7j for tsvwg@ietf.org; Tue, 24 May 2005 15:39:22 -0400 Received: from [192.168.1.15] (p508F530E.dip.t-dialin.net [80.143.83.14]) by ilsa.franken.de (Postfix) with ESMTP id D2F57245CD; Tue, 24 May 2005 21:20:20 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4292E7A6.6060001@axesb2.usa.alcatel.com> References: <4292E7A6.6060001@axesb2.usa.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing Date: Tue, 24 May 2005 21:20:18 +0200 To: bhanu X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi Bhanu, if you receive an HB-ACK without information you might have sent one... If not, I would just discard it. If you receive an empty HB you just send back an empty HB-ACK. Best regards Michael On May 24, 2005, at 10:36 AM, bhanu wrote: > Hai all.. > > When a Heartbeat or Heartbeat-Ack is received without any information, > what action need to be taken. > > Please clarify. > > Regards > Bhanu. > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 25 03:56:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16671 for ; Wed, 25 May 2005 03:56:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dar2q-0005BK-T9 for tsvwg-archive@ietf.org; Wed, 25 May 2005 04:15:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daqk4-0001VD-8U; Wed, 25 May 2005 03:55:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daqk2-0001V5-Kb for tsvwg@megatron.ietf.org; Wed, 25 May 2005 03:55:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16656 for ; Wed, 25 May 2005 03:55:49 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dar2L-0005Aa-0z for tsvwg@ietf.org; Wed, 25 May 2005 04:14:48 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4P7tXCR013502; Wed, 25 May 2005 02:55:35 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id NAA05646; Wed, 25 May 2005 13:15:11 -0500 (GMT) Message-ID: <429430AA.2000102@axesb2.usa.alcatel.com> Date: Wed, 25 May 2005 13:30:42 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing References: <4292E7A6.6060001@axesb2.usa.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Hai Michael Tuexen, But the RFC-2960 says Section: 8.3 Path Heartbeat The sender of the HEARTBEAT chunk should include in the Heartbeat Information field of the chunk the current time when the packet is sent out and the destination address to which the packet is sent. The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk. Please see my in-line comments. Michael Tuexen wrote: > Hi Bhanu, > > if you receive an HB-ACK without information you might have sent > one... If not, I would just discard it. If we are accepting the HB-ACK without information, what about Timer (RTO updation)...? and what about the retransmission counter..? > > If you receive an empty HB you just send back an empty HB-ACK. Is it OK to send ERROR with cause "MISSING MANDATORY PARAMETER". > > Best regards > Michael > > On May 24, 2005, at 10:36 AM, bhanu wrote: > >> Hai all.. >> >> When a Heartbeat or Heartbeat-Ack is received without any information, >> what action need to be taken. >> >> Please clarify. >> >> Regards >> Bhanu. >> >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > > Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 25 04:24:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18343 for ; Wed, 25 May 2005 04:24:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DarTz-0005nd-9M for tsvwg-archive@ietf.org; Wed, 25 May 2005 04:43:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dar8l-0006J9-3n; Wed, 25 May 2005 04:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dar8k-0006Iq-1U for tsvwg@megatron.ietf.org; Wed, 25 May 2005 04:21:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18035 for ; Wed, 25 May 2005 04:21:20 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[Vovp/UlQ/8Ly7U6r/ctrTwArNfMly6CG]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DarR4-0005he-Q7 for tsvwg@ietf.org; Wed, 25 May 2005 04:40:20 -0400 Received: from ns.pigworks.openss7.net (IDENT:31n29YJLK75scIQf4tmun0C6G4BfsfJl@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id j4P8LEQ30274; Wed, 25 May 2005 02:21:14 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id j4P8LDf22846; Wed, 25 May 2005 02:21:13 -0600 Date: Wed, 25 May 2005 02:21:13 -0600 From: "Brian F. G. Bidulock" To: bhanu Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing Message-ID: <20050525022113.A22785@openss7.org> References: <4292E7A6.6060001@axesb2.usa.alcatel.com> <429430AA.2000102@axesb2.usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <429430AA.2000102@axesb2.usa.alcatel.com>; from bprakash@axesb2.usa.alcatel.com on Wed, May 25, 2005 at 01:30:42PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id j4P8LEQ30274 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: Michael Tuexen , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable bhanu, Well, the passage says "should" and not "must". I agree with Michael: unexpected HB-ACK can be discarded. Also, HB is normally responded to with HB-ACK containing whatever was included (or not) in the original heartbeat. There are a few exceptions: in some states neither will be accepted; and in some states, different procedures apply depending on things like vtags and IP addresses; but, in the established state, all other things being equal and correct, what Michael describes is IMO appropriate. --brian On Wed, 25 May 2005, bhanu wrote: >=20 > Hai Michael Tuexen, >=20 > But the RFC-2960 says >=20 > Section: > 8.3 Path Heartbeat >=20 > The sender of the HEARTBEAT chunk should include in the Heartbeat > Information field of the chunk the current time when the packet is > sent out and the destination address to which the packet is sent. >=20 > The receiver of the HEARTBEAT should immediately respond with a > HEARTBEAT ACK that contains the Heartbeat Information field copied > from the received HEARTBEAT chunk. >=20 >=20 > Please see my in-line comments. >=20 >=20 > Michael Tuexen wrote: >=20 > > Hi Bhanu, > > > > if you receive an HB-ACK without information you might have sent > > one... If not, I would just discard it. >=20 > If we are accepting the HB-ACK without information, what about Timer=20 > (RTO updation)...? > and what about the retransmission counter..? >=20 > > > > If you receive an empty HB you just send back an empty HB-ACK. >=20 > Is it OK to send ERROR with cause "MISSING MANDATORY PARAMETER". >=20 > > > > Best regards > > Michael > > > > On May 24, 2005, at 10:36 AM, bhanu wrote: > > > >> Hai all.. > >> > >> When a Heartbeat or Heartbeat-Ack is received without any informatio= n, > >> what action need to be taken. > >> > >> Please clarify. > >> > >> Regards > >> Bhanu. > >> > >> > >> _______________________________________________ > >> tsvwg mailing list > >> tsvwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/tsvwg > >> > >> > > > > > > > Regards > Bhanu. >=20 >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 25 04:55:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19963 for ; Wed, 25 May 2005 04:55:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daryd-0006gp-S5 for tsvwg-archive@ietf.org; Wed, 25 May 2005 05:15:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DarfQ-0003RY-Qm; Wed, 25 May 2005 04:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DarfP-0003RT-Dg for tsvwg@megatron.ietf.org; Wed, 25 May 2005 04:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19936 for ; Wed, 25 May 2005 04:55:05 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Darxk-0006fu-FR for tsvwg@ietf.org; Wed, 25 May 2005 05:14:05 -0400 Received: from [192.168.1.15] (p508F4AF2.dip.t-dialin.net [80.143.74.242]) by ilsa.franken.de (Postfix) with ESMTP id 66028245D2; Wed, 25 May 2005 10:54:56 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <429430AA.2000102@axesb2.usa.alcatel.com> References: <4292E7A6.6060001@axesb2.usa.alcatel.com> <429430AA.2000102@axesb2.usa.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D80CF2F-537F-4938-A669-DBFBBBB99E30@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing Date: Wed, 25 May 2005 10:54:54 +0200 To: bhanu X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Bhanu, I would implement the processing of a received HEARTBEAT by just changing the type the HEARTBEAT-ACK and send it out again. No checking. Not looking into the structure of the chunk value. When I receive a HEARTBEAT-ACK I expect it of a certain structure. I would do some checking and accept it if it passes the checks. If not, I would just discard it and continue processing as if I had never received it (including incrementing the error counters). I'm not sure about the ERROR. You can send it, but does it help? I do not think so. If the HEARTBEAT-ACK comes modified from a peer, he is broken or attacking you. So would he act on the ERROR? Best regards Michael On May 25, 2005, at 10:00 AM, bhanu wrote: > > Hai Michael Tuexen, > > But the RFC-2960 says > > Section: > 8.3 Path Heartbeat > > The sender of the HEARTBEAT chunk should include in the Heartbeat > Information field of the chunk the current time when the packet is > sent out and the destination address to which the packet is sent. > > The receiver of the HEARTBEAT should immediately respond with a > HEARTBEAT ACK that contains the Heartbeat Information field copied > from the received HEARTBEAT chunk. > > > Please see my in-line comments. > > > Michael Tuexen wrote: > > >> Hi Bhanu, >> >> if you receive an HB-ACK without information you might have sent >> one... If not, I would just discard it. >> > > If we are accepting the HB-ACK without information, what about > Timer (RTO updation)...? > and what about the retransmission counter..? > > >> >> If you receive an empty HB you just send back an empty HB-ACK. >> > > Is it OK to send ERROR with cause "MISSING MANDATORY PARAMETER". > > >> >> Best regards >> Michael >> >> On May 24, 2005, at 10:36 AM, bhanu wrote: >> >> >>> Hai all.. >>> >>> When a Heartbeat or Heartbeat-Ack is received without any >>> information, >>> what action need to be taken. >>> >>> Please clarify. >>> >>> Regards >>> Bhanu. >>> >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >>> >> >> >> >> > Regards > Bhanu. > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu May 26 07:30:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20915 for ; Thu, 26 May 2005 07:30:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbGra-0006bm-Nn for tsvwg-archive@ietf.org; Thu, 26 May 2005 07:49:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbGYH-0001SI-Fs; Thu, 26 May 2005 07:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbGYF-0001Rh-4H for tsvwg@megatron.ietf.org; Thu, 26 May 2005 07:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20838 for ; Thu, 26 May 2005 07:29:21 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbGqm-0006as-Sb for tsvwg@ietf.org; Thu, 26 May 2005 07:48:35 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4QBT5CR009847; Thu, 26 May 2005 06:29:07 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id QAA07656; Thu, 26 May 2005 16:48:42 -0500 (GMT) Message-ID: <4295B436.3080907@axesb2.usa.alcatel.com> Date: Thu, 26 May 2005 17:04:14 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing References: <4292E7A6.6060001@axesb2.usa.alcatel.com> <429430AA.2000102@axesb2.usa.alcatel.com> <9D80CF2F-537F-4938-A669-DBFBBBB99E30@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: "Brian F. G. Bidulock" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Hi It was a useful information. I need some clarification on following: (1) If an ERROR chunk is received with a invalid cause length, what action need to be taken..? and what about the other bundled chunks, if present..? ( in this case the chunk length might be correct, otherwise next chunk cannot be extracted). (2) If an Un-recognized chunk is received with highest-order two bits specifying: 10 - Skip this chunk and continue processing. what about the other bundled chunks, if present..? should we consider chunk length as correct and extract next chunk..? Please clarify. Regards Bhanu. Michael Tuexen wrote: > Hi Bhanu, > > I would implement the processing of a received HEARTBEAT by just > changing the > type the HEARTBEAT-ACK and send it out again. No checking. Not > looking into > the structure of the chunk value. > > When I receive a HEARTBEAT-ACK I expect it of a certain structure. I > would > do some checking and accept it if it passes the checks. If not, I > would just > discard it and continue processing as if I had never received it > (including > incrementing the error counters). I'm not sure about the ERROR. You > can send > it, but does it help? I do not think so. If the HEARTBEAT-ACK comes > modified > from a peer, he is broken or attacking you. So would he act on the > ERROR? > > Best regards > Michael > > On May 25, 2005, at 10:00 AM, bhanu wrote: > >> >> Hai Michael Tuexen, >> >> But the RFC-2960 says >> >> Section: >> 8.3 Path Heartbeat >> >> The sender of the HEARTBEAT chunk should include in the Heartbeat >> Information field of the chunk the current time when the packet is >> sent out and the destination address to which the packet is sent. >> >> The receiver of the HEARTBEAT should immediately respond with a >> HEARTBEAT ACK that contains the Heartbeat Information field copied >> from the received HEARTBEAT chunk. >> >> >> Please see my in-line comments. >> >> >> Michael Tuexen wrote: >> >> >>> Hi Bhanu, >>> >>> if you receive an HB-ACK without information you might have sent >>> one... If not, I would just discard it. >>> >> >> If we are accepting the HB-ACK without information, what about Timer >> (RTO updation)...? >> and what about the retransmission counter..? >> >> >>> >>> If you receive an empty HB you just send back an empty HB-ACK. >>> >> >> Is it OK to send ERROR with cause "MISSING MANDATORY PARAMETER". >> >> >>> >>> Best regards >>> Michael >>> >>> On May 24, 2005, at 10:36 AM, bhanu wrote: >>> >>> >>>> Hai all.. >>>> >>>> When a Heartbeat or Heartbeat-Ack is received without any >>>> information, >>>> what action need to be taken. >>>> >>>> Please clarify. >>>> >>>> Regards >>>> Bhanu. >>>> >>>> >>>> _______________________________________________ >>>> tsvwg mailing list >>>> tsvwg@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/tsvwg >>>> >>>> >>>> >>> >>> >>> >>> >> Regards >> Bhanu. >> >> >> > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu May 26 11:17:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05758 for ; Thu, 26 May 2005 11:17:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKPQ-0003JP-0K for tsvwg-archive@ietf.org; Thu, 26 May 2005 11:36:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbK5l-0005Dd-L4; Thu, 26 May 2005 11:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbK5j-0005DY-JK for tsvwg@megatron.ietf.org; Thu, 26 May 2005 11:16:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05647 for ; Thu, 26 May 2005 11:16:09 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbKOL-0003Hc-Od for tsvwg@ietf.org; Thu, 26 May 2005 11:35:26 -0400 Received: from [192.168.1.10] (p508F4A35.dip.t-dialin.net [80.143.74.53]) by ilsa.franken.de (Postfix) with ESMTP id 58F8D245E2; Thu, 26 May 2005 17:16:03 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <4295B436.3080907@axesb2.usa.alcatel.com> References: <4292E7A6.6060001@axesb2.usa.alcatel.com> <429430AA.2000102@axesb2.usa.alcatel.com> <9D80CF2F-537F-4938-A669-DBFBBBB99E30@lurchi.franken.de> <4295B436.3080907@axesb2.usa.alcatel.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <571EACF9-B5DA-4963-97CB-A9D8623159AF@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP - HB/HB-ack processing Date: Thu, 26 May 2005 17:16:01 +0200 To: bhanu X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: "Brian F. G. Bidulock" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Hi Bhanu, see my comments in-line. Best regards Michael On May 26, 2005, at 1:34 PM, bhanu wrote: > > Hi > It was a useful information. > I need some clarification on following: > > (1) > If an ERROR chunk is received with a invalid cause length, what > action need to be taken..? > and what about the other bundled chunks, if present..? > ( in this case the chunk length might be correct, otherwise next > chunk cannot be extracted). I would not process the ERROR chunk and continue processing the next chunk. If you send an ERROR is up to you. I do not think the receiver will do anything with it, but if is shows up in a message trace someone might look at it and fix the bug. On the other hand this might end up in an ERROR ping-pong exchange, because if the sender sends wrong packets he might consider correct ones to be bad. So I would not send back an ERROR... > > (2) > If an Un-recognized chunk is received with highest-order two bits > specifying: > 10 - Skip this chunk and continue processing. > what about the other bundled chunks, if present..? > should we consider chunk length as correct and extract next chunk..? Yes, the length is considered correct and you just continue processing the next chunk. > > Please clarify. > > Regards > Bhanu. > > > > Michael Tuexen wrote: > > >> Hi Bhanu, >> >> I would implement the processing of a received HEARTBEAT by just >> changing the >> type the HEARTBEAT-ACK and send it out again. No checking. Not >> looking into >> the structure of the chunk value. >> >> When I receive a HEARTBEAT-ACK I expect it of a certain structure. >> I would >> do some checking and accept it if it passes the checks. If not, I >> would just >> discard it and continue processing as if I had never received it >> (including >> incrementing the error counters). I'm not sure about the ERROR. >> You can send >> it, but does it help? I do not think so. If the HEARTBEAT-ACK >> comes modified >> from a peer, he is broken or attacking you. So would he act on >> the ERROR? >> >> Best regards >> Michael >> >> On May 25, 2005, at 10:00 AM, bhanu wrote: >> >> >>> >>> Hai Michael Tuexen, >>> >>> But the RFC-2960 says >>> >>> Section: >>> 8.3 Path Heartbeat >>> >>> The sender of the HEARTBEAT chunk should include in the Heartbeat >>> Information field of the chunk the current time when the >>> packet is >>> sent out and the destination address to which the packet is sent. >>> >>> The receiver of the HEARTBEAT should immediately respond with a >>> HEARTBEAT ACK that contains the Heartbeat Information field >>> copied >>> from the received HEARTBEAT chunk. >>> >>> >>> Please see my in-line comments. >>> >>> >>> Michael Tuexen wrote: >>> >>> >>> >>>> Hi Bhanu, >>>> >>>> if you receive an HB-ACK without information you might have sent >>>> one... If not, I would just discard it. >>>> >>>> >>> >>> If we are accepting the HB-ACK without information, what about >>> Timer (RTO updation)...? >>> and what about the retransmission counter..? >>> >>> >>> >>>> >>>> If you receive an empty HB you just send back an empty HB-ACK. >>>> >>>> >>> >>> Is it OK to send ERROR with cause "MISSING MANDATORY PARAMETER". >>> >>> >>> >>>> >>>> Best regards >>>> Michael >>>> >>>> On May 24, 2005, at 10:36 AM, bhanu wrote: >>>> >>>> >>>> >>>>> Hai all.. >>>>> >>>>> When a Heartbeat or Heartbeat-Ack is received without any >>>>> information, >>>>> what action need to be taken. >>>>> >>>>> Please clarify. >>>>> >>>>> Regards >>>>> Bhanu. >>>>> >>>>> >>>>> _______________________________________________ >>>>> tsvwg mailing list >>>>> tsvwg@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/tsvwg >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> Regards >>> Bhanu. >>> >>> >>> >>> >> >> >> >> > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu May 26 23:20:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09500 for ; Thu, 26 May 2005 23:20:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbVht-0006tS-1u for tsvwg-archive@ietf.org; Thu, 26 May 2005 23:40:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbVMZ-0008I8-G9; Thu, 26 May 2005 23:18:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaUBq-0007h1-Qu; Tue, 24 May 2005 03:51:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04808; Tue, 24 May 2005 03:51:01 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaUTy-0008IT-Pv; Tue, 24 May 2005 04:09:48 -0400 Received: from axesb2.ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j4O7onCR017370; Tue, 24 May 2005 02:50:50 -0500 (CDT) Received: from axesb2.usa.alcatel.com by axesb2.ssd.usa.alcatel.com (8.8.8+Sun/SMI-SVR4) id NAA04009; Tue, 24 May 2005 13:10:28 -0500 (GMT) Message-ID: <4292DE0E.4010203@axesb2.usa.alcatel.com> Date: Tue, 24 May 2005 13:25:58 +0530 From: bhanu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 May 2005 23:18:18 -0400 Subject: [Tsvwg] SCTP - HB/HB-ack processing X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hai all.. When a Heartbeat or Heartbeat-Ack is received without any information, what action need to be taken. Please clarify. Regards Bhanu. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri May 27 09:46:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11467 for ; Fri, 27 May 2005 09:46:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfT2-0003OD-Kn for tsvwg-archive@ietf.org; Fri, 27 May 2005 10:05:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf9V-00035p-OS; Fri, 27 May 2005 09:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbf9T-00035K-SH; Fri, 27 May 2005 09:45:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11440; Fri, 27 May 2005 09:45:26 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbfSG-0003NH-PQ; Fri, 27 May 2005 10:04:54 -0400 Received: from [192.168.1.10] (p508F59FC.dip.t-dialin.net [80.143.89.252]) by ilsa.franken.de (Postfix) with ESMTP id AA85C245D3; Fri, 27 May 2005 15:45:21 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B2C2887-A2B7-434B-8F94-4577B66315F8@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Fri, 27 May 2005 15:45:21 +0200 To: sigtran@ietf.org X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: [Tsvwg] SIGTRAN Interop X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Dear all, we would like to let you know that it is planned to hold an SIGTRAN interop at ETSI in Sofia Antipolis, France on September 12-16th. In addition to the possibility to test all SIGTRAN adaptation layer there is the possibility that France Telecom provides an emulation of E1 interface with SS7 network emulation such that participants with the capability of connecting their equipment to an SS7 network can make use of it. It seems also that there will be several participants with testtools for SIGTRAN which can generate packet sequences including conformance test suites. To progress preparation of the Interop we would like to know: - Who is interested to attend that Interop? - Which protocols would you like to test? - Do you want to use the SS7 connectivity to the network emulator? - How would you like to use of the SS7 network emulation? Please send your answer to kmorneau@cisco.com and tuexen@fh- muenster.de. Please note that this feedback is for information only and is not a registration for that event. Best regards Ken and Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg