From exim@www1.ietf.org Sat Nov 1 07:25:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05114 for ; Sat, 1 Nov 2003 07:25:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFuoW-0005jE-VF for tsvwg-archive@odin.ietf.org; Sat, 01 Nov 2003 07:25:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1CP80B022016 for tsvwg-archive@odin.ietf.org; Sat, 1 Nov 2003 07:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFuoR-0005iC-7u; Sat, 01 Nov 2003 07:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFunU-0005hW-9E for tsvwg@optimus.ietf.org; Sat, 01 Nov 2003 07:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05079 for ; Sat, 1 Nov 2003 07:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFunT-0000kj-00 for tsvwg@ietf.org; Sat, 01 Nov 2003 07:24:03 -0500 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1AFunT-0000kB-00 for tsvwg@ietf.org; Sat, 01 Nov 2003 07:24:03 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id hA1CMu4j027292; Sat, 1 Nov 2003 06:22:56 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FA3A59D.2070401@stewart.chicago.il.us> Date: Sat, 01 Nov 2003 06:22:53 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hanping Long CC: lksctp-developers@lists.sourceforge.net, tsvwg@ietf.org Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hanping Long wrote: >Hi, > >Regarding the one-to-many(UDP style) and one-to-one(tcp style) socket >interface in socket API, one-to-many is more effiencient in terms of >exploring the new features of SCTP, can anyone tell me which feature that >one-to-one style interface CANNOT make use of? > > > The big issue (at least I know in KAME-BSD) is that a one-to-one style socket is not allowed to send data until the connect() or accept() as completed. This translates into not being able to piggyback data on the third or fourth leg of the 4-way handshake. The one-to-many uses implicit connection setup so that when you do a send(data, new-addr); it will start the connection setup and piggyback the data with the cookie-echo. At one time there were other features that could not be used by the one-to-one style. But I think for the most mart Kacheong as done a good job of finding ways to make them all work ;-> >Though each association could have its dedicated buffer space for >one-to-many style API, all the associations will fail if their related >socket fails. But if one socket fails for one-to-one style API, only one >association will fail. Is this the benefit of one-to-one style API? or it's >not possible in reality? > > What in the world is a "socket fails" .. There is no such thing. You either allocate a socket up front with a sd = socket(...); or it just does not work. Once the socket is open the resources are dedicated and I don't see how it could "fail"... if you might give me an example of what you have in mind I might understand what you are driving at.. but I know from the BSD work in KAME that once I have a socket open.. the socket itself has nothing in it that can fail.. maybe linux is different.. I don't know... >But for one-to-one style, the maximum number of associations is limited by >the number of socket the specific OS allows to open, as well as the select() >call could handle(the value of FD_SETSIZE). > > > Well this is true. In a typical BSD system the max sockets is somewhere around 8000. Of course there is almost always a "MAX ASSOC" variable as well.. we have it in BSD.. (not sure what the default is but I have had it up to 20,000 before and brought up 20k assoc)... But back to your point... if max_socket > max_assoc you have no issue.. however if max_assoc > max_socket (likely) then yep ..what you say above is true. Select would get in the way if you had a lot of assoc in the one-to-one catagory.. but there is something to remember about select and a one-to-many style socket. 1) If you are doing a select for reading when it returns true one of the associations is ready to read from.... not a specific one but one of them. 2) If you are doing a slect for writing its even more strange :-0 since most likely one of the associations under the socket can be written so it will almost always return true.. however if you want to write a specific association it might block (if you don't have non-blocking io set) since it might not have been the assoc that the select call said was writeable :-0 Basically select for write just does not work right for the one-to-many you almost have to do non-blocking io and get the error (EAGAIN) and then go forward from there... If you really need to do a select for write on a specific assoc you might have to peel it off with sctp_peeloff into a one-to-one type socket... if theres room :-> R >Any suggestion or idea is highly appreciated! > >hanping > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Nov 1 10:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07551 for ; Sat, 1 Nov 2003 10:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFxIK-00060w-2T for tsvwg-archive@odin.ietf.org; Sat, 01 Nov 2003 10:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA1F44si023110 for tsvwg-archive@odin.ietf.org; Sat, 1 Nov 2003 10:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFxIG-0005zY-TS; Sat, 01 Nov 2003 10:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFxHL-0005wt-Iv for tsvwg@optimus.ietf.org; Sat, 01 Nov 2003 10:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07433 for ; Sat, 1 Nov 2003 10:02:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFxHJ-00023n-00 for tsvwg@ietf.org; Sat, 01 Nov 2003 10:03:01 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AFxHI-00023d-00 for tsvwg@ietf.org; Sat, 01 Nov 2003 10:03:00 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA1F2TIw374692; Sat, 1 Nov 2003 10:02:29 -0500 Received: from w-sridhar.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA1F2SBS156518; Sat, 1 Nov 2003 08:02:28 -0700 Date: Sat, 1 Nov 2003 07:02:27 -0800 (PST) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: "Randall R. Stewart (home)" cc: Hanping Long , , Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP In-Reply-To: <3FA3A59D.2070401@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Sat, 1 Nov 2003, Randall R. Stewart (home) wrote: > Hanping Long wrote: > > >Hi, > > > >Regarding the one-to-many(UDP style) and one-to-one(tcp style) socket > >interface in socket API, one-to-many is more effiencient in terms of > >exploring the new features of SCTP, can anyone tell me which feature that > >one-to-one style interface CANNOT make use of? > > > > > > > The big issue (at least I know in KAME-BSD) is that a one-to-one style > socket is not allowed to send data until the connect() or accept() as > completed. This translates into not being able to piggyback data on > the third or fourth leg of the 4-way handshake. The one-to-many uses > implicit connection setup so that when you do a send(data, new-addr); it > will start the connection setup and piggyback the data with the cookie-echo. In LKSCTP it is possible to do auto connect using sendto()/sendmsg() which allows bundling of data with cookie-echo. > > At one time there were other features that could not be used by the > one-to-one style. But > I think for the most mart Kacheong as done a good job of finding ways to > make them > all work ;-> I can think of only one socket option that applies only to one-to-many style sockets - SCTP_AUTOCLOSE. > > >Though each association could have its dedicated buffer space for > >one-to-many style API, all the associations will fail if their related > >socket fails. But if one socket fails for one-to-one style API, only one > >association will fail. Is this the benefit of one-to-one style API? or it's > >not possible in reality? > > > > > What in the world is a "socket fails" .. There is no such thing. You > either allocate > a socket up front with a > sd = socket(...); > or it just does not work. Once the socket is open the resources are > dedicated and > I don't see how it could "fail"... if you might give me an example of > what you > have in mind I might understand what you are driving at.. but I know from > the BSD work in KAME that once I have a socket open.. the socket itself > has nothing in it that can fail.. maybe linux is different.. I don't know... Hanping may have meant the failure of the process/thread owning the socket as "socket fails". > > >But for one-to-one style, the maximum number of associations is limited by > >the number of socket the specific OS allows to open, as well as the select() > >call could handle(the value of FD_SETSIZE). Yes, there are these limits, but it is possible to increase at least the open file limit at runtime using 'ulimit -n'. We don't have a limit on the no. of associations per socket(one-to-many) in LKSCTP. I guess we should have it as a configurable parameter. Also 2.6 Linux is going to support a more scalable event polling mechanism than poll or select called epoll. http://lse.sourceforge.net/epoll I haven't tried out this mechanism with SCTP sockets on linux, but hopefully it should work. > > > > > > > Well this is true. In a typical BSD system the max sockets is somewhere > around > 8000. Of course there is almost always a "MAX ASSOC" variable as well.. we > have it in BSD.. (not sure what the default is but I have had it up to > 20,000 before > and brought up 20k assoc)... But back to your point... if max_socket > > max_assoc > you have no issue.. however if max_assoc > max_socket (likely) then yep > ..what > you say above is true. > > Select would get in the way if you had a lot of assoc in the one-to-one > catagory.. but > there is something to remember about select and a one-to-many style socket. > > 1) If you are doing a select for reading when it returns true one of the > associations is ready to read from.... not a specific one but one of > them. > > 2) If you are doing a slect for writing its even more strange :-0 since most > likely one of the associations under the socket can be written so it > will > almost always return true.. however if you want to write a specific > association it might block (if you don't have non-blocking io set) since > it might not have been the assoc that the select call said was > writeable :-0 > Basically select for write just does not work right for the > one-to-many you > almost have to do non-blocking io and get the error (EAGAIN) and then > go forward from there... If you really need to do a select for write > on a > specific assoc you might have to peel it off with sctp_peeloff into a > one-to-one type socket... if theres room :-> > > R > > >Any suggestion or idea is highly appreciated! > > > >hanping > > > > > > > >_______________________________________________ > >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 exim@www1.ietf.org Sun Nov 2 00:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24684 for ; Sun, 2 Nov 2003 00:10:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAV8-0005UB-Ox for tsvwg-archive@odin.ietf.org; Sun, 02 Nov 2003 00:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA25AAmf021006 for tsvwg-archive@odin.ietf.org; Sun, 2 Nov 2003 00:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAV0-0005Se-Sy; Sun, 02 Nov 2003 00:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbth-0000HM-Nf for tsvwg@optimus.ietf.org; Fri, 31 Oct 2003 11:13:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05322 for ; Fri, 31 Oct 2003 11:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbtg-0002Pn-00 for tsvwg@ietf.org; Fri, 31 Oct 2003 11:13:12 -0500 Received: from bay2-f54.bay2.hotmail.com ([65.54.247.54] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AFbtg-0002PQ-00 for tsvwg@ietf.org; Fri, 31 Oct 2003 11:13:12 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 31 Oct 2003 08:12:41 -0800 Received: from 128.107.253.42 by by2fd.bay2.hotmail.msn.com with HTTP; Fri, 31 Oct 2003 16:12:40 GMT X-Originating-IP: [128.107.253.42] X-Originating-Email: [vdang3@hotmail.com] From: "Van Dang" To: tsvwg@ietf.org Date: Fri, 31 Oct 2003 08:12:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2003 16:12:41.0153 (UTC) FILETIME=[CF4ABB10:01C39FC9] Subject: [Tsvwg] minimum TCP MSS Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Does any one know the minimum MSS that TCP must support. I think most TCP implementation, without Path MTU Discovery, would use the outgoing interface MTU to calculate the MSS if the destination is local. If destination is remote, then use the default MSS. However, some host may try a smaller MSS even if locally connected. So I was wondering what does TCP must support in order to be compliant with RFC. It would be great if someone knows this answer. It would save me some time from scanning through the RFCs. Thanks. _________________________________________________________________ Never get a busy signal because you are always connected with high-speed Internet access. Click here to comparison-shop providers. https://broadband.msn.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Nov 2 00:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24696 for ; Sun, 2 Nov 2003 00:10:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAV8-0005UA-Ok for tsvwg-archive@odin.ietf.org; Sun, 02 Nov 2003 00:10:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA25AARY021009 for tsvwg-archive@odin.ietf.org; Sun, 2 Nov 2003 00:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAV0-0005ST-Cy; Sun, 02 Nov 2003 00:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFXTu-0007Dl-HF for tsvwg@optimus.ietf.org; Fri, 31 Oct 2003 06:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21963 for ; Fri, 31 Oct 2003 06:30:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFXTq-00063N-00 for tsvwg@ietf.org; Fri, 31 Oct 2003 06:30:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFXTp-00061U-00 for tsvwg@ietf.org; Fri, 31 Oct 2003 06:30:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9VBTa604793; Fri, 31 Oct 2003 13:29:37 +0200 Date: Fri, 31 Oct 2003 13:29:36 +0200 (EET) From: Pekka Savola To: Bill Sommerfeld cc: tsvwg@ietf.org, In-Reply-To: <200310302122.h9ULMiS4000324@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] Re: TCP and ICMP soft-errors in IPv4/6 environments Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 30 Oct 2003, Bill Sommerfeld wrote: > > Has this been discussed in the transport area? Is there something to be > > done about this, e.g. a BCP document discussing this practice and > > suggesting ICMP DU's are OK when establishing connections -- or something > > else? > > Maybe the right answer here is a "slewed parallel" connection > establishment; start with one address, and if you get a soft error or > a RTO-sized timeout, try a second, third, fourth, etc., connection, > but leave the prior ones open in the event they complete successfully. > > Soft errors wouldn't kill the first connection -- they'd just be a a > hint to try another connection in parallel. > > This should probably be buried in a library routine so that > applications don't have to reinvent this wheel. This is probably an obvious first thought, as what would be the desirable behaviour. But what would that imply in practice? That at least some parts of the basic API functions like connect() be augmented by a set of new functions for managing connectivity? That could be a forever-project, while what we'd like is to get a fix that'd be usable in this decade :-). I'm not saying that's not a probably relevant option to consider, but I think folks have been thinking about replacing APIs before and not much has come out of it.. so I'm a bit reluctant to start on that particular path... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sun Nov 2 00:17:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24771 for ; Sun, 2 Nov 2003 00:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAbm-0005sl-Gu for tsvwg-archive@odin.ietf.org; Sun, 02 Nov 2003 00:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA25H2LC022577 for tsvwg-archive@odin.ietf.org; Sun, 2 Nov 2003 00:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAbl-0005rK-FJ; Sun, 02 Nov 2003 00:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGAbN-0005r9-3Z for tsvwg@optimus.ietf.org; Sun, 02 Nov 2003 00:16:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24756 for ; Sun, 2 Nov 2003 00:16:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGAbK-0001zN-00 for tsvwg@ietf.org; Sun, 02 Nov 2003 00:16:34 -0500 Received: from gw.openss7.com ([142.179.199.224] ident=[QsiYtQSezxifAvkJEQ8rkA/DREoWI+u3]) by ietf-mx with esmtp (Exim 4.12) id 1AGAbI-0001zK-00 for tsvwg@ietf.org; Sun, 02 Nov 2003 00:16:32 -0500 Received: from ns.pigworks.openss7.net (IDENT:IujJMcDggfjWgTedMWG02kVoQaCYeZ+4@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id hA25GTa16034; Sat, 1 Nov 2003 22:16:29 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id hA25GSk18737; Sat, 1 Nov 2003 22:16:28 -0700 Date: Sat, 1 Nov 2003 22:16:28 -0700 From: "Brian F. G. Bidulock" To: Van Dang Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] minimum TCP MSS Message-ID: <20031101221628.A18706@openss7.org> Reply-To: bidulock@openss7.org References: 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: ; from vdang3@hotmail.com on Fri, Oct 31, 2003 at 08:12:40AM -0800 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 hA25GTa16034 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Van, 536. --brian On Fri, 31 Oct 2003, Van Dang wrote: > Does any one know the minimum MSS that TCP must support. > I think most TCP implementation, without Path MTU Discovery, > would use the outgoing interface MTU to calculate the MSS > if the destination is local. If destination is remote, then use the > default MSS. However, some host may try a smaller MSS even > if locally connected. So I was wondering what does TCP must > support in order to be compliant with RFC. >=20 > It would be great if someone knows this answer. It would save > me some time from scanning through the RFCs. >=20 > Thanks. >=20 > _________________________________________________________________ > Never get a busy signal because you are always connected with high-spe= ed=20 > Internet access. Click here to comparison-shop providers. =20 > https://broadband.msn.com >=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 exim@www1.ietf.org Mon Nov 3 16:42:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23171 for ; Mon, 3 Nov 2003 16:42:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmSa-0000VN-DA for tsvwg-archive@odin.ietf.org; Mon, 03 Nov 2003 16:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Lg4dN001909 for tsvwg-archive@odin.ietf.org; Mon, 3 Nov 2003 16:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmSX-0000U9-MC; Mon, 03 Nov 2003 16:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGmRg-0000Rg-Uj for tsvwg@optimus.ietf.org; Mon, 03 Nov 2003 16:41:08 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23098 for ; Mon, 3 Nov 2003 16:40:57 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AGm7I-0002ri-Ew; Mon, 03 Nov 2003 16:20:04 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 03 Nov 2003 16:20:04 -0500 Subject: [Tsvwg] Document Action: 'Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions' to Experimental RFC Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions ' as an Experimental RFC This document is the product of the Transport Area Working Group Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary TCP and SCTP provide notification of duplicate segment receipt through DSACK and Duplicate TSN notification, respectively. This document shows conservative methods of using this information to identify unnecessary retransmissions for various applications. This document does not, however outline what a TCP or SCTP sender should do after a spurious retransmission is detected. It is hoped that future work building on the detection of spurious transmissions will make TCP and SCTP more robust to reordererd packets. Working Group Summary The TSVWG supports this protocol going forward, and is investigating several proposals that rely on the detection of spurious retransmissions which might benefit from this work. Protocol Quality This document was reviewed for the IESG by Allison Mankin and Jon Peterson. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 3 17:50:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00415 for ; Mon, 3 Nov 2003 17:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnWO-0007In-NB for tsvwg-archive@odin.ietf.org; Mon, 03 Nov 2003 17:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3Mo4NB028030 for tsvwg-archive@odin.ietf.org; Mon, 3 Nov 2003 17:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGnWM-0007Hm-CB; Mon, 03 Nov 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGjAc-00056b-Cb for tsvwg@optimus.ietf.org; Mon, 03 Nov 2003 13:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13044 for ; Mon, 3 Nov 2003 13:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGjAa-0001v2-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 13:11:16 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AGjAZ-0001uz-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 13:11:15 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id 564C11C00D01 for ; Mon, 3 Nov 2003 10:11:12 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.9.3 SMKit7.02) with ESMTP id KAA24500 for ; Mon, 3 Nov 2003 10:11:12 -0800 (PST) Message-ID: <3FA69A3F.6A5406CB@hp.com> Date: Mon, 03 Nov 2003 10:11:11 -0800 From: Rick Jones Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] minimum TCP MSS References: <20031101221628.A18706@openss7.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It is my understanding that there is no minimum MSS specified for TCP (well, one byte is perhaps implicit in TCP being a byte stream rather than a bit stream...), although some TCP _implementations_ may have settings to reject connections advertising an MSS less than some value. Again, unless I am getting beyond my knowledge, 536 is the _default_ MSS - the MSS that TCP should assume when it does not send or see an MSS option in the SYN or SYN|ACK segment. I _suspect_ but cannot quote chapter and verse to confirm, that 536 stems from the requirement that a conforming IP stack must be able to reassemble IP datagram fragments into IP datagrams of at least 576 bytes. That is the "minimum, maximum IP datagram size" an IP stack must support, not a minimum MTU. (IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6) If TCP "knows" that the "minimum, maximum IP datagram size" is 576, then it "knows" that using an MSS of 536 (576 less 20 bytes of TCP header and 20 bytes of IP header, options may vary :) means that its traffic has at least a snowball's chance of getting through. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 3 18:30:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03349 for ; Mon, 3 Nov 2003 18:30:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo97-000144-Tu for tsvwg-archive@odin.ietf.org; Mon, 03 Nov 2003 18:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3NU5tH004064 for tsvwg-archive@odin.ietf.org; Mon, 3 Nov 2003 18:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo94-00012h-46; Mon, 03 Nov 2003 18:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo8X-000121-5l for tsvwg@optimus.ietf.org; Mon, 03 Nov 2003 18:29:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03327 for ; Mon, 3 Nov 2003 18:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGo8U-0000Uj-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 18:29:26 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1AGo8T-0000Ug-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 18:29:25 -0500 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hA3NTJa27175; Mon, 3 Nov 2003 15:29:19 -0800 (PST) Message-ID: <3FA6E4D4.8070206@isi.edu> Date: Mon, 03 Nov 2003 15:29:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Jones CC: tsvwg@ietf.org Subject: Re: [Tsvwg] minimum TCP MSS References: <20031101221628.A18706@openss7.org> <3FA69A3F.6A5406CB@hp.com> In-Reply-To: <3FA69A3F.6A5406CB@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rick Jones wrote: > It is my understanding that there is no minimum MSS specified for TCP (well, one > byte is perhaps implicit in TCP being a byte stream rather than a bit > stream...), although some TCP _implementations_ may have settings to reject > connections advertising an MSS less than some value. > > Again, unless I am getting beyond my knowledge, 536 is the _default_ MSS - the > MSS that TCP should assume when it does not send or see an MSS option in the SYN > or SYN|ACK segment. > > I _suspect_ but cannot quote chapter and verse to confirm, that 536 stems from > the requirement that a conforming IP stack must be able to reassemble IP > datagram fragments into IP datagrams of at least 576 bytes. That is the > "minimum, maximum IP datagram size" an IP stack must support, not a minimum MTU. > (IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6) > > If TCP "knows" that the "minimum, maximum IP datagram size" is 576, then it > "knows" that using an MSS of 536 (576 less 20 bytes of TCP header and 20 bytes > of IP header, options may vary :) means that its traffic has at least a > snowball's chance of getting through. > > rick jones MSS = Maximum segment size. TCP's max-min is based on IP's, as noted before. There is no min segment size - TCP can, and does, send 0-length segments (though it wouldn't be productive if that's all it could send). That would mean a min overall packet of 40 bytes, but a 0-length TCP payload. Joe _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 3 22:45:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12624 for ; Mon, 3 Nov 2003 22:45:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGs7r-0003oZ-Rg for tsvwg-archive@odin.ietf.org; Mon, 03 Nov 2003 22:45:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA43j3X4014657 for tsvwg-archive@odin.ietf.org; Mon, 3 Nov 2003 22:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGs7q-0003o9-LO; Mon, 03 Nov 2003 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo4d-0000zU-Vm for tsvwg@optimus.ietf.org; Mon, 03 Nov 2003 18:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03193 for ; Mon, 3 Nov 2003 18:25:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGo4a-0000Sq-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 18:25:25 -0500 Received: from mail1.cray.com ([136.162.0.111]) by ietf-mx with esmtp (Exim 4.12) id 1AGo4a-0000SC-00 for tsvwg@ietf.org; Mon, 03 Nov 2003 18:25:24 -0500 Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.10/8.12.10/gw-1.2) with ESMTP id hA3NOeGE007479; Mon, 3 Nov 2003 17:24:41 -0600 (CST) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.10/8.12.10/hub-1.3) with ESMTP id hA3NOdd0022972; Mon, 3 Nov 2003 17:24:39 -0600 (CST) Received: from [172.31.18.222] (restive [172.31.18.222]) by saffron.us.cray.com (8.12.10/8.12.8/badger-1.4) with ESMTP id hA3NOdW6589483; Mon, 3 Nov 2003 17:24:39 -0600 (CST) In-Reply-To: <3FA69A3F.6A5406CB@hp.com> References: <20031101221628.A18706@openss7.org> <3FA69A3F.6A5406CB@hp.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org From: David Borman Subject: Re: [Tsvwg] minimum TCP MSS Date: Mon, 3 Nov 2003 17:24:07 -0600 To: Rick Jones X-Mailer: Apple Mail (2.606) X-Cray-VirusStatus: clean Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 3, 2003, at 12:11 PM, Rick Jones wrote: > It is my understanding that there is no minimum MSS specified for TCP > (well, one > byte is perhaps implicit in TCP being a byte stream rather than a bit > stream...), although some TCP _implementations_ may have settings to > reject > connections advertising an MSS less than some value. > Again, unless I am getting beyond my knowledge, 536 is the _default_ > MSS - the > MSS that TCP should assume when it does not send or see an MSS option > in the SYN > or SYN|ACK segment. Yes, see RFC 1122, section 4.2.2.6 > > I _suspect_ but cannot quote chapter and verse to confirm, that 536 > stems from > the requirement that a conforming IP stack must be able to reassemble > IP > datagram fragments into IP datagrams of at least 576 bytes. That is the > "minimum, maximum IP datagram size" an IP stack must support, not a > minimum MTU. > (IIRC, the minimum IPv4 MTU is 68 bytes, and 12XX for v6) For IPv4, RFC 791 defines the minimum IP packet size as 68 bytes. On page 25: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. So, avoiding any IP fragmentation, that puts the minimum TCP MSS at 28 bytes. But since every IP must be able to receive a 576 byte packet, either as a single piece or in fragments, that's how the TCP default MSS of 536 is derived. > If TCP "knows" that the "minimum, maximum IP datagram size" is 576, > then it > "knows" that using an MSS of 536 (576 less 20 bytes of TCP header and > 20 bytes > of IP header, options may vary :) means that its traffic has at least a > snowball's chance of getting through. TCP MSS doesn't include IP or TCP options, it's the underlying MTU minus the fixed IP and TCP headers. Senders need to adjust down the amount of TCP data based on any IP or TCP options that it is inserting. > rick jones David Borman, dab@cray.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 15:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04256 for ; Tue, 4 Nov 2003 15:35:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7tL-00030x-3O for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 15:35:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4KZ746011572 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 15:35:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7tI-00030P-EC; Tue, 04 Nov 2003 15:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7CF-0000hb-SR for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 14:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00932 for ; Tue, 4 Nov 2003 14:50:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7CD-0003xE-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 14:50:33 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AH7CC-0003wW-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 14:50:32 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Tue, 4 Nov 2003 16:08:15 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Nov 2003 16:08:24 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6A6@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Date: Tue, 4 Nov 2003 16:08:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Comments on draft-morita-tsvwg-pps-01 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Naotaka, your revised and new PPS related draft are marked=20 as TSV WG, but haven't been announced yet (at least I=20 couldn't find an announcement in the archive). After=20 reading both, I'm having some remarks, following below. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt Remarks related to morita-tsvwg-pps-01: While the draft is focused on terminals sending with=20 variable rates, the edge traffic control seems to assume=20 the peak rate as only parameter characterising the=20 controlled traffic. Further, section 8.4 demands=20 continuous sending of packets. Does that mean that=20 terminals sending with variable rates are expected=20 to continuosly create traffic at their peak rate if=20 they desire to use PPS? Your third draft "Measurable Forwarding: A New per-Hop=20 Behavior (PHB)" wasn't listed in the "individual=20 submissions" section. If IETF didn't accept it this time,=20 a url to it would be useful as I think it helps=20 understanding pps operation. The framework could put more emphasis on the "stateless=20 core" operation. This feature is a clear and very desirable=20 benefit of PPS against other signaling modes. It is=20 mentioned only once in section 4.2 so far. I'll stop here and save minor and editorial comments for=20 a time when there's a clearer view on the future of PPS=20 within IETF. Regards, R=FCdiger R=FCdiger Geib T-Systems Systems Integration Senior Expert, Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 http://www.t-systems.com =20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 20:42:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15667 for ; Tue, 4 Nov 2003 20:42:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCgN-0006mk-SZ for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 20:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA51g3xn026078 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 20:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCgL-0006mL-M7; Tue, 04 Nov 2003 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCgB-0006lz-Na for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 20:41:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15647 for ; Tue, 4 Nov 2003 20:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCg9-0001Pp-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 20:41:49 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx with esmtp (Exim 4.12) id 1AHCg8-0001Pm-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 20:41:48 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id hA51fne1010120; Tue, 4 Nov 2003 17:41:49 -0800 Received: (from falk@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id hA51feCU010117; Tue, 4 Nov 2003 17:41:40 -0800 Date: Tue, 4 Nov 2003 17:41:40 -0800 From: Aaron Falk To: spencer@mcsr-labs.org, carlw@mcsr-labs.org Cc: tsvwg@ietf.org Message-ID: <20031105014139.GX1604@isi.edu> Mail-Followup-To: spencer@mcsr-labs.org, carlw@mcsr-labs.org, tsvwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [Tsvwg] comments on draft-dawkins-trigtran-linkup-01 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Spencer, Carl- I just read through draft-dawkins-trigtran-linkup-01.txt and have a couple of comments. I'm not sure if this document is on the agenda for tsvwg this IETF so I'm sending my comments now. Hope this is helpful, --aaron -------------- In section 2.3, you say: Hosts supporting TCP-based applications over subnetwork interfaces subject to multi-second outages MAY perform the actions described in Section 3. These actions are more attractive for TCP implementations used with "human-in-the-loop" applications, but are safe for any TCP-based implementation. Just to be clear: this proposal is only for end-systems, right? Not for routers? The text here is clearly talking about hosts but later in section 3 you talk about subnetworks. The proposal seems a little vague on this. I feel like you are saying that he retransmitted packet may come from a router along the path (as suggested in draft-ietf-pilc-link-design) but the language seems to imply that it is _hosts_ saving and retransmitting the packets. A block diagram would help. :) Because, if it is the sender saving and retransmitting the packets and the sender directly connected to the wireless interface, the question comes up: why not just kick the RTO timer when the interface comes back up, as Phil Karn suggested? ---------------- Section 3.1 "Layering Violation Tradeoffs" This section is quite confusing. I don't know what is meant by a "subnetwork implementation". At a minimum it's mis-titled. It doesn't say why one should be concerned about layering violations, nor what the tradeoffs are. ---------------- In section 3. "When a Local Interface Returns to UP", you say: When the subnetwork implementation detects that a local interface has returned to "UP" status, the subnetwork implementation MAY retransmit the last packet stored for each TCP connection. (Again: the subnetwork vs. end-host issue.) My concern here is that the proposal in this draft is for links that are down for long enough that recovering from an RTO is onerous. Links that are down for only a few RTTs should be allowed to recover using the existing algorithm. So, I think you should say something about how long a link is down before engaging in this behavior. For example, you might say 'the local interface has returned to "UP" and the/one/all connection(s) are in RETRANSMISSION-WAIT.' Of course, this means makes implementation a bit harder since you a) need to be on the end-system and b) need to correlate packets you are saving to resend with the state of the connection. A simple approach would be to have the implementor fix a lower bound in seconds. -------------- Finally in Section 3. you need to say something about aging old buffered packets. I have this vision of hosts with lots of idle or even closed connections, a link going down and up triggering a storm of saved packets from hours/days previous trying to restart connections that are idle. The hosts and connections will probably survive but it seems an un-neighborly thing to do to the network. So, I'd propose a setting maximum time that packets can be held, say 1 MSL (2 minutes, I believe), by any entity doing this algorithm. -------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 22:03:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19432 for ; Tue, 4 Nov 2003 22:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDwk-0004vq-UB for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 22:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5332XG018933 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 22:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDwj-0004vG-B4; Tue, 04 Nov 2003 22:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDwY-0004v5-25 for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 22:02:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19395 for ; Tue, 4 Nov 2003 22:02:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDwU-0002jz-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:02:46 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AHDwU-0002ja-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:02:46 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA532Gb9014035; Wed, 5 Nov 2003 03:02:16 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Nov 2003 22:03:35 -0500 Message-ID: From: "Peterson, Jon" To: "'Geib, Ruediger'" , morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Subject: RE: [Tsvwg] Comments on draft-morita-tsvwg-pps-01 Date: Tue, 4 Nov 2003 22:03:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Your third draft "Measurable Forwarding: A New per-Hop > Behavior (PHB)" wasn't listed in the "individual > submissions" section. If IETF didn't accept it this time, > a url to it would be useful as I think it helps > understanding pps operation. Just as an FYI - the IETF secretariat has been using some new tools for managing Internet-Draft submissions for this IETF, and they're still hammering out a few bugs. draft-morita-tsvwg-mfbhp-00 was submitted before the deadline, and we're working to get it into the I-D repository ASAP. Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 22:10:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19843 for ; Tue, 4 Nov 2003 22:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHE3X-0005VL-FC for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 22:10:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA53A3Bx021121 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 22:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHE3W-0005Tr-Pa; Tue, 04 Nov 2003 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHE2w-0005QD-V0 for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 22:09:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19743 for ; Tue, 4 Nov 2003 22:09:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHE2t-0002pq-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:09:23 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AHE2t-0002pK-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:09:23 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA538sb9014089 for ; Wed, 5 Nov 2003 03:08:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Nov 2003 22:10:13 -0500 Message-ID: From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Tue, 4 Nov 2003 22:10:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] WGLC for draft-ietf-tsvwg-slowstart-00 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The chairs would like to announce a three-week Working Group Last Call (allowing an extra week given the intervening IETF meeting) for draft-ietf-tsvwg-slowstart-00, commencing on November 5th and concluding on November 26th. Please send any final comments relating to this document to the TSVWG mailing list. Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 22:17:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20775 for ; Tue, 4 Nov 2003 22:17:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEAH-0005uN-SX for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 22:17:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA53H1sY022677 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 22:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHEAH-0005su-5p; Tue, 04 Nov 2003 22:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHE9K-0005qn-2n for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 22:16:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20720 for ; Tue, 4 Nov 2003 22:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHE9G-00033k-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:15:58 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHE9F-00033h-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 22:15:58 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA53FvUC009903; Wed, 5 Nov 2003 12:15:57 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA53Fupo002554; Wed, 5 Nov 2003 12:15:56 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA53Fu8H014596; Wed, 5 Nov 2003 12:15:56 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id MAA04068; Wed, 5 Nov 2003 12:15:55 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id MAA27035; Wed, 5 Nov 2003 12:15:55 +0900 (JST) Message-Id: <5.1.1.11.2.20031105121537.0458fe70@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Wed, 05 Nov 2003 12:15:58 +0900 To: "Peterson, Jon" , "'Geib, Ruediger'" From: "MORITA, Naotaka" Subject: RE: [Tsvwg] Comments on draft-morita-tsvwg-pps-01 Cc: tsvwg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, Thank you for the confirmation. At 22:03 03/11/04 -0500, Peterson, Jon wrote: > >> Your third draft "Measurable Forwarding: A New per-Hop >> Behavior (PHB)" wasn't listed in the "individual >> submissions" section. If IETF didn't accept it this time, >> a url to it would be useful as I think it helps >> understanding pps operation. > >Just as an FYI - the IETF secretariat has been using some new tools for >managing Internet-Draft submissions for this IETF, and they're still >hammering out a few bugs. draft-morita-tsvwg-mfbhp-00 was submitted before >the deadline, and we're working to get it into the I-D repository ASAP. > >Jon Peterson >NeuStar, Inc. > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 4 23:26:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22735 for ; Tue, 4 Nov 2003 23:26:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHF2q-0001ZE-QC for tsvwg-archive@odin.ietf.org; Tue, 04 Nov 2003 23:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA54DOG1006025 for tsvwg-archive@odin.ietf.org; Tue, 4 Nov 2003 23:13:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHF2a-0001YK-CW; Tue, 04 Nov 2003 23:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHF1t-0001XZ-Nx for tsvwg@optimus.ietf.org; Tue, 04 Nov 2003 23:12:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22394 for ; Tue, 4 Nov 2003 23:12:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHF1r-0003mF-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 23:12:23 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHF1q-0003m5-00 for tsvwg@ietf.org; Tue, 04 Nov 2003 23:12:22 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA54CKUC019354 for ; Wed, 5 Nov 2003 13:12:20 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA54CJpo011942 for ; Wed, 5 Nov 2003 13:12:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA54CJ8H029625 for ; Wed, 5 Nov 2003 13:12:19 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA08416 for ; Wed, 5 Nov 2003 13:12:18 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA01586 for ; Wed, 5 Nov 2003 13:12:18 +0900 (JST) Message-Id: <5.1.1.11.2.20031105125656.05ef7770@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Wed, 05 Nov 2003 13:08:21 +0900 To: tsvwg@ietf.org From: "MORITA, Naotaka" Subject: RE: [Tsvwg] Comments on draft-morita-tsvwg-pps-01 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Regarding PPS and MF-PHB, could someone give me any hints? 1) Real time video characterisctis Are there any archive about real time (interactive) video? 2) Constant or Variable I am personally collecting characteristics of interactive video traffic. Some of them are quite flat and some of them are quite fluctuating. Is it possible and reasonable to produce constant rate traffic by adjusting picuture resolution or quality? 2) In the MF-PHB document, I describe a couple policer behaviors. I know that there are some variants of the policer description. Are there any reference in IETF? 3) In the MF-PHB document, I describe two-threshold policer and two-rate policer. I guess the two-threshold policer is similar to single rate Two Rate Markder specified in RFC2697, but is slightly different. Are there any discussion about this kind of new policers? Naotaka At 22:03 03/11/04 -0500, Peterson, Jon wrote: > >> Your third draft "Measurable Forwarding: A New per-Hop >> Behavior (PHB)" wasn't listed in the "individual >> submissions" section. If IETF didn't accept it this time, >> a url to it would be useful as I think it helps >> understanding pps operation. > >Just as an FYI - the IETF secretariat has been using some new tools for >managing Internet-Draft submissions for this IETF, and they're still >hammering out a few bugs. draft-morita-tsvwg-mfbhp-00 was submitted before >the deadline, and we're working to get it into the I-D repository ASAP. > >Jon Peterson >NeuStar, Inc. ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 00:49:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24669 for ; Wed, 5 Nov 2003 00:49:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHGXQ-00058p-OH for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 00:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA55n4VO019740 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 00:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHGXN-00058C-0m; Wed, 05 Nov 2003 00:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHGWz-00057g-Hc for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 00:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24654 for ; Wed, 5 Nov 2003 00:48:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHGWw-0004og-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 00:48:34 -0500 Received: from bay1-f115.bay1.hotmail.com ([65.54.245.115] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AHGWw-0004oB-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 00:48:34 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Nov 2003 21:48:04 -0800 Received: from 66.46.217.31 by by1fd.bay1.hotmail.msn.com with HTTP; Wed, 05 Nov 2003 05:48:04 GMT X-Originating-IP: [66.46.217.31] X-Originating-Email: [kalatwal@hotmail.com] From: "K S A" To: sri@us.ibm.com, randall@stewart.chicago.il.us Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP Date: Wed, 05 Nov 2003 05:48:04 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Nov 2003 05:48:04.0754 (UTC) FILETIME=[61AECF20:01C3A360] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I have question about the RTO.min value. The draft says that there is one RTO.min value per stack. But, it is possible a host could have one association that travels over the public Internet and others that travel over a short (a few meters) high speed links. But, the lower latency local links will be forced to take at least the RTO.min value when re-transmitting data. While it may have been shown that a RTO.min value of 1 second is appropriate for the public Internet, it seems to unduly slow recovery of low latency local links. Could there not be a RTO.min value per association to accomodate this difference in latency that allows each link to operate efficiently? - Kulwinder. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 08:48:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05505 for ; Wed, 5 Nov 2003 08:48:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO0w-0002BW-Qh for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 08:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Dm2qJ008362 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 08:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO0u-0002AP-QO; Wed, 05 Nov 2003 08:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHO0t-00029t-7m for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 08:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05470 for ; Wed, 5 Nov 2003 08:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHO0r-0004ND-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 08:47:57 -0500 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1AHO0k-0004MF-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 08:47:50 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id hA5DlF4j057205; Wed, 5 Nov 2003 07:47:17 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FA8FF61.30207@stewart.chicago.il.us> Date: Wed, 05 Nov 2003 07:47:13 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: K S A CC: sri@us.ibm.com, tsvwg@ietf.org Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit K S A wrote: > > I have question about the RTO.min value. The draft says that there is > one RTO.min value per stack. What draft are you talking about? Socketsapi? > But, it is possible a host could have one association that travels > over the public Internet and others that travel over a short (a few > meters) high speed links. But, the lower latency local links will be > forced to take at least the RTO.min value when re-transmitting data. > > While it may have been shown that a RTO.min value of 1 second is > appropriate for the public Internet, it seems to unduly slow recovery > of low latency local links. > > Could there not be a RTO.min value per association to accomodate this > difference in latency that allows each link to operate efficiently? > I know in KAME we implemented a RTO.min per endpoint.. which is inherited from the RTO.min of the system.. that way you could change things for those special cases. R > - Kulwinder. > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 13:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16636 for ; Wed, 5 Nov 2003 13:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShM-0003VZ-Rf for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 13:48:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Im8Om013462 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 13:48:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHShF-0003SR-Tq; Wed, 05 Nov 2003 13:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHSgU-0003Rl-05 for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 13:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16562 for ; Wed, 5 Nov 2003 13:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgR-0000ag-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 13:47:11 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHSgR-0000aO-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 13:47:11 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id hA5IkVYd131470; Wed, 5 Nov 2003 13:46:31 -0500 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA5IkS0N180012; Wed, 5 Nov 2003 13:46:29 -0500 Date: Wed, 5 Nov 2003 10:46:26 -0800 (PST) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: "Randall R. Stewart (home)" cc: K S A , Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP In-Reply-To: <3FA8FF61.30207@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Wed, 5 Nov 2003, Randall R. Stewart (home) wrote: > K S A wrote: > > > > > I have question about the RTO.min value. The draft says that there is > > one RTO.min value per stack. > > > What draft are you talking about? Socketsapi? > > > But, it is possible a host could have one association that travels > > over the public Internet and others that travel over a short (a few > > meters) high speed links. But, the lower latency local links will be > > forced to take at least the RTO.min value when re-transmitting data. > > > > While it may have been shown that a RTO.min value of 1 second is > > appropriate for the public Internet, it seems to unduly slow recovery > > of low latency local links. > > > > Could there not be a RTO.min value per association to accomodate this > > difference in latency that allows each link to operate efficiently? > > > I know in KAME we implemented a RTO.min per endpoint.. which is > inherited from the > RTO.min of the system.. that way you could change things for those > special cases. Even in LK-SCTP, all the RTO parameters(initial, min and max) are tunable per association or endpoint. This can be done using the new SCTP_RTOINFO socket option defined in the sockets api extension draft. Thanks Sridhar > > R > > > - Kulwinder. > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > > > > > > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 16:24:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24530 for ; Wed, 5 Nov 2003 16:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8U-0005Va-HB for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOIug021129 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8K-0005KY-1t; Wed, 05 Nov 2003 16:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU8Q-0002sN-1T for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 15:20:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22337 for ; Wed, 5 Nov 2003 15:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU8O-0002SU-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 15:20:08 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AHU8N-0002S4-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 15:20:07 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA5KJZb9027581 for ; Wed, 5 Nov 2003 20:19:35 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 15:20:56 -0500 Message-ID: From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Wed, 5 Nov 2003 15:20:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] proposed agenda for TSVWG Meeting in Minneapolis Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Please send any comments or suggestions on the agenda to myself and Allison. Jon Peterson NeuStar, Inc. ---- Transport Area WG (tsvwg) Monday, November 10 at 0900-1130 ============================= CHAIRS: Allison Mankin Jon Peterson 0900 Charter Discussion (chairs) 0910 Newreno Update (Sally Floyd) (5 mins) http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-01.txt 0915 Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy) (15 mins) http://www.ietf.org/internet-drafts/draft-bhandarkar-tcp-dcr-00.txt 0930 FAST TCP (Cheng/Low) (15 mins) http://www.ietf.org/internet-drafts/draft-jin-wei-low-tcp-fast-01.txt 0945 Early Retransmit (Mark Allman) (15 mins) http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-02.txt 1000 IPMP (Matthew Luckie) (10 mins) http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-02.txt 1010 RFC1323bis (David Borman) (15 mins) http://www.ietf.org/internet-drafts/draft-jacobson-tsvwg-1323bis-00.txt 1025 Priority Promotion Scheme (Naotaka MORITA) (15 mins) http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt 1040 "Packet Drop" chunk type (Randall Stewart) (15 mins) http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt 1055 SCTP Chunk Authentication (Michael Tuexen) (15 mins) http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-00.txt 1110 De-correlated Loss Recovery (Yogesh Prem Swami) (10 mins) http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-02.txt http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-01.txt 1120 Multi-link Transport (Hosei Matsuoka) (10 mins) http://www.ietf.org/internet-drafts/draft-matsuoka-multilink-transport-00.tx t 1130 Close meeting _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 16:33:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25054 for ; Wed, 5 Nov 2003 16:33:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVGw-0007I1-4l for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 16:33:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LX2ej027994 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 16:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVGv-0007Gi-HL; Wed, 05 Nov 2003 16:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVGe-0007GT-6N for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 16:32:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25040 for ; Wed, 5 Nov 2003 16:32:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVGc-0003q4-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 16:32:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVGb-0003pk-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 16:32:41 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA5LW8mW020644; Wed, 5 Nov 2003 13:32:10 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANX50326; Wed, 5 Nov 2003 13:32:06 -0800 (PST) Date: Wed, 5 Nov 2003 16:32:05 -0500 Subject: Re: [Tsvwg] proposed agenda for TSVWG Meeting in Minneapolis Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'tsvwg@ietf.org'" To: "Peterson, Jon" From: Melinda Shore In-Reply-To: Message-Id: <80748F5E-0FD7-11D8-A2D4-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, November 5, 2003, at 03:20 PM, Peterson, Jon wrote: > Please send any comments or suggestions on the agenda to myself and > Allison. At the last meeting it was mentioned that there were plans to create a new working group to handle the TCP stuff that's been being done in tsvwg. I think that's a good idea - what's its status? Melinda _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 18:07:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29206 for ; Wed, 5 Nov 2003 18:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWjz-0005jA-3u for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 18:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5N76H7021978 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 18:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWjt-0005gw-GA; Wed, 05 Nov 2003 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHWjQ-0005eF-TB for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 18:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29061 for ; Wed, 5 Nov 2003 18:06:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHWjN-0005Ko-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 18:06:29 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AHWjN-0005Ka-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 18:06:29 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA5N5pb9030828; Wed, 5 Nov 2003 23:05:51 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 18:07:11 -0500 Message-ID: From: "Peterson, Jon" To: "'Melinda Shore'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] proposed agenda for TSVWG Meeting in Minneapolis Date: Wed, 5 Nov 2003 18:07:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yes, this will be discussed during the allotted "charter" time at the beginning of the session. I'm pleased to say that we do have a proposed charter, and a plan for migrating existing TSVWG items over to the new WG. More details will follow before the meeting on Monday. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 05, 2003 1:32 PM > To: Peterson, Jon > Cc: 'tsvwg@ietf.org' > Subject: Re: [Tsvwg] proposed agenda for TSVWG Meeting in Minneapolis > > > On Wednesday, November 5, 2003, at 03:20 PM, Peterson, Jon wrote: > > Please send any comments or suggestions on the agenda to myself and > > Allison. > > At the last meeting it was mentioned that there were plans to create a > new working group to handle the TCP stuff that's been being done in > tsvwg. I think that's a good idea - what's its status? > > Melinda > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 5 22:46:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08658 for ; Wed, 5 Nov 2003 22:46:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHb5v-0005yG-UU for tsvwg-archive@odin.ietf.org; Wed, 05 Nov 2003 22:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA63k37c022948 for tsvwg-archive@odin.ietf.org; Wed, 5 Nov 2003 22:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHb5t-0005xz-VT; Wed, 05 Nov 2003 22:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHb52-0005w8-Ip for tsvwg@optimus.ietf.org; Wed, 05 Nov 2003 22:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08643 for ; Wed, 5 Nov 2003 22:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHb4z-0001Ee-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 22:45:05 -0500 Received: from bay1-f10.bay1.hotmail.com ([65.54.245.10] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AHb4y-0001EK-00 for tsvwg@ietf.org; Wed, 05 Nov 2003 22:45:04 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Nov 2003 19:44:35 -0800 Received: from 24.92.224.41 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 06 Nov 2003 03:44:34 GMT X-Originating-IP: [24.92.224.41] X-Originating-Email: [kalatwal@hotmail.com] From: "K S A" To: sri@us.ibm.com, randall@stewart.chicago.il.us Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] one-to-many/one-to-one socket API extension for SCTP Date: Thu, 06 Nov 2003 03:44:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Nov 2003 03:44:35.0161 (UTC) FILETIME=[4BA26490:01C3A418] Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > >On Wed, 5 Nov 2003, Randall R. Stewart (home) wrote: > > > K S A wrote: > > > > > > > > I have question about the RTO.min value. The draft says that there is > > > one RTO.min value per stack. > > > > > > What draft are you talking about? Socketsapi? draft-ietf-tsvwg-sctpsocket-07.txt on the WG page. Where is/are the lastest references? I had read RFC2960 which also has this limitation. - Thanks, Kulwinder. > > > > > But, it is possible a host could have one association that travels > > > over the public Internet and others that travel over a short (a few > > > meters) high speed links. But, the lower latency local links will be > > > forced to take at least the RTO.min value when re-transmitting data. > > > > > > While it may have been shown that a RTO.min value of 1 second is > > > appropriate for the public Internet, it seems to unduly slow recovery > > > of low latency local links. > > > > > > Could there not be a RTO.min value per association to accomodate this > > > difference in latency that allows each link to operate efficiently? > > > > > I know in KAME we implemented a RTO.min per endpoint.. which is > > inherited from the > > RTO.min of the system.. that way you could change things for those > > special cases. > >Even in LK-SCTP, all the RTO parameters(initial, min and max) are tunable >per association or endpoint. This can be done using the new SCTP_RTOINFO >socket option defined in the sockets api extension draft. > >Thanks >Sridhar > > > > > R > > > > > - Kulwinder. > > > > > > _________________________________________________________________ > > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > > >http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 6 14:37:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24987 for ; Thu, 6 Nov 2003 14:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpwF-0004oX-2v for tsvwg-archive@odin.ietf.org; Thu, 06 Nov 2003 14:37:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Jb20Z018483 for tsvwg-archive@odin.ietf.org; Thu, 6 Nov 2003 14:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpwC-0004n5-8D; Thu, 06 Nov 2003 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlFk-00027n-68 for tsvwg@optimus.ietf.org; Thu, 06 Nov 2003 09:36:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10670 for ; Thu, 6 Nov 2003 09:36:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlFi-0001us-00 for tsvwg@ietf.org; Thu, 06 Nov 2003 09:36:50 -0500 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1AHlFh-0001uX-00 for tsvwg@ietf.org; Thu, 06 Nov 2003 09:36:49 -0500 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Thu, 6 Nov 2003 15:14:03 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Nov 2003 15:14:14 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6B1@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: morita.naotaka@lab.ntt.co.jp Cc: tsvwg@ietf.org Date: Thu, 6 Nov 2003 15:14:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] More comments on the pps drafts Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Naotaka, some more thoughts after having read the MF PHB draft (which I felt to = be enjoyable reading): - PPS requires a "customised" output policing=20 rather than a special queuing discipline. It=20 may be useful if the framework could=20 explicitely mention this important fact.=20 - The re-routing and mobility cases will require=20 more thought. I doubt that a state free attempt=20 will do. How does a router learn that some MF-H=20 traffic is exceptional? Fast thought: something like a path-token=20 transmitted within a domain and tracked by=20 routers?=20 - Also suiting variable rate sources may require=20 some state. Here, information about the number=20 of active sources and their peak rate may be=20 useful. This could help to set the MF-M=20 threshold in the dynamic case and also be=20 used for buffer dimensioning. - Buffer dimensioning needs some more discussion. - When does an access system decide that a=20 session is terminated? Without a timer, a=20 terminal may continue to send MF-H traffic=20 because it considers the session still to be=20 up. Again, a limited amount of state would be=20 required to handle the issue. The state maintenance requirements I mentioned still aren't as big as = with RSVP and would refer to aggregates in the core.=20 Regards, R=FCdiger R=FCdiger Geib T-Systems Systems Integration Senior Expert, Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 http://www.t-systems.com =20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 6 23:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16150 for ; Thu, 6 Nov 2003 23:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHyLs-000307-HD for tsvwg-archive@odin.ietf.org; Thu, 06 Nov 2003 23:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA74a41I011523 for tsvwg-archive@odin.ietf.org; Thu, 6 Nov 2003 23:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHyLq-0002zi-0p; Thu, 06 Nov 2003 23:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHyLO-0002xa-Ht for tsvwg@optimus.ietf.org; Thu, 06 Nov 2003 23:35:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16125 for ; Thu, 6 Nov 2003 23:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHyLM-0006IL-00 for tsvwg@ietf.org; Thu, 06 Nov 2003 23:35:32 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHyLL-0006IE-00 for tsvwg@ietf.org; Thu, 06 Nov 2003 23:35:31 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA74ZOUC006951 for ; Fri, 7 Nov 2003 13:35:24 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA74ZNpo006601 for ; Fri, 7 Nov 2003 13:35:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA74ZL8H026616 for ; Fri, 7 Nov 2003 13:35:22 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA06588 for ; Fri, 7 Nov 2003 13:35:20 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA27061 for ; Fri, 7 Nov 2003 13:35:20 +0900 (JST) Message-Id: <5.1.1.11.2.20031107133454.0450fd90@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 13:35:03 +0900 To: tsvwg@ietf.org From: "MORITA, Naotaka" Subject: Re: [Tsvwg] More comments on the pps drafts In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6B1@G8PQD.blf01.telek om.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id hA74ZOUC006951 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ruediger, At 15:14 03/11/06 +0100, Geib, Ruediger wrote: >Hello Naotaka, > >some more thoughts after having read the MF PHB draft (which I felt to = be >enjoyable reading): Thank you again. > >- PPS requires a "customised" output policing > rather than a special queuing discipline. It > may be useful if the framework could > explicitely mention this important fact. Rate limiting is the required function. Policer or shaper can be used for the rate limiting. Due to the short-delay characteristics and being potential to extend to the elastic mode, the policer is preferable. But the shaper, for the quick deployment, can be used. >- The re-routing and mobility cases will require > more thought. I doubt that a state free attempt > will do. How does a router learn that some MF-H > traffic is exceptional? > Fast thought: something like a path-token > transmitted within a domain and tracked by > routers? Yes, it is a state free attempt. But the router does not distingush exceptional MF-H traffic from ordinal = one. For the mobility case, it will work, because the exceptional traffic may not be so large. For the re-routing case, if we limit the topology and anticipate the wors= t re-routed traffic, it should work. >- Also suiting variable rate sources may require > some state. Here, information about the number > of active sources and their peak rate may be > useful. This could help to set the MF-M > threshold in the dynamic case and also be > used for buffer dimensioning. I am sorry. I do not catch your point. As you have pointed out at the previous mail, the important feature of PPS is stateless inside the nework, or inside the core at least. For the ingress edge, per-flow state may be necessary to avoid unexpected terminal behavior. Do you mean the state for varible rate source is at the ingress egde, or all routers? >- Buffer dimensioning needs some more discussion. I fully agree. I am now investigating in my labs. >- When does an access system decide that a > session is terminated? Without a timer, a > terminal may continue to send MF-H traffic > because it considers the session still to be > up. Again, a limited amount of state would be > required to handle the issue. Yes, I agree. For the ingress edge, a limited amout of state is necessary for unexpected use. I assume that the terminal send "Bye" message at the SIP level and the SIP proxy makes the edge router release access control list. > >The state maintenance requirements I mentioned still aren't as big as w= ith >RSVP and would refer to aggregates in the core. I agree. I would like to stress the following points. 1. The state per MF-PHB class is mandatory. It is the rate limit value a= t=20 the policer or the shaper. The rate limit is per-class basis, at the output port at all routers, or=20 even L2 switches. 2. Per-flow states are at terminals. 3. If the operator want to avoid unexpected use such as malicious use or=20 failuer condition, the edge router should keep per-flow states for per-flow policing at the=20 input port at the ingress router. Naotaka > >Regards, R=1B$B=97E=1B(Biger > > >R=1B$B=97E=1B(Biger Geib >T-Systems >Systems Integration >Senior Expert, Technologiezentrum >Am Kavalleriesand 3, 64295 Darmstadt >Germany >Fon: +49 6151 832138 >http://www.t-systems.com > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 7 00:25:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17425 for ; Fri, 7 Nov 2003 00:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHz7M-0004fz-J9 for tsvwg-archive@odin.ietf.org; Fri, 07 Nov 2003 00:25:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA75P8m0017950 for tsvwg-archive@odin.ietf.org; Fri, 7 Nov 2003 00:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHz7H-0004ed-5J; Fri, 07 Nov 2003 00:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHz6z-0004e6-NI for tsvwg@optimus.ietf.org; Fri, 07 Nov 2003 00:24:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17407 for ; Fri, 7 Nov 2003 00:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHz6x-0006nl-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 00:24:43 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHz6w-0006ni-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 00:24:42 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75OeUC016406 for ; Fri, 7 Nov 2003 14:24:41 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75Odpo015186 for ; Fri, 7 Nov 2003 14:24:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75Ob8H010886 for ; Fri, 7 Nov 2003 14:24:37 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA11034 for ; Fri, 7 Nov 2003 14:24:37 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA00977 for ; Fri, 7 Nov 2003 14:24:36 +0900 (JST) Message-Id: <5.1.1.11.2.20031107142341.045258b0@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 14:24:41 +0900 To: tsvwg@ietf.org From: "MORITA, Naotaka" Subject: Re: [Tsvwg] More comments on the pps drafts In-Reply-To: <5.1.1.11.2.20031107133454.0450fd90@imj.m.ecl.ntt.co.jp> References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB6B1@G8PQD.blf01.telekom.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You can refer to the following web site for measurement-based admission control. http://lcn.imit.kth.se/PBAC/ ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 7 00:37:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17615 for ; Fri, 7 Nov 2003 00:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzIs-00051Z-S0 for tsvwg-archive@odin.ietf.org; Fri, 07 Nov 2003 00:37:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA75b222019288 for tsvwg-archive@odin.ietf.org; Fri, 7 Nov 2003 00:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzIq-00050L-Qs; Fri, 07 Nov 2003 00:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHzIb-0004zy-Ns for tsvwg@optimus.ietf.org; Fri, 07 Nov 2003 00:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17600 for ; Fri, 7 Nov 2003 00:36:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHzIY-0006t2-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 00:36:43 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AHzIY-0006su-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 00:36:42 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75aeUC018378 for ; Fri, 7 Nov 2003 14:36:40 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75adpo017114 for ; Fri, 7 Nov 2003 14:36:39 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA75ac8H014006 for ; Fri, 7 Nov 2003 14:36:38 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA12010 for ; Fri, 7 Nov 2003 14:36:38 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA01931 for ; Fri, 7 Nov 2003 14:36:38 +0900 (JST) Message-Id: <5.1.1.11.2.20031107143448.04511548@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 14:36:43 +0900 To: tsvwg@ietf.org From: "MORITA, Naotaka" Subject: Re: [Tsvwg] Comments on draft-morita-tsvwg-pps-01 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id hA75aeUC018378 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I thought I had replied to the TSV mailing list, not directly to Ruediger= , Naotaka =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ruediger, Thank you very much for your comments. At 16:08 03/11/04 +0100, you wrote: >Hello Naotaka, > >your revised and new PPS related draft are marked >as TSV WG, but haven't been announced yet (at least I >couldn't find an announcement in the archive). After >reading both, I'm having some remarks, following below. > >http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt >http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt > Actually I posted three documents. Those are avilable now. The most important one is http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt >Remarks related to morita-tsvwg-pps-01: > >While the draft is focused on terminals sending with >variable rates, the edge traffic control seems to assume >the peak rate as only parameter characterising the >controlled traffic. Further, section 8.4 demands >continuous sending of packets. Does that mean that >terminals sending with variable rates are expected >to continuosly create traffic at their peak rate if >they desire to use PPS? I need to check the consistency of the description. Thanks. For the edge, I assume peak reate policing per-flow basis. But the source can be variable bit rate. > >Your third draft "Measurable Forwarding: A New per-Hop >Behavior (PHB)" wasn't listed in the "individual >submissions" section. If IETF didn't accept it this time, >a url to it would be useful as I think it helps >understanding pps operation. Fortunately, this missing one is now on the web site. > >The framework could put more emphasis on the "stateless >core" operation. This feature is a clear and very desirable >benefit of PPS against other signaling modes. It is >mentioned only once in section 4.2 so far. Thank you again. That is the bottom line of this scheme. > >I'll stop here and save minor and editorial comments for >a time when there's a clearer view on the future of PPS >within IETF. If you make additional comments on MF-PHB according to the last draft, I am happy. Regards, Naotaka > >Regards, R=1B$B=97E=1B(Biger > > >R=1B$B=97E=1B(Biger Geib >T-Systems >Systems Integration >Senior Expert, Technologiezentrum >Am Kavalleriesand 3, 64295 Darmstadt >Germany >Fon: +49 6151 832138 >http://www.t-systems.com > > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html=20 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 7 11:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21285 for ; Fri, 7 Nov 2003 11:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9ca-0007dV-CC for tsvwg-archive@odin.ietf.org; Fri, 07 Nov 2003 11:38:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Gc4OW029349 for tsvwg-archive@odin.ietf.org; Fri, 7 Nov 2003 11:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9cY-0007cm-5T; Fri, 07 Nov 2003 11:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9bh-0007OB-O3 for tsvwg@optimus.ietf.org; Fri, 07 Nov 2003 11:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21258 for ; Fri, 7 Nov 2003 11:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9bg-0007Gx-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 11:37:08 -0500 Received: from adsl-02-154.abel.net.uk ([193.109.51.154] helo=starburst.demon.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1AI9bf-0007Gu-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 11:37:07 -0500 Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id QAA15109 for tsvwg@ietf.org; Fri, 7 Nov 2003 16:37:05 GMT From: Richard Wendland Message-Id: <200311071637.QAA15109@starburst.demon.co.uk> To: tsvwg@ietf.org Date: Fri, 7 Nov 2003 16:37:04 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] RFC1323bis comments Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have a comment on draft-jacobson-tsvwg-1323bis-00.txt. I think the Windows TCP behaviour of sending a zero-valued TSecr on SYN-ACK rather than using the TSval value sent on the SYN needs to be addressed in RFC1323bis. The new APPENDIX E Pseudo-code Summary does not allow for this behaviour. It looks to me like at least some implementations do not allow for this behaviour, probably leading to SRTT and RTTVAR being initialised to very large values at the SYN-ACK. Looking at the FreeBSD source and TCP/IP Illustrated Vol 2 I cannot find any code that disregards zero-valued TSecr echoes. It seems to me that the RFC1323 (and RFC1323bis) specification could be read both to allow and dis-allow this behaviour. Thus I think this aspect of the specification should be made clearer. The pertinent section of RFC1323bis is in 3.2: The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. a) If one takes the sentence "When TSecr is not valid, its value must be zero." in isolation, it could be taken to mean that whenever an implementation does not have a valid TSecr to hand (for whatever reason), it is OK to send a zero TSecr. This justifies the Windows implementation. b) If one takes the paragraph as a whole, one can argue that the word "valid" is specified for this paragraph to have a particular meaning: "valid" = ACK bit set in header. Thus all the sentence in a) really means in this context "The TSecr in a TCP header without the ACK bit set must have a value of zero". So "if it is valid [ACK bit set], it echos a timestamp value that was sent by the remote TCP in the TSval" applies and Windows TCP is wrong not to echo the TSval it was sent on the SYN. Interpretation b) can take support from "These TSval values are echoed in TSecr values in the reverse direction." in 3.3, and the TS.Recent discussion. Whatever view is taken on the correct interpretation of RFC1323, at this stage I do not think a new RFC should disregard at least 3 years widespread practice by Windows TCP. Windows probably does this because it does not set up a full connection control block until the connection is fully open, and so does not remember the SYN TSval in a way that can be echoed in the SYN-ACK. This is not entirely unreasonable behaviour. If my argument that this area of the specification needs clarifying is accepted, and the specification will permit the Windows TCP practice, it has to be decided if it will allow a zero TSecr only on the SYN-ACK, or on any segment where an implementation wishes to do this. I do not have a view on this. However it is worth noting that allowing a zero TSecr anywhere an implementation chooses is pertinent to the issue Reiner Ludwig raised ([Tsvwg] on 14 Aug 2003): Another open issue with RFC1323, I think, is the question of whether *every* segment MUST carry a TS option once that was negotiated in the SYN/SYN-ACK handshake. since it impacts algorithms and testing in a similar way. Richard -- Richard Wendland richard@codeburst.co.uk _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 7 19:37:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16501 for ; Fri, 7 Nov 2003 19:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH67-0005FI-8j for tsvwg-archive@odin.ietf.org; Fri, 07 Nov 2003 19:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80b3g2020131 for tsvwg-archive@odin.ietf.org; Fri, 7 Nov 2003 19:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH65-0005E3-D5; Fri, 07 Nov 2003 19:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH5s-0005Bf-PD for tsvwg@optimus.ietf.org; Fri, 07 Nov 2003 19:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16481 for ; Fri, 7 Nov 2003 19:36:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH5q-0005ru-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 19:36:46 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AIH5q-0005r1-00 for tsvwg@ietf.org; Fri, 07 Nov 2003 19:36:46 -0500 Received: from chiimc01.npac.com (chiimc01.neustar.com [10.32.90.4]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA80aBb9010316 for ; Sat, 8 Nov 2003 00:36:11 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 18:37:35 -0600 Message-ID: From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Fri, 7 Nov 2003 18:37:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] Final agenda for TSVWG meeting Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Transport Area WG (tsvwg) Monday, November 10 at 0900-1130 ============================= CHAIRS: Allison Mankin Jon Peterson 0900 Charter Discussion (chairs) 0910 "Packet Drop" chunk type (Randall Stewart) (15 mins) http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt 0925 Newreno Update (Sally Floyd) (5 mins) http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-01.txt 0930 Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy) (15 mins) http://www.ietf.org/internet-drafts/draft-bhandarkar-tcp-dcr-00.txt 0945 FAST TCP (Cheng/Low) (15 mins) http://www.ietf.org/internet-drafts/draft-jin-wei-low-tcp-fast-01.txt 1000 LinkUp (Spencer Dawkins) (15 mins) http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-linkup-01.txt 1015 IPMP (Matthew Luckie) (10 mins) http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-02.txt 1025 RFC1323bis (David Borman) (15 mins) http://www.ietf.org/internet-drafts/draft-jacobson-tsvwg-1323bis-00.txt 1040 Priority Promotion Scheme (Naotaka MORITA) (15 mins) http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt 1055 SCTP Chunk Authentication (Michael Tuexen) (15 mins) http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-00.txt 1110 De-correlated Loss Recovery (Yogesh Prem Swami) (10 mins) http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-02.txt http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-01.txt 1120 Multi-link Transport (Hosei Matsuoka) (10 mins) http://www.ietf.org/internet-drafts/draft-matsuoka-multilink-transport-00.tx t 1130 Close meeting _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 10 18:40:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22970 for ; Mon, 10 Nov 2003 18:40:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLdg-0007Yw-BD for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 18:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANe8n7029064 for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 18:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLdb-0007Y5-9v; Mon, 10 Nov 2003 18:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLcc-0007W2-2f for tsvwg@optimus.ietf.org; Mon, 10 Nov 2003 18:39:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22864; Mon, 10 Nov 2003 18:38:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLcX-0007ZU-00; Mon, 10 Nov 2003 18:38:57 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AJLcX-0007ZR-00; Mon, 10 Nov 2003 18:38:57 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AJLcK-0002BX-00; Tue, 11 Nov 2003 00:38:44 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AJLcJ-0003pZ-00; Tue, 11 Nov 2003 00:38:43 +0100 Received: from localhost ([::1] helo=i72mn12.tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AJLcB-0007JC-00; Tue, 11 Nov 2003 00:38:36 +0100 Date: Tue, 11 Nov 2003 00:38:55 +0100 From: Roland Bless To: "MORITA, Naotaka" Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" Message-Id: <20031111003855.5c313dd0.bless@tm.uka.de> In-Reply-To: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: [NSIS] PPS and MF-PHB Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Naotaka, On Fri, 07 Nov 2003 09:36:44 +0900 "MORITA, Naotaka" wrote: > I would like to draw QoS experts attention to the following three documents. > > http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt > http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt > http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt > > I am going to make a presentation on Monday morning at TSV WG. After reading draft-morita-tsvwg-mfphb-00.txt and attending your presentation, I have some remarks related to this approach: - I'm not quite sure whether this is really a PHB definition. It seems to me, that it is actually a mix of * a scheme for measured-based admission control and resource provisioning * a Per-Domain Behavior (see RFC 3086) * a PHB group description - The scheme inherently relies on feedback information and it should be made clear how the feedback can be provided (you mentioned RTCP as an example, what about others?). - Instead of defining a new PHB, possibly two Class Selector PHBs or even an AF class can be used ("green" packets get high priority after admission control, "yellow" and "red" packet may be used for probing). AF usually gives no guarantees for delay and jitter, however, if AF is provisioned properly, "green" packets may get some guarantee. - For security and robustness, it is essential to police the markings for the higher priority. Otherwise the service guarantees for other users are violated by a malicious or ill-behaving end-system. Therefore, I think first-hop routers should do the policing (based on the feedback information?). - I see some value in the overall approach, but IMHO the proposal may be turned into a description for a measurement-based admission control scheme and PDB using Class Selector PHBs. I copied to the relevant lists (diffserv-interest and tsvwg) as I'm interested in other opinions. Best regards, Roland _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 10 21:47:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01346 for ; Mon, 10 Nov 2003 21:47:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOYZ-0000oL-85 for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 21:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB2l3BN003113 for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 21:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOYX-0000nv-51; Mon, 10 Nov 2003 21:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOYV-0000nc-OL for tsvwg@optimus.ietf.org; Mon, 10 Nov 2003 21:46:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01331; Mon, 10 Nov 2003 21:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOYS-0003Ed-00; Mon, 10 Nov 2003 21:46:56 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AJOYR-0003Ea-00; Mon, 10 Nov 2003 21:46:55 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2krUC004345; Tue, 11 Nov 2003 11:46:53 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2kqpo001999; Tue, 11 Nov 2003 11:46:52 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAB2kp8H000105; Tue, 11 Nov 2003 11:46:51 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA04812; Tue, 11 Nov 2003 11:46:51 +0900 (JST) Received: from morita-ibmthink.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id LAA09423; Tue, 11 Nov 2003 11:46:49 +0900 (JST) Message-Id: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Mon, 10 Nov 2003 20:45:59 -0600 To: Roland Bless From: "MORITA, Naotaka" Subject: Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" In-Reply-To: <20031111003855.5c313dd0.bless@tm.uka.de> References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit At 00:38 03/11/11 +0100, Roland Bless wrote: >Hi Naotaka, > >On Fri, 07 Nov 2003 09:36:44 +0900 >"MORITA, Naotaka" wrote: > >> I would like to draw QoS experts attention to the following three documents. >> >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt >> http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt >> >> I am going to make a presentation on Monday morning at TSV WG. > >After reading draft-morita-tsvwg-mfphb-00.txt and attending your >presentation, I have some remarks related to this approach: >- I'm not quite sure whether this is really a PHB definition. > It seems to me, that it is actually a mix of > * a scheme for measured-based admission control and resource provisioning > * a Per-Domain Behavior (see RFC 3086) > * a PHB group description Your understanding is correct, but I do not think it is a mix. The key of the PPS is to utilize PHB for admission control. The proposed new PHB, MF-PHB refers to two-subclasses, but we do not have to define it as a group description. > >- The scheme inherently relies on feedback information and it should be made > clear how the feedback can be provided (you mentioned RTCP as an example, > what about others?). Yes, it is. As the PPS, I would like to describe the feedback mechanims, but for a PHB, we do not have to. > >- Instead of defining a new PHB, possibly two Class Selector PHBs > or even an AF class can be used ("green" packets get high priority after > admission control, "yellow" and "red" packet may be used for probing). > AF usually gives no guarantees for delay and jitter, however, if AF is > provisioned properly, "green" packets may get some guarantee. This kind of disucssion is what I wanted to do. Sorry for spending much time on me presentation only. Are you refering to Three Color Marker in RFC2697 and RFC2698? > >- For security and robustness, it is essential to police the markings > for the higher priority. Otherwise the service guarantees for other users > are violated by a malicious or ill-behaving end-system. Therefore, I think > first-hop routers should do the policing (based on the feedback > information?). I agree. Are there any opinion about the description in pps framework document? Not sufficient? > >- I see some value in the overall approach, but IMHO the proposal may > be turned into a description for a measurement-based > admission control scheme and PDB using Class Selector PHBs. > >I copied to the relevant lists (diffserv-interest and tsvwg) as I'm >interested in other opinions. Me, too. > >Best regards, > Roland > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Nov 10 23:29:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04816 for ; Mon, 10 Nov 2003 23:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ9I-0007XV-FS for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4T49c028975 for tsvwg-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ9F-0007W6-Tx; Mon, 10 Nov 2003 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ8W-0007Ua-4T for tsvwg@optimus.ietf.org; Mon, 10 Nov 2003 23:28:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04761; Mon, 10 Nov 2003 23:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQ8T-0004V9-00; Mon, 10 Nov 2003 23:28:13 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AJQ8T-0004V6-00; Mon, 10 Nov 2003 23:28:13 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AJQ8P-0006FO-00; Tue, 11 Nov 2003 05:28:09 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AJQ8P-0000B6-00; Tue, 11 Nov 2003 05:28:09 +0100 Received: from localhost ([::1] helo=i72mn12.tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AJQ8N-0007vB-00; Tue, 11 Nov 2003 05:28:07 +0100 Date: Tue, 11 Nov 2003 05:28:27 +0100 From: Roland Bless To: "MORITA, Naotaka" Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB Message-Id: <20031111052827.348154fd.bless@tm.uka.de> In-Reply-To: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> References: <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Naotaka, > >After reading draft-morita-tsvwg-mfphb-00.txt and attending your > >presentation, I have some remarks related to this approach: > >- I'm not quite sure whether this is really a PHB definition. > > It seems to me, that it is actually a mix of > > * a scheme for measured-based admission control and resource provisioning ^^^^^^^^sorry, should have been: measurement-based admission control > > * a Per-Domain Behavior (see RFC 3086) > > * a PHB group description > Your understanding is correct, but I do not think it is a mix. > The key of the PPS is to utilize PHB for admission control. Hmm, I disagree here. A PHB usually describes an "externally observable forwarding treatment", basically how a node treats a packet during the forwarding procedure (typically boils down to queue management and scheduling issues). In your case, that both PHBs (MF-H,MF-M) get their own assigned resources (bw limitation) and that MF-M has a higher drop precedence than MF-H. On top of that PHB group you define an admission control procedure with additional traffic conditioning mechanisms (your token bucket descriptions). This fits better to a PDB description in my opinion. And as you state in section 5: The Priority Promotion Scheme can be viewed as a kind of admission control. > The proposed new PHB, MF-PHB refers to two-subclasses, > but we do not have to define it as a group description. What you call "sub-classes" are effectively two different PHBs: you will need two distinct DSCPs and each DSCP will be mapped to a distinct PHB that will cause a specific packet forwarding treatment. RFC 2475 defines a PHB group as "a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously,....". Please, see also RFC 3260 for clarification on the AF class as a PHB group. MF-H makes not much sense without MF-M and vice versa. However, I think your PPS admission control scheme can be applied to an AF class as well as to the CSC PHBs, therefore you don't need two new PHBs. > >- The scheme inherently relies on feedback information and it should be made > > clear how the feedback can be provided (you mentioned RTCP as an example, > > what about others?). > > Yes, it is. As the PPS, I would like to describe the feedback mechanims, > but for a PHB, we do not have to. Yes, for a PHB you don't have to, but that's exactly why admission control should be defined not together with the PHB. EF also requires some form of admission control to achieve the timely forwarding, but admission control procedures are not defined within RFC 3246. Your admission control procedure will not work without feedback, but the PHBs will. Therefore, define a PDB that defines constraints for corresponding PHBs. > >- Instead of defining a new PHB, possibly two Class Selector PHBs > > or even an AF class can be used ("green" packets get high priority after > > admission control, "yellow" and "red" packet may be used for probing). > > AF usually gives no guarantees for delay and jitter, however, if AF is > > provisioned properly, "green" packets may get some guarantee. > > This kind of disucssion is what I wanted to do. > Sorry for spending much time on me presentation only. > Are you refering to Three Color Marker in RFC2697 and RFC2698? Not exactly, because I was not referring to packet marking, but as in those RFCs, I used the color code as an equivalent for the drop precedence (i.e., "green"=AFx1, "yellow"=AFx2, "red"=AFx3). Note that, the AF class definition allows also to implement only two (instead of three) effective different levels of loss probability for an AF class x. > >- For security and robustness, it is essential to police the markings > > for the higher priority. Otherwise the service guarantees for other users > > are violated by a malicious or ill-behaving end-system. Therefore, I think > > first-hop routers should do the policing (based on the feedback > > information?). > > I agree. Are there any opinion about the description in pps framework document? > Not sufficient? Yes, I think some issues in 4.4 need more discussion. E.g., how do you ensure that the feedback information is correct (you only state that "The behavior in the direction from the destination to the source should also be correct")? Some aspects should possibly be moved to the security section. Best regards, Roland _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 11 12:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12991 for ; Tue, 11 Nov 2003 12:46:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaa-0005NG-Cu for tsvwg-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHk4CH020652 for tsvwg-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaX-0005LJ-Dp; Tue, 11 Nov 2003 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaO-0005Kg-C7 for tsvwg@optimus.ietf.org; Tue, 11 Nov 2003 12:45:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12938; Tue, 11 Nov 2003 12:45:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcaM-00072Q-00; Tue, 11 Nov 2003 12:45:50 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AJcaL-00072E-00; Tue, 11 Nov 2003 12:45:50 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlUC028501; Wed, 12 Nov 2003 02:45:47 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlpo001464; Wed, 12 Nov 2003 02:45:47 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjl8H019773; Wed, 12 Nov 2003 02:45:47 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA06351; Wed, 12 Nov 2003 02:45:46 +0900 (JST) Received: from morita-ibmthink.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA08127; Wed, 12 Nov 2003 02:45:44 +0900 (JST) Message-Id: <5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Mon, 10 Nov 2003 23:18:37 -0600 To: Roland Bless From: "MORITA, Naotaka" Subject: Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" In-Reply-To: <20031111052827.348154fd.bless@tm.uka.de> References: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Roland, At 05:28 03/11/11 +0100, Roland Bless wrote: >Hi Naotaka, > >> >After reading draft-morita-tsvwg-mfphb-00.txt and attending your >> >presentation, I have some remarks related to this approach: >> >- I'm not quite sure whether this is really a PHB definition. >> > It seems to me, that it is actually a mix of >> > * a scheme for measured-based admission control and resource provisioning > ^^^^^^^^sorry, should have been: measurement-based >admission control >> > * a Per-Domain Behavior (see RFC 3086) >> > * a PHB group description > >> Your understanding is correct, but I do not think it is a mix. >> The key of the PPS is to utilize PHB for admission control. > >Hmm, I disagree here. A PHB usually describes an >"externally observable forwarding treatment", basically how >a node treats a packet during the forwarding procedure >(typically boils down to queue management and scheduling issues). >In your case, that both PHBs (MF-H,MF-M) get their own assigned >resources (bw limitation) and that MF-M has a higher drop precedence >than MF-H. On top of that PHB group you define an admission >control procedure with additional traffic conditioning mechanisms >(your token bucket descriptions). This fits better to a PDB >description in my opinion. And as you state in section 5: > > The Priority Promotion Scheme can be viewed as a kind of admission > control. That is right. I will check the meaning of PDP. > >> The proposed new PHB, MF-PHB refers to two-subclasses, >> but we do not have to define it as a group description. > >What you call "sub-classes" are effectively two different PHBs: you will >need two distinct DSCPs and each DSCP will be mapped to a distinct PHB >that will cause a specific packet forwarding treatment. RFC 2475 defines >a PHB group as "a set of one or more PHBs that can only be meaningfully >specified and implemented simultaneously,....". Please, see also RFC 3260 >for clarification on the AF class as a PHB group. MF-H makes not much >sense without MF-M and vice versa. However, I think your PPS admission control >scheme can be applied to an AF class as well as to the CSC PHBs, therefore you >don't need two new PHBs. But the important factor is the bandwidth limitation is shared between two sub-classes. Sequence integrity is another one. How do I describe such things by isolated PHBs? Anyway, what is CSC? > >> >- The scheme inherently relies on feedback information and it should be made >> > clear how the feedback can be provided (you mentioned RTCP as an example, >> > what about others?). >> >> Yes, it is. As the PPS, I would like to describe the feedback mechanims, >> but for a PHB, we do not have to. > >Yes, for a PHB you don't have to, but that's exactly why admission control >should be defined not together with the PHB. EF also requires some form of >admission control to achieve the timely forwarding, but admission control >procedures are not defined within RFC 3246. Your admission control procedure >will not work without feedback, but the PHBs will. Therefore, define a PDB >that defines constraints for corresponding PHBs. I see. Again, I will check PDB. > >> >- Instead of defining a new PHB, possibly two Class Selector PHBs >> > or even an AF class can be used ("green" packets get high priority after >> > admission control, "yellow" and "red" packet may be used for probing). >> > AF usually gives no guarantees for delay and jitter, however, if AF is >> > provisioned properly, "green" packets may get some guarantee. >> >> This kind of disucssion is what I wanted to do. >> Sorry for spending much time on me presentation only. >> Are you refering to Three Color Marker in RFC2697 and RFC2698? > >Not exactly, because I was not referring to packet marking, >but as in those RFCs, I used the color code as an equivalent >for the drop precedence (i.e., "green"=AFx1, "yellow"=AFx2, "red"=AFx3). >Note that, the AF class definition allows also to implement only two (instead of >three) effective different levels of loss probability for an AF class x. I will soon show you the difference between srTCM and my proposed two-threshold. > >> >- For security and robustness, it is essential to police the markings >> > for the higher priority. Otherwise the service guarantees for other users >> > are violated by a malicious or ill-behaving end-system. Therefore, I think >> > first-hop routers should do the policing (based on the feedback >> > information?). >> >> I agree. Are there any opinion about the description in pps framework >document? >> Not sufficient? > >Yes, I think some issues in 4.4 need more discussion. E.g., how do you ensure >that the feedback information is correct (you only state that "The behavior >in the direction from the destination to the source should also be correct")? >Some aspects should possibly be moved to the security section. Thank you. I will do that. For the correctness of the feedback information is a target of media monitor server. > >Best regards, > Roland > >_______________________________________________ >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 exim@www1.ietf.org Tue Nov 11 13:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14064 for ; Tue, 11 Nov 2003 13:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd3b-0008Ld-PC for tsvwg-archive@odin.ietf.org; Tue, 11 Nov 2003 13:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABIG3EW032074 for tsvwg-archive@odin.ietf.org; Tue, 11 Nov 2003 13:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd3Z-0008KP-VB; Tue, 11 Nov 2003 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJd2c-0008GS-U4 for tsvwg@optimus.ietf.org; Tue, 11 Nov 2003 13:15:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14022; Tue, 11 Nov 2003 13:14:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJd2a-0007Ob-00; Tue, 11 Nov 2003 13:15:00 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AJd2a-0007OY-00; Tue, 11 Nov 2003 13:15:00 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AJd2S-0002af-00; Tue, 11 Nov 2003 19:14:52 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AJd2R-00009B-00; Tue, 11 Nov 2003 19:14:51 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=i72mn12.tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AJd2Q-0000z4-00; Tue, 11 Nov 2003 19:14:50 +0100 Date: Tue, 11 Nov 2003 19:15:12 +0100 From: Roland Bless To: "MORITA, Naotaka" , diffserv-interest@ietf.org, "'tsvwg@ietf.org'" Subject: Re: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB Message-Id: <20031111191512.0adcff52.bless@tm.uka.de> In-Reply-To: <5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp> References: <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031107093524.04528c98@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031110203629.04c62f88@imj.m.ecl.ntt.co.jp> <5.1.1.11.2.20031110230755.04c76b18@imj.m.ecl.ntt.co.jp> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 10 Nov 2003 23:18:37 -0600 "MORITA, Naotaka" wrote: > That is right. I will check the meaning of PDP. PDB=Per-Domain Behavior, see RFC 3086. > >What you call "sub-classes" are effectively two different PHBs: you will > >need two distinct DSCPs and each DSCP will be mapped to a distinct PHB > >that will cause a specific packet forwarding treatment. RFC 2475 defines > >a PHB group as "a set of one or more PHBs that can only be meaningfully > >specified and implemented simultaneously,....". Please, see also RFC 3260 > >for clarification on the AF class as a PHB group. MF-H makes not much > >sense without MF-M and vice versa. However, I think your PPS admission control > >scheme can be applied to an AF class as well as to the CSC PHBs, therefore you > >don't need two new PHBs. > > But the important factor is the bandwidth limitation is shared between two > sub-classes. Sure, no problem. That's why it is a PHB group. > Sequence integrity is another one. You mean that micro-flows should not be reordered if their packets are marked as MF-H and MF-M alternatingly? This is also a requirement for the PHBs in an AF class. However, I don't see how you achieve this with the implementation described in 4.1 Fig.3: as soon as you have separate queues for MF-H and MF-M, reordering may occur. > How do I describe such things by isolated PHBs? Confer the AF class definition and read RFC3260 in addition to that. > Anyway, what is CSC? Class Selector Compliant PHB, cf. RFC 2474, sec. 4.2.2.2 > I will soon show you the difference between srTCM and my proposed two-threshold. No, you don't have to, I support that there are differences. I'm not referring to the marking scheme, I'm referring to the AF PHB definition. > For the correctness of the feedback information is a target of media > monitor server. I'm not sure whether it is reasonable that the scheme depends on the existence of some additional server. Regards, Roland _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 12 07:00:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14934 for ; Wed, 12 Nov 2003 07:00:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJtfM-0004uD-7O for tsvwg-archive@odin.ietf.org; Wed, 12 Nov 2003 07:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACC07K9018851 for tsvwg-archive@odin.ietf.org; Wed, 12 Nov 2003 07:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJtfG-0004t3-6l; Wed, 12 Nov 2003 07:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJtf7-0004sM-Ij for tsvwg@optimus.ietf.org; Wed, 12 Nov 2003 06:59:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14891 for ; Wed, 12 Nov 2003 06:59:39 -0500 (EST) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJtf3-0005TO-00 for tsvwg@ietf.org; Wed, 12 Nov 2003 06:59:49 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJtf2-0005TL-00 for tsvwg@ietf.org; Wed, 12 Nov 2003 06:59:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACBxnA04018 for ; Wed, 12 Nov 2003 13:59:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 13:59:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 12 Nov 2003 13:59:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Nov 2003 13:59:48 +0200 Message-ID: Thread-Topic: Comments about the PKTDROP SCTP extension Thread-Index: AcOpFHg19GW6yXkpQMm/UPlJhOutNA== To: X-OriginalArrivalTime: 12 Nov 2003 11:59:48.0350 (UTC) FILETIME=[788DB9E0:01C3A914] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Comments about the PKTDROP SCTP extension Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all! I have just read the Packet Drop Reporting extension for SCTP = (http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt)= and I have some quite many comments (as usual ;->): - Page 3, last paragraph, a typo: "middle box peer can be *can be* = located..." - Page 5, new chunk diagram: This is maybe a matter of style and taste = but I liked the way flags are described in other SCTP documents (I mean = in the drawing). What about something like 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 0x81 |Reserved |T|B|M| Chunk Length = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+? - Page 5: I think that the field "Truncated Length" is a little bit = confusing, since it is the length of the datagram before truncating it. = What about "Original SCTP Datagram Length"? - Page 6, beginning, T flag definition: It says that you get the = original packet length "from the IP header". That's really confusing, as = later it is clear that only the SCTP datagram is included (without the = header). I think you should change that and make clear that it is only = the SCTP datagram what's copied in the PKTDROP chunk. Also, up to this = point it is not completely clear whether that length also includes the = SCTP common header... - Page 7, Data Field definition: I think you could make clearer here = that when you speak about the packet you mean just the SCTP packet NOT = including the header... - Section 5.1.1: There are some chunks that a middle box shouldn't send = back to the sender. These are the INIT ACK, SHUTDOWN COMPLETE and any = packet containing an ABORT. It shouldn't because that doesn't make = sense: the sender of such a packet does not have any TCB about that = association any more. So, the PKTDROP would be an OOTB datagram and that = would only originate that an ABORT is sent to the other peer. In fact, in the case the original packet contained an ABORT, the above = might make sense. If it was a SHUTDOWN COMPLETE, it will basically speed up the fatal = destiny of the association (the peer would otherwise retransmit the = SHUTDOWN ACK and get a SHUTDOWN COMPLETE similar to the ABORT it will = get if the middle box sends the PKTDROP). Receiving an ABORT with the = *right* VT and still with the T flag set, instead of a SHUTDOWN COMPLETE = with the T flag set and the reverse VT might be a little bit confusing = though... But if the INIT ACK was lost, that would cause that the establishment = phase is aborted, and that's not good. - Section 5.1.2: The above comment also works for this section. And I = was also thinking if when receiving a corrupted HEARTBEAT ACK it would = make much more sense simple sending back a new HEARTBEAT than the = PKTDROP. Same happens with the SHUTDOWN ACK: better to resend the = SHUTDOWN instead of the PKTDROP since that would speed up the processing = of the datagram at the peer side. I'm not sure but maybe the same happens with corrupted COOKIE ACK and = ASCONF ACK chunks... :-/ - Section 5.2: There are many chunk names written in lower case, such = as "heartbeat", "shutdown acknowledgement", "cookie-ack", "Packet = Drop"... and more. I think they should be written with capital letters = (and the "official" name). - Section 5.2: What happens if one receives a PKTDROP containing an = ASCONF ACK? I think that after carefully checking the serial number, the = receiver of the PKTDROP could resend the ASCONF ACK (at least in the = quite probable case that it stores a copy of the last ASCONF ACK sent). - Section 5.2, page 9: The calculation of "rtt" is very confusing. What = are those values there? Besides, there is a bracket missing... - Section 5.2., page 10: In the formula for bw_avail, you could mention = that dividing the result by 1000 is because the rtt is in milliseconds. = I might be too clumsy but I was wondering whether that value was because = you wanted to give a share of one thousandth to each peer... :-/ - Section 6, Security considerations: I suppose that you have already = though about this, but, as said at the beginning of page 6, middle boxes = are allowed to send a PKTDROP just to state the bandwidth value. What if = the peer wants to speed up the transmission and sends a fake PKTDROP as = being sent by any middle box in between? This can be perfectly done... = I'm not sure whether you should allow any increase in the cwnd at all... = :-/ Ok, that's all (by now! ;->) BR Iv=E1n Arias Rodr=EDguez PS: I suppose this is the right list to send this mail.. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 13 09:16:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27696 for ; Thu, 13 Nov 2003 09:16:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIGV-0004MX-Vu for tsvwg-archive@odin.ietf.org; Thu, 13 Nov 2003 09:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADEG7qc016740 for tsvwg-archive@odin.ietf.org; Thu, 13 Nov 2003 09:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIGQ-0004L1-MO; Thu, 13 Nov 2003 09:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwdD-0006bZ-E0 for tsvwg@optimus.ietf.org; Wed, 12 Nov 2003 10:10:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20697 for ; Wed, 12 Nov 2003 10:09:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwdB-00004Z-00 for tsvwg@ietf.org; Wed, 12 Nov 2003 10:10:05 -0500 Received: from web13805.mail.yahoo.com ([216.136.175.15]) by ietf-mx with smtp (Exim 4.12) id 1AJwdA-00004W-00 for tsvwg@ietf.org; Wed, 12 Nov 2003 10:10:05 -0500 Message-ID: <20031112151004.89695.qmail@web13805.mail.yahoo.com> Received: from [130.129.135.147] by web13805.mail.yahoo.com via HTTP; Wed, 12 Nov 2003 07:10:04 PST Date: Wed, 12 Nov 2003 07:10:04 -0800 (PST) From: jon b To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] IPMP discussion on the IMRG list Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , As mentioned in the meeting on Monday the discussion of IPMP has now moved to the IMRG list at https://www1.ietf.org/mail-archive/working-groups/imrg/current/msg00154.html We invite anyone interested in the topic to participate in the discussion. Jon Bennett _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 18 16:43:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19558 for ; Tue, 18 Nov 2003 16:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMDcs-0002UN-JU for tsvwg-archive@odin.ietf.org; Tue, 18 Nov 2003 16:43:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAILhA8q009529 for tsvwg-archive@odin.ietf.org; Tue, 18 Nov 2003 16:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMDcj-0002TI-Gh; Tue, 18 Nov 2003 16:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMDcf-0002Sr-LY for tsvwg@optimus.ietf.org; Tue, 18 Nov 2003 16:42:57 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19548 for ; Tue, 18 Nov 2003 16:42:45 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AMCwH-0002dK-Ts; Tue, 18 Nov 2003 15:59:09 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: tsvwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Tue, 18 Nov 2003 15:59:09 -0500 Subject: [Tsvwg] Last Call: 'SCTP Partial Reliability Extension' to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Transport Area Working Group to consider the following document: - 'SCTP Partial Reliability Extension ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-12-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 20 14:31:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19909 for ; Thu, 20 Nov 2003 14:31:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuWE-00033e-99 for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 14:31:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJVAwG011750 for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 14:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuW8-00031L-1p; Thu, 20 Nov 2003 14:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMuVX-0002xs-KF for tsvwg@optimus.ietf.org; Thu, 20 Nov 2003 14:30:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19784; Thu, 20 Nov 2003 14:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVU-0000nJ-00; Thu, 20 Nov 2003 14:30:24 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1AMuVT-0000nG-00; Thu, 20 Nov 2003 14:30:23 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hAKJU8LL005206; Thu, 20 Nov 2003 12:30:12 -0700 (MST) Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id hAKJLxF7031929; Thu, 20 Nov 2003 13:21:59 -0600 Message-ID: <3FBD1558.C10047DF@motorola.com> Date: Thu, 20 Nov 2003 13:26:16 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Phelan, Tom" CC: philippe.gentric@philips.com, "'Rosen, Brian'" , avt@ietf.org, dccp@ietf.org, mmusic@ietf.org, TSV WG list References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Tom, It seems to me that you are basically: 1) questioning the fairness of TCP itself and, 2) you want to do something in the app level to outmaneuver TCP so as to achieve your term of fairness. I am not convinced this is the right thing to do with DCCP. I remember similar issue was discussed on tsvwg list (I am cc'ing it). Maybe people in tsvwg can share their thoughts on this as well. regards, -Qiaobing "Phelan, Tom" wrote: > Hi Phillipe, > > The situation I'm worried about is a little different than you describe. > Say you have a 10M bps link, over which there's a 4M bps video stream and a > long-lived TCP app. The TCP app will take the remaining 6M bps, and then > push for more, which might cause the video stream to lose packets. The > video stream then drops to 2M bps, and the TCP app expands to 8M bps. This > hardly seems fair. > > The video app can protect itself from this by transmitting enough more than > 4M bps to buffer itself against the TCP probes. In this case we'd come to a > relatively steady state where both apps are sending roughly 5M bps. This > seems reasonably fair to me, since the TCP app gets what it would get if it > were competing with other TCP apps, and the video app gets to send at its > full rate. > > Tom P. > > > -----Original Message----- > > From: philippe.gentric@philips.com > > [mailto:philippe.gentric@philips.com] > > Sent: Thursday, November 20, 2003 12:23 PM > > To: Phelan, Tom; 'Rosen, Brian' > > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > Brian, all, > > > > It may provide some help in understanding the situation > > to describe your exemple as follows: > > > > * you send video at 4 Mb/s, good. > > > > * it happens that you are competing with (a lot of ) TCP > > > > AND that you want to be fair to it: > > > > * so when that happens you decrease your rate to 2 Mb/s for "a while" > > because otherwise you are not fair. > > > > * but at some moment you will want to come back up to 4 Mb/s right ? > > > > => the point is that the **only way** to know if you "can" > > do that, is to try it.... > > > > regards, > > > > > > Philippe Gentric > > Chief Architect > > Philips Software > > philippe.gentric@philips.com > > http://www.software.philips.com > > > > > > > > > > > > > > > > > > To: > > "'Rosen, Brian'" > > > > cc: > > "'dccp@ietf.org'" > > > > > > "'avt@ietf.org'" > > > > > > "'mmusic@ietf.org'" > > > > "Phelan, Tom" (bcc: > > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > > > Subject: > > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > Sent by: > > Classification: > > > > mmusic-admin@ietf.org > > > > > > > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > Thanks for the comments. See inline ... > > > > Tom P. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, November 20, 2003 11:05 AM > > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > To me, this is just nonsense. > > > I can't imagine anyone deploying such a solution. > > > > > > This is forcing the problem to fit the solution, and it's not > > > the right way to go. If you want it to work, the protocol > > > has to take the characteristics of the flows as they are, and not > > > as you would like them to be. Real time media, streaming > > or realtime, > > > is either constant bit rate, or pretty close to it. That's how it > > > works. Our challenge is to make the protocols work with this data, > > > not change the data, especially silly ideas like doubling the > > > bandwidth. > > > > > > We make video telephones. They nominally send 4 megabits. Would > > > you like us to double that, under any circumstances? > > > > > > I thought not. > > > > Would you prefer to be forced unnecessarily into packet loss > > and a lower > > encoding rate by greedy TCP applications? Or do you have > > another solution? > > > > I don't think I'm forcing the problem to fit the solution, > > just perhaps that > > the problem I'm trying to solve is different than you > > perceive. The problem > > that I'm trying to solve is how can an application that is > > content with a > > maximum bandwidth compete with TCP applications that are > > insatiably greedy, > > in a way that satisfies some concept of fairness in all directions? > > > > The solution that I see is to provide a buffer against TCP > > probing. This > > would involve sending more data than is nominally necessary. > > If the network > > has capacity for more than 4M bps, then why shouldn't a media > > app make use > > of it? A TCP app would. > > > > I must admit that my initial reactions to suggestions like > > this were very > > similar to yours. I encourage you to look at the draft for > > more detail on > > the issues that convinced me otherwise. > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > > Sent: Thursday, November 20, 2003 10:36 AM > > > > To: 'Jonathan Rosenberg' > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > Hi Jonathan, > > > > > > > > Thanks for the comments. The actual proposal is to send up > > > > to double the > > > > nominal transmit rate when there's available bandwidth, and > > > > to reduce the > > > > rate as necessary if there isn't enough bandwidth. This > > > > doubling is to > > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > > media apps and > > > > TCP apps), and to avoid what appears to me to be the > > > > potential for bullying > > > > from TCP applications that want to suck up all the bandwidth > > > > they can. It > > > > doesn't preclude using low-rate codecs, or mean that the > > > > access link must > > > > support the double rate for the connection to function well. > > > > > > > > This recommendation was meant for best-effort environments, > > > > where the voice > > > > traffic receives no special treatment, and must compete with > > > > TCP apps for > > > > network resources. I can see how this would require a > > > > network that gave > > > > special treatment to voice packets to provision double the > > > > capacity, though. > > > > > > > > This fairness problem is difficult. All of the research I'm > > > > familiar with > > > > approaches it from the direction of other apps being fair to > > > > TCP. I'm not > > > > aware of any other methods for ensuring that non-TCP apps get > > > > their fair > > > > share when competing with TCP. If you (or anyone else) knows > > > > of something > > > > I'd appreciate the pointer. > > > > > > > > Tom P. > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > > To: Phelan, Tom > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Tom, > > > > > > > > > > I don't think this solution will be acceptable to many of > > > > the network > > > > > providers of interactive voip services. Many of them are > > > > insistent on > > > > > using low rate codecs, like g.723, in order to reduce the > > > costs of > > > > > capacity in their networks. Doubling the rate would defeat > > > > > the purpose > > > > > of using these low rate codecs in the first place. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > > suggestion that > > > > > > media apps should transmit at up to twice their nominal > > > > > maximum rate, when > > > > > > DCCP allows it, in order to provide protection from > > > competing TCP > > > > > > applications. I know that the first time I heard someone > > > > > make a similar > > > > > > suggestion I was horrified, but as I developed the issues > > > > > it seemed to be > > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > > > Tom P. > > > > > > > > > > > > _______________________________________________ > > > > > > mmusic mailing list > > > > > > mmusic@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > > Chief Technology Officer Parsippany, NJ > > > > 07054-2711 > > > > > dynamicsoft > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > Audio/Video Transport Working Group > > > > avt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 20 17:03:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02123 for ; Thu, 20 Nov 2003 17:03:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwtG-00009b-6C for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 17:03:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKM36MA000571 for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 17:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwtB-00007Q-QU; Thu, 20 Nov 2003 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMwsi-00005g-3v for tsvwg@optimus.ietf.org; Thu, 20 Nov 2003 17:02:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02091; Thu, 20 Nov 2003 17:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMwsf-0004qI-00; Thu, 20 Nov 2003 17:02:29 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1AMwse-0004pe-00; Thu, 20 Nov 2003 17:02:28 -0500 Received: from [192.168.0.101] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 6A1D2246142; Thu, 20 Nov 2003 17:02:31 -0500 (EST) In-Reply-To: <3FBD1558.C10047DF@motorola.com> References: <3FBD1558.C10047DF@motorola.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, "'Rosen, Brian'" , TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com From: Caitlin Bestler Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 16:01:47 -0600 To: Qiaobing Xie X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > Hi, Tom, > > It seems to me that you are basically: 1) questioning the fairness of > TCP itself > and, 2) you want to do something in the app level to outmaneuver TCP > so as to > achieve your term of fairness. > > I am not convinced this is the right thing to do with DCCP. > > I remember similar issue was discussed on tsvwg list (I am cc'ing it). > Maybe > people in tsvwg can share their thoughts on this as well. The fairness of TCP itself could use some questioning -- but I do not believe that is a reason to evade TCP friendly rate control. Eventually, there should be a solution for proper support of predictably variable rate flows that have fixed delivery requirements. But that solution should be developed considering TCP, SCTP and DCCP as a whole. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 20 17:16:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02988 for ; Thu, 20 Nov 2003 17:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5p-0000tx-2v for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKMG4cJ003421 for tsvwg-archive@odin.ietf.org; Thu, 20 Nov 2003 17:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx5m-0000rL-DM; Thu, 20 Nov 2003 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMx4o-0000nV-HE for tsvwg@optimus.ietf.org; Thu, 20 Nov 2003 17:15:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02892; Thu, 20 Nov 2003 17:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4k-00058N-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AMx4j-00057U-00; Thu, 20 Nov 2003 17:14:58 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09118; Thu, 20 Nov 2003 17:14:24 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13114; Thu, 20 Nov 2003 17:14:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 17:14:24 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6102@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Caitlin Bestler'" , Qiaobing Xie Cc: mmusic@ietf.org, TSV WG list , "Phelan, Tom" , avt@ietf.org, dccp@ietf.org, philippe.gentric@philips.com Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide Date: Thu, 20 Nov 2003 17:14:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The reason to "avoid" TCP friendly rate control is, at least so far, because there is no way yet proposed to do it without destroying the usability of the RTP flow. Part of the problem is that the only "rate control" that works is to negotiate an acceptable rate in the signalling before the stream starts. There really isn't any other way to change the rate, at least for interactive streams. For non-interactive streams, you can always buffer more, which allows you some short term variation. I don't think that any of the proposed mechanisms would actually work even in that case, but maybe there is a way to do something. Non interactive streams need CBR averaged over the buffer time. That can be up to seconds in some cases, hundreds of milliseconds in other cases, but over that interval, your goodput must equate to the transmit offer rate times the interval (some small loss rate acceptable). It would be nice if there was a way. I haven't seen one yet. Brian > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, November 20, 2003 5:02 PM > To: Qiaobing Xie > Cc: mmusic@ietf.org; 'Rosen, Brian'; TSV WG list; Phelan, Tom; > avt@ietf.org; dccp@ietf.org; philippe.gentric@philips.com > Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP > Media Guide > > > > On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote: > > > Hi, Tom, > > > > It seems to me that you are basically: 1) questioning the > fairness of > > TCP itself > > and, 2) you want to do something in the app level to > outmaneuver TCP > > so as to > > achieve your term of fairness. > > > > I am not convinced this is the right thing to do with DCCP. > > > > I remember similar issue was discussed on tsvwg list (I am > cc'ing it). > > Maybe > > people in tsvwg can share their thoughts on this as well. > > > The fairness of TCP itself could use some questioning -- but I do not > believe that is a reason to evade TCP friendly rate control. > > Eventually, there should be a solution for proper support of > predictably > variable rate flows that have fixed delivery requirements. But that > solution > should be developed considering TCP, SCTP and DCCP as a whole. > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 21 09:03:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13739 for ; Fri, 21 Nov 2003 09:03:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBsM-0008B9-Kh for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 09:03:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALE3Ace031435 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 09:03:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBsD-00087k-F4; Fri, 21 Nov 2003 09:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANBrl-00087D-Pu for tsvwg@optimus.ietf.org; Fri, 21 Nov 2003 09:02:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13696; Fri, 21 Nov 2003 09:02:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANBrk-0002Y6-00; Fri, 21 Nov 2003 09:02:32 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ANBrj-0002Xl-00; Fri, 21 Nov 2003 09:02:31 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALE20lf024929; Fri, 21 Nov 2003 09:02:00 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 21 Nov 2003 09:01:55 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 09:01:55 -0500 Message-ID: From: "Phelan, Tom" To: "'Qiaobing Xie'" Cc: TSV WG list , "'dccp@ietf.org'" Date: Fri, 21 Nov 2003 09:01:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] RE: [dccp] DCCP Media Guide Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi Qiaobing [trimmed list a bit], > It seems to me that you are basically: 1) questioning the > fairness of TCP itself > and, 2) you want to do something in the app level to > outmaneuver TCP so as to > achieve your term of fairness. The current practice for streaming media is unfair to TCP (well, at least according to the IAB, an opinion that I buy into). If we modify the behavior of streaming media so that it is fair to TCP, we must also be certain that TCP is fair to this new behavior. This bi-directional fairness doesn't seem to have gotten much attention yet. > I am not convinced this is the right thing to do with DCCP. I'd love to hear opinions on this. But if DCCP doesn't give acceptable service for streaming media, then it isn't going to be used for streaming media. Tom Phelan > > I remember similar issue was discussed on tsvwg list (I am > cc'ing it). Maybe > people in tsvwg can share their thoughts on this as well. > > regards, > -Qiaobing > > "Phelan, Tom" wrote: > > > Hi Phillipe, > > > > The situation I'm worried about is a little different than > you describe. > > Say you have a 10M bps link, over which there's a 4M bps > video stream and a > > long-lived TCP app. The TCP app will take the remaining 6M > bps, and then > > push for more, which might cause the video stream to lose > packets. The > > video stream then drops to 2M bps, and the TCP app expands > to 8M bps. This > > hardly seems fair. > > > > The video app can protect itself from this by transmitting > enough more than > > 4M bps to buffer itself against the TCP probes. In this > case we'd come to a > > relatively steady state where both apps are sending roughly > 5M bps. This > > seems reasonably fair to me, since the TCP app gets what it > would get if it > > were competing with other TCP apps, and the video app gets > to send at its > > full rate. > > > > Tom P. > > > > > -----Original Message----- > > > From: philippe.gentric@philips.com > > > [mailto:philippe.gentric@philips.com] > > > Sent: Thursday, November 20, 2003 12:23 PM > > > To: Phelan, Tom; 'Rosen, Brian' > > > Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org' > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > Brian, all, > > > > > > It may provide some help in understanding the situation > > > to describe your exemple as follows: > > > > > > * you send video at 4 Mb/s, good. > > > > > > * it happens that you are competing with (a lot of ) TCP > > > > > > AND that you want to be fair to it: > > > > > > * so when that happens you decrease your rate to 2 Mb/s > for "a while" > > > because otherwise you are not fair. > > > > > > * but at some moment you will want to come back up to 4 > Mb/s right ? > > > > > > => the point is that the **only way** to know if you "can" > > > do that, is to try it.... > > > > > > regards, > > > > > > > > > Philippe Gentric > > > Chief Architect > > > Philips Software > > > philippe.gentric@philips.com > > > http://www.software.philips.com > > > > > > > > > > > > > > > > > > > > > > > > > > > To: > > > "'Rosen, Brian'" > > > > > > cc: > > > "'dccp@ietf.org'" > > > > > > > > > "'avt@ietf.org'" > > > > > > > > > "'mmusic@ietf.org'" > > > > > > "Phelan, Tom" (bcc: > > > Philippe Gentric/MP4-SUR/CE/PHILIPS) > > > > > > Subject: > > > RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Sent by: > > > Classification: > > > > > > mmusic-admin@ietf.org > > > > > > > > > > > > > > > > > > 20/11/2003 17:47 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > Thanks for the comments. See inline ... > > > > > > Tom P. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Thursday, November 20, 2003 11:05 AM > > > > To: 'Phelan, Tom'; 'Jonathan Rosenberg' > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > To me, this is just nonsense. > > > > I can't imagine anyone deploying such a solution. > > > > > > > > This is forcing the problem to fit the solution, and it's not > > > > the right way to go. If you want it to work, the protocol > > > > has to take the characteristics of the flows as they > are, and not > > > > as you would like them to be. Real time media, streaming > > > or realtime, > > > > is either constant bit rate, or pretty close to it. > That's how it > > > > works. Our challenge is to make the protocols work > with this data, > > > > not change the data, especially silly ideas like doubling the > > > > bandwidth. > > > > > > > > We make video telephones. They nominally send 4 > megabits. Would > > > > you like us to double that, under any circumstances? > > > > > > > > I thought not. > > > > > > Would you prefer to be forced unnecessarily into packet loss > > > and a lower > > > encoding rate by greedy TCP applications? Or do you have > > > another solution? > > > > > > I don't think I'm forcing the problem to fit the solution, > > > just perhaps that > > > the problem I'm trying to solve is different than you > > > perceive. The problem > > > that I'm trying to solve is how can an application that is > > > content with a > > > maximum bandwidth compete with TCP applications that are > > > insatiably greedy, > > > in a way that satisfies some concept of fairness in all > directions? > > > > > > The solution that I see is to provide a buffer against TCP > > > probing. This > > > would involve sending more data than is nominally necessary. > > > If the network > > > has capacity for more than 4M bps, then why shouldn't a media > > > app make use > > > of it? A TCP app would. > > > > > > I must admit that my initial reactions to suggestions like > > > this were very > > > similar to yours. I encourage you to look at the draft for > > > more detail on > > > the issues that convinced me otherwise. > > > > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > > > > > Sent: Thursday, November 20, 2003 10:36 AM > > > > > To: 'Jonathan Rosenberg' > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > Subject: [AVT] RE: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > Thanks for the comments. The actual proposal is to send up > > > > > to double the > > > > > nominal transmit rate when there's available bandwidth, and > > > > > to reduce the > > > > > rate as necessary if there isn't enough bandwidth. This > > > > > doubling is to > > > > > allow fair sharing of the chokepoint bandwidth (between DCCP > > > > > media apps and > > > > > TCP apps), and to avoid what appears to me to be the > > > > > potential for bullying > > > > > from TCP applications that want to suck up all the bandwidth > > > > > they can. It > > > > > doesn't preclude using low-rate codecs, or mean that the > > > > > access link must > > > > > support the double rate for the connection to function well. > > > > > > > > > > This recommendation was meant for best-effort environments, > > > > > where the voice > > > > > traffic receives no special treatment, and must compete with > > > > > TCP apps for > > > > > network resources. I can see how this would require a > > > > > network that gave > > > > > special treatment to voice packets to provision double the > > > > > capacity, though. > > > > > > > > > > This fairness problem is difficult. All of the research I'm > > > > > familiar with > > > > > approaches it from the direction of other apps being fair to > > > > > TCP. I'm not > > > > > aware of any other methods for ensuring that non-TCP apps get > > > > > their fair > > > > > share when competing with TCP. If you (or anyone else) knows > > > > > of something > > > > > I'd appreciate the pointer. > > > > > > > > > > Tom P. > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > Sent: Thursday, November 20, 2003 2:32 AM > > > > > > To: Phelan, Tom > > > > > > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org' > > > > > > Subject: Re: [MMUSIC] DCCP Media Guide > > > > > > > > > > > > > > > > > > Tom, > > > > > > > > > > > > I don't think this solution will be acceptable to many of > > > > > the network > > > > > > providers of interactive voip services. Many of them are > > > > > insistent on > > > > > > using low rate codecs, like g.723, in order to reduce the > > > > costs of > > > > > > capacity in their networks. Doubling the rate would defeat > > > > > > the purpose > > > > > > of using these low rate codecs in the first place. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > Phelan, Tom wrote: > > > > > > > > > > > > > > > > > > > Comments will be appreciated. In particular, I make the > > > > > > suggestion that > > > > > > > media apps should transmit at up to twice their nominal > > > > > > maximum rate, when > > > > > > > DCCP allows it, in order to provide protection from > > > > competing TCP > > > > > > > applications. I know that the first time I heard someone > > > > > > make a similar > > > > > > > suggestion I was horrified, but as I developed the issues > > > > > > it seemed to be > > > > > > > necessary. Reactions to this will be appreciated. > > > > > > > > > > > > > > Tom P. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mmusic mailing list > > > > > > > mmusic@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > > > > -- > > > > > > Jonathan D. Rosenberg, Ph.D. 600 > Lanidex Plaza > > > > > > Chief Technology Officer Parsippany, NJ > > > > > 07054-2711 > > > > > > dynamicsoft > > > > > > jdrosen@dynamicsoft.com FAX: > > > (973) 952-5050 > > > > > > http://www.jdrosen.net PHONE: > > > (973) 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Audio/Video Transport Working Group > > > > > avt@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > > > > _______________________________________________ > > dccp IETF mailing list: dccp@ietf.org > > list info: https://www1.ietf.org/mailman/listinfo/dccp > > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 21 10:45:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18567 for ; Fri, 21 Nov 2003 10:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDT7-0006gS-Kf for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALFjDmu025652 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 10:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSw-0006X5-AE; Fri, 21 Nov 2003 10:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDSl-0006V3-6z for tsvwg@optimus.ietf.org; Fri, 21 Nov 2003 10:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18480; Fri, 21 Nov 2003 10:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSi-0003vC-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ANDSh-0003v9-00; Fri, 21 Nov 2003 10:44:48 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hALFilSs004253; Fri, 21 Nov 2003 16:44:47 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFF6ZG50; Fri, 21 Nov 2003 16:44:46 +0100 Message-ID: <3FBE32EC.5000400@ericsson.com> Date: Fri, 21 Nov 2003 16:44:44 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, TSV WG list , avt@ietf.org, dccp@ietf.org CC: "Phelan, Tom" References: <3FBD1558.C10047DF@motorola.com> <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> In-Reply-To: <22EDA8FA-1BA5-11D8-8F72-000393814604@asomi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] DCCP Media Guide - STOP crossposting Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Please don't crosspost to all these lists. It creates problems for the list managers and will fragment the discussion. As long as we are discussing issues related to media and DCCP please keep these topics on the AVT mailing list. Other DCCP related issues goes on the DCCP list. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 21 11:21:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19814 for ; Fri, 21 Nov 2003 11:21:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE1p-0000Bw-6v for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 11:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGL5aD000737 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 11:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE1l-0000Ao-KM; Fri, 21 Nov 2003 11:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANE1a-0000AU-OG for tsvwg@optimus.ietf.org; Fri, 21 Nov 2003 11:20:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19776 for ; Fri, 21 Nov 2003 11:20:37 -0500 (EST) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANE1Z-0004P2-00 for tsvwg@ietf.org; Fri, 21 Nov 2003 11:20:49 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ANE1Z-0004Oz-00 for tsvwg@ietf.org; Fri, 21 Nov 2003 11:20:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALGKlA19532 for ; Fri, 21 Nov 2003 18:20:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Nov 2003 18:20:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 18:20:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Nov 2003 18:20:46 +0200 Message-ID: Thread-Topic: Comments about the PKTDROP SCTP extension Thread-Index: AcOpFHg19GW6yXkpQMm/UPlJhOutNAHMaKLw To: X-OriginalArrivalTime: 21 Nov 2003 16:20:46.0931 (UTC) FILETIME=[6B835230:01C3B04B] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Comments about the PR-SCTP extension Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all! I have read the PR-SCTP extension draft, and I have seen some typos = (which I hate to comment, but since I saw them anyway...) and also I = have couple of comments: - Section 1.2, page 4, second paragraph, a duplicated word: "... IETF = so that *that* the designers..." - Section 3.1, "Length" definition: "Indicate the size...", shouldn't = it be "Indicates the size..."? - Section 3.2, page 8, "Stream Sequence-N" definition: "... report = TSN's co*or*esponding to..." - Section 3.3.1, title of the section (also in the index): This is kind = of silly, but, shouldn't be that "param" be "parameter" instead? - Section 3.3.2, second paragraph: There is a mistaken reference to = RFC2960 as [4] instead of [5]... - Section 3.3.3, page 9: "... COOKIE or as a** unrecognized...", I = would say that "a" should be "an"... :-/ - Section 3.4, page 12, rule C5: Hmm... I think that a very common = situation will be that we have some TSNs unacknowledged, and then the = T3-rtx timer expires (the only one that was running), and then you = decide to abandon all the unacknowledged TSNs and send the FORWARD TSN. = There is no T3-rtx running, so, C5 says that we "MUST assure that at = least one T3-rtx timer is running", so, should be restart it? but, which = one? Another thing that is not so clear for me is which address should we = use for sending the FORWARD TSN... Should we kind of follow the same = criterion than when retransmitting the TSNs themselves? However, the = abandoned TSNs might have been sent to different addresses, so, which = one should be use? Maybe I'm just mistaken but I would say that this is = not clearly stated in the draft... :-/ - Section 3.4, page 12, rule A5: As it is written I think it is a = little bit confusing... I suppose that what you want to mean is that = after a T3 expiration you check whether you have to abandon or not any = TSN, and after that you try to advance the Advanced.Peer.Ack.Point, = right? But that procedure of advancing that variable is stated only in = C2... The others are mostly related with the arrival of a SACK... :-/ Ok, that's all this time! Have a nice weekend! BR Iv=E1n Arias Rodr=EDguez _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 21 11:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22215 for ; Fri, 21 Nov 2003 11:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEcZ-0003Qi-7k for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 11:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALGx3MM013177 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 11:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEcX-0003Oa-1i; Fri, 21 Nov 2003 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANEcJ-0003N5-MZ for tsvwg@optimus.ietf.org; Fri, 21 Nov 2003 11:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22200; Fri, 21 Nov 2003 11:58:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANEcI-0005EH-00; Fri, 21 Nov 2003 11:58:46 -0500 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 1ANEcH-0005Dg-00; Fri, 21 Nov 2003 11:58:45 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 68A0B2456C6; Fri, 21 Nov 2003 11:58:21 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'dccp@ietf.org'" , "'Qiaobing Xie'" From: Caitlin Bestler Subject: Re: [Tsvwg] RE: [dccp] DCCP Media Guide Date: Fri, 21 Nov 2003 10:57:51 -0600 To: "Phelan, Tom" , TSV WG list X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 21, 2003, at 8:01 AM, Phelan, Tom wrote: > Hi Qiaobing [trimmed list a bit], > >> It seems to me that you are basically: 1) questioning the >> fairness of TCP itself >> and, 2) you want to do something in the app level to >> outmaneuver TCP so as to >> achieve your term of fairness. > > The current practice for streaming media is unfair to TCP (well, at > least > according to the IAB, an opinion that I buy into). If we modify the > behavior of streaming media so that it is fair to TCP, we must also be > certain that TCP is fair to this new behavior. This bi-directional > fairness > doesn't seem to have gotten much attention yet. > >> I am not convinced this is the right thing to do with DCCP. > > I'd love to hear opinions on this. But if DCCP doesn't give acceptable > service for streaming media, then it isn't going to be used for > streaming > media. > > Tom Phelan > > Two very good observations. But they lead to some very crucial questions: Is "TCP Friendly Rate Control" unfriendly to an entire class of applications? I believe that is the case. If so, a solution that is wider that an application protocol is called for. If not so, then that application should conform to TCP Friendly Rate Control rather than just declaring itself to be exempt. Is it possible to build a two-pronged rate control solution? My understanding of the position of those that advocate TCP Friendly Rate Control alone is that they do not believe a two-pronged approach is plausible. I am not certain. What I am in agreement on is that it should not be 'n-pronged' where every application that thinks that TCP friendly rate control is unfair to it simply exempts itself and creates its own *separate* flow control. I am a firm believer that *all* applications share the same fundamental assumption about network congestion -- namely that it is a problem caused by *other* applications. If there is to be an alternate to TFRC, it must accommodate virtually *all* other connection-oriented traffic. Otherwise each little turf will "solve" the network congestion problem based upon the above cited universal assumption. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Nov 21 13:28:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25606 for ; Fri, 21 Nov 2003 13:28:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG0i-0002GV-20 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 13:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALIS4Z5008701 for tsvwg-archive@odin.ietf.org; Fri, 21 Nov 2003 13:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG0e-0002DO-Tz; Fri, 21 Nov 2003 13:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANG0A-0002CF-EH for tsvwg@optimus.ietf.org; Fri, 21 Nov 2003 13:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25526; Fri, 21 Nov 2003 13:27:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANG08-0006Z4-00; Fri, 21 Nov 2003 13:27:28 -0500 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 1ANG07-0006YY-00; Fri, 21 Nov 2003 13:27:27 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hALIQvlf010726; Fri, 21 Nov 2003 13:26:57 -0500 (EST) Received: from sonusmail01.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 21 Nov 2003 13:26:51 -0500 Received: by sonusmail01.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 13:26:51 -0500 Message-ID: From: "Phelan, Tom" To: "'Caitlin Bestler'" , "Phelan, Tom" , TSV WG list Cc: "'dccp@ietf.org'" , "'Qiaobing Xie'" Date: Fri, 21 Nov 2003 13:26:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] RE: [dccp] DCCP Media Guide Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi Caitlin, See inline ... Tom Phelan [snipped] > Two very good observations. > > But they lead to some very crucial questions: > > Is "TCP Friendly Rate Control" unfriendly to an entire class of > applications? I don't think TFRC in and of itself is unfriendly - it depends on how you use it. If you employ strategy 3 from the draft, then you could be subject to undesirable effects while competing with other TCP (or TFRC) apps. Strategy 3 bis tries to correct these problems. > I believe that is the case. If so, a solution that is > wider that an > application protocol is called for. If not so, then > that application > should conform to TCP Friendly Rate Control rather than > just declaring > itself to be exempt. Nothing in the draft declares itself exempt from TFRC - all strategies are bound by TFRC. At no time do you transmit faster than TFRC will allow. Sometimes you might transmit slower. > Is it possible to build a two-pronged rate control solution? > > My understanding of the position of those that advocate > TCP Friendly > Rate Control alone is that they do not believe a > two-pronged approach > is plausible. > > I am not certain. What I am in agreement on is that it should > not be 'n-pronged' where every application that thinks that > TCP friendly rate control is unfair to it simply exempts > itself and creates its own *separate* flow control. I don't know whether our current two choices for flow control mechanisms (AIMD, as in TCP, or TFRC) are enough or not. Maybe they are; maybe we need one or two more. Regardless, each application that uses one of these mechanisms must decide how. For some apps it will be simple - always transmit as fast as the flow control allows. For other apps (streaming media being the current topic), it's more complicated. My purpose in the DCCP Media Guide was to ask the question, "Can streaming media apps use TFRC successfully?" Personally, I don't think it answers that question. I hope it does illuminate some of the issues, though. > I am a firm believer that *all* applications share the same > fundamental assumption about network congestion -- namely that > it is a problem caused by *other* applications. > > If there is to be an alternate to TFRC, it must accommodate > virtually *all* other connection-oriented traffic. Otherwise > each little turf will "solve" the network congestion problem > based upon the above cited universal assumption. I don't see why an alternate to TFRC needs to accommodate all other connection-oriented traffic. If we come up with a third congestion control mechanism that satisfies the needs of some set of applications while maintaining "fairness" with TCP and TFRC, that seems OK. That isn't to say that I think we need a third mechanism. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Nov 25 16:32:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11729 for ; Tue, 25 Nov 2003 16:32:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkn1-0002Yk-3N for tsvwg-archive@odin.ietf.org; Tue, 25 Nov 2003 16:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPLW7Lp009807 for tsvwg-archive@odin.ietf.org; Tue, 25 Nov 2003 16:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkmu-0002Y2-RA; Tue, 25 Nov 2003 16:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkml-0002Xm-IY for tsvwg@optimus.ietf.org; Tue, 25 Nov 2003 16:31:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11718 for ; Tue, 25 Nov 2003 16:31:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkmj-0006vI-00 for tsvwg@ietf.org; Tue, 25 Nov 2003 16:31:49 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AOkmi-0006sW-00 for tsvwg@ietf.org; Tue, 25 Nov 2003 16:31:49 -0500 Received: from chiimc01.npac.com (chiimc01.neustar.com [10.32.90.4]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hAPLVIb9028441 for ; Tue, 25 Nov 2003 21:31:18 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 15:31:20 -0600 Message-ID: From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Date: Tue, 25 Nov 2003 15:31:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The chairs would like to announce a two-week Working Group Last Call for draft-ietf-tsvwg-tcp-eifel-response-04, commencing on November 26th and concluding on December 10th. Please send any final comments relating to this document to the TSVWG mailing list. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-04.t xt Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 26 07:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05030 for ; Wed, 26 Nov 2003 07:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOz8L-00089a-1u for tsvwg-archive@odin.ietf.org; Wed, 26 Nov 2003 07:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQCp55O031338 for tsvwg-archive@odin.ietf.org; Wed, 26 Nov 2003 07:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOz8I-00088U-09; Wed, 26 Nov 2003 07:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOz81-000885-Q7 for tsvwg@optimus.ietf.org; Wed, 26 Nov 2003 07:50:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05017 for ; Wed, 26 Nov 2003 07:50:32 -0500 (EST) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOz80-0004wY-00 for tsvwg@ietf.org; Wed, 26 Nov 2003 07:50:45 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOz80-0004wV-00 for tsvwg@ietf.org; Wed, 26 Nov 2003 07:50:44 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQCohQ07925 for ; Wed, 26 Nov 2003 14:50:43 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Nov 2003 14:50:41 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 14:50:41 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 26 Nov 2003 14:50:39 +0200 Message-ID: Thread-Topic: Comments about the PKTDROP SCTP extension Thread-Index: AcOpFHg19GW6yXkpQMm/UPlJhOutNAHMaKLwAMgwBjA= To: X-OriginalArrivalTime: 26 Nov 2003 12:50:41.0822 (UTC) FILETIME=[E65913E0:01C3B41B] Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Comments about the AddIP SCTP extension Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all! Having read the latest version of the extension, I have the following = comments: - Section 3.1.1, page 5, a typo: "in RFC2960 [5], *forall* variable = parameters." - Section 3.2: Here we can read that there are some parameters that can = be sent in the INIT/INIT ACK and some that should go in the ASCONF = chunk. But, what it is not stated is what happens if the peer for = example includes a Delete IP Address parameter. He looks to have a bug, = so probably the best thing would be sending back an ABORT... :-/ - Section 3.2: The Error Cause Indication and Success Indication = parameters cannot be included in the INIT ACK. So, I assume there isn't = any way the INIT receiver could negatively answer to a Set Primary = Address... Probably it is not that important, since the receiver of such = a parameter is not really forced to do anything, but it could be = interesting to be able to do so... - Section 3.3.4, top of page 16: It says "... no more than 2^^31 = greater than...", I think it should say "... no more than 2^^31 - 1 = greater than...". - Section 4.1, A2): Here we see a SHOULD (about the initialization of = the serial number) while in section 4.2, C1) we see a MUST (about the = same value). I imagine that it should state MUST in both places... - Section 4.1, A9), a typo: "... it did not recognized the...", if my = teachers taught me the right English grammar, I suppose it should be = "... it did not recognize the..." :-) - Section 4.1.1, R4): Does it make any sense to be able to send ASCONF = chunks while in the SHUTDOWN-RECEIVED state (and SHUTDOWN-PENDING state, = especially if the ASCONF is a retransmission)? And same for ASCONF ACK = chunks while in the SHUTDOWN-SENT state, and especially, while in the = SHUTDOWN-PENDING... - Section 4.3.1: Maybe, checking whether the ABORT has the T flag set = or not would help identifying those "false" ABORTs that may be = received... - Section 6, another small typo: "... is a 32 bit *interger* that = is..." Ok, that's all. Thanks! BR Iv=E1n Arias Rodr=EDguez _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Nov 26 13:39:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20904 for ; Wed, 26 Nov 2003 13:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4ZF-0007ee-Mm for tsvwg-archive@odin.ietf.org; Wed, 26 Nov 2003 13:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQIdDOL029423 for tsvwg-archive@odin.ietf.org; Wed, 26 Nov 2003 13:39:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4Z4-0007dK-1A; Wed, 26 Nov 2003 13:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP4YH-0007a3-Ki for tsvwg@optimus.ietf.org; Wed, 26 Nov 2003 13:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20873 for ; Wed, 26 Nov 2003 13:37:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP4YF-0002Wo-00 for tsvwg@ietf.org; Wed, 26 Nov 2003 13:38:11 -0500 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1AP4YE-0002WD-00 for tsvwg@ietf.org; Wed, 26 Nov 2003 13:38:10 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id hAQIbV5T071743; Wed, 26 Nov 2003 12:37:31 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FC4F2EA.3000704@stewart.chicago.il.us> Date: Wed, 26 Nov 2003 12:37:30 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments about the PR-SCTP extension References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id hAQIbV5T071743 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I have read the PR-SCTP extension draft, and I have seen some typos (wh= ich I hate to comment, but since I saw them anyway...) and also I have co= uple of comments: > > - Section 1.2, page 4, second paragraph, a duplicated word: "... IETF s= o that *that* the designers..." > > - Section 3.1, "Length" definition: "Indicate the size...", shouldn't i= t be "Indicates the size..."? > > - Section 3.2, page 8, "Stream Sequence-N" definition: "... report TSN'= s co*or*esponding to..." > > - Section 3.3.1, title of the section (also in the index): This is kind= of silly, but, shouldn't be that "param" be "parameter" instead? > > - Section 3.3.2, second paragraph: There is a mistaken reference to RFC= 2960 as [4] instead of [5]... > > - Section 3.3.3, page 9: "... COOKIE or as a** unrecognized...", I woul= d say that "a" should be "an"... :-/ > =20 > Thanks for the typos.. I found them all ;->=20 Now to your other questions... > - Section 3.4, page 12, rule C5: Hmm... I think that a very common situ= ation will be that we have some TSNs unacknowledged, and then the T3-rtx = timer expires (the only one that was running), and then you decide to aba= ndon all the unacknowledged TSNs and send the FORWARD TSN. There is no T3= -rtx running, so, C5 says that we "MUST assure that at least one T3-rtx t= imer is running", so, should be restart it? but, which one? > =20 > I don't think that it matters. The point of having the T3 timer running=20 is that if it is NOT running (as you illustrate above) and the FWD-TSN is lost.. then you have a kind of=20 deadlock scenario.. not really a dead lock.. but until the sender of the FWD-TSN sends some new data it=20 will never know to resend the FWD-TSN. Thus the receiver will possibly be stuck with some=20 out-of-order data on queue and never send it up to the upper layer until new data is sent... not really=20 what you want I think... So, as long as one tiemr is running the job will get done i.e. it will go off=20 and then cause you to resend the FWD-TSN. I suppose we could add a Implementation note like: " IMPLEMENTATION NOTE: Any destination's timer may be used for the purposes of rule C5. " > Another thing that is not so clear for me is which address should we us= e for sending the FORWARD TSN... Should we kind of follow the same criter= ion than when retransmitting the TSNs themselves? However, the abandoned = TSNs might have been sent to different addresses, so, which one should be= use? Maybe I'm just mistaken but I would say that this is not clearly st= ated in the draft... :-/ > > =20 > I think again it does not really matter, as long as the address is=20 "confirmed" (see the I-Gv10 which was sent in during the IETF)... So maybe a note after C3 stating: IMPLEMENTATION NOTE: It is an implemenation decision as to which destination address is to be sent to, the only restriction being that the address MUST be one that is CONFIRMED. > - Section 3.4, page 12, rule A5: As it is written I think it is a littl= e bit confusing... I suppose that what you want to mean is that after a T= 3 expiration you check whether you have to abandon or not any TSN, and af= ter that you try to advance the Advanced.Peer.Ack.Point, right? But that = procedure of advancing that variable is stated only in C2... The others a= re mostly related with the arrival of a SACK... :-/ > > =20 > Hmm in looking at the rules I must disagree and agree :-> Rule C1 has to do with a SACK... Rule C2 has to do with how you figure out if you have an advance peer ack point. Rule C3 tells you that you must send a FWD-TSN (possibly) Rule C4 tells you that you must back it down if you have some data that is not partially reliable between the last sack point and the advance=20 peer ack point. Rule C5 tells you that you must maintain your timer.. So really A5 should use the procedures outlined in C2-5 not C1-5.. So I guess we can consider these IETF-Last-Call comments aka.. 1) Fix typos. 2) add two implementation notes 3) correct sequecne range in A5 to C2-C5 instead of C1-C5 Does this sound ok to you Ivan? R R > Ok, that's all this time! > > Have a nice weekend! > > BR Iv=E1n Arias Rodr=EDguez > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > =20 > --=20 Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Nov 27 05:25:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02584 for ; Thu, 27 Nov 2003 05:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJKd-0002FE-2n for tsvwg-archive@odin.ietf.org; Thu, 27 Nov 2003 05:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARAP6db008618 for tsvwg-archive@odin.ietf.org; Thu, 27 Nov 2003 05:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJKY-0002EA-43; Thu, 27 Nov 2003 05:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APJJy-0002Dp-Af for tsvwg@optimus.ietf.org; Thu, 27 Nov 2003 05:24:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02580 for ; Thu, 27 Nov 2003 05:24:11 -0500 (EST) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APJJu-0006CF-00 for tsvwg@ietf.org; Thu, 27 Nov 2003 05:24:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1APJJt-0006CC-00 for tsvwg@ietf.org; Thu, 27 Nov 2003 05:24:22 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hARAOMM07913 for ; Thu, 27 Nov 2003 12:24:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Nov 2003 12:24:22 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 12:24:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 12:24:22 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Tsvwg] Comments about the PR-SCTP extension Date: Thu, 27 Nov 2003 12:24:21 +0200 Message-ID: Thread-Topic: [Tsvwg] Comments about the PR-SCTP extension Thread-Index: AcO0THS+CVMeMEC4Slmp2PtQ5ULqJQAfqS3A To: Cc: X-OriginalArrivalTime: 27 Nov 2003 10:24:22.0064 (UTC) FILETIME=[9F9E1300:01C3B4D0] Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all! See my comments inline... > > - Section 3.4, page 12, rule C5: Hmm... I think that a=20 > very common situation will be that we have some TSNs=20 > unacknowledged, and then the T3-rtx timer expires (the only=20 > one that was running), and then you decide to abandon all the=20 > unacknowledged TSNs and send the FORWARD TSN. There is no=20 > T3-rtx running, so, C5 says that we "MUST assure that at=20 > least one T3-rtx timer is running", so, should be restart it?=20 > but, which one? > > =20 > > >=20 > I don't think that it matters. The point of having the T3=20 > timer running=20 > is that if it is NOT running (as you > illustrate above) and the FWD-TSN is lost.. then you have a kind of=20 > deadlock scenario.. not really > a dead lock.. but until the sender of the FWD-TSN sends some=20 > new data it=20 > will never know to resend > the FWD-TSN. Thus the receiver will possibly be stuck with some=20 > out-of-order data on queue and > never send it up to the upper layer until new data is sent...=20 > not really=20 > what you want I think... So, as > long as one tiemr is running the job will get done i.e. it=20 > will go off=20 > and then cause you to resend > the FWD-TSN. >=20 > I suppose we could add a Implementation note like: > " > IMPLEMENTATION NOTE: Any destination's timer may be used for the > purposes of rule C5. > " Yeah, you are completely right... In fact, the point of this comment = (and the next one) was that I was thinking that, since the FWD-TSN is = acknowledged as the DATA chunks are, you were also performing that = retransmission counter reset when the SACK arrives, or an increase plus = cwnd shrink and RTO doubling and so on... But since that's not the case (by the way, which is the reason not to = do so?), then I agree that the destination doesn't really matter = (however, I think that any implementer will try to send the FWD-TSN to a = different address than the previously used)... > > Another thing that is not so clear for me is which=20 > address should we use for sending the FORWARD TSN... Should=20 > we kind of follow the same criterion than when retransmitting=20 > the TSNs themselves? However, the abandoned TSNs might have=20 > been sent to different addresses, so, which one should be=20 > use? Maybe I'm just mistaken but I would say that this is not=20 > clearly stated in the draft... :-/ > > > > =20 > > >=20 > I think again it does not really matter, as long as the address is=20 > "confirmed" (see the I-Gv10 which was > sent in during the IETF)... >=20 > So maybe a note after C3 stating: > > IMPLEMENTATION NOTE: It is an implemenation decision as to which > destination address is to be sent to, the only restriction > being that the address MUST be one that is CONFIRMED. > Same comment also applies here. The NOTE sounds good for me, but mind = that "implemenation" typo ;-) > > - Section 3.4, page 12, rule A5: As it is written I=20 > think it is a little bit confusing... I suppose that what you=20 > want to mean is that after a T3 expiration you check whether=20 > you have to abandon or not any TSN, and after that you try to=20 > advance the Advanced.Peer.Ack.Point, right? But that=20 > procedure of advancing that variable is stated only in C2...=20 > The others are mostly related with the arrival of a SACK... :-/ > > > > =20 > > > Hmm in looking at the rules I must disagree and agree :-> >=20 > Rule C1 has to do with a SACK... Yes... > Rule C2 has to do with how you figure out if you have > an advance peer ack point. I agree... > Rule C3 tells you that you must send a FWD-TSN (possibly) Yes but here there is a comment about the received SACK... In fact, = thinking about it, since you firstly process normally the SACK, I don't = think you even have to mention the SACK at all, since the value of the = "Cumulative TSN Ack Point" must have been already updated at this stage, = being equal to the "Cumulative TSN ACK carried in the received SACK"... Hmm... now that I see it, A4) mentions the normal processing procedure = for SACKs as stated in 6.2.1, but that section basically deals with the = rwnd only... Weird that 6.2.1 in the RFC doesn't give any pointer to = sections 7.2.1 and 7.2.2, which depict the "real" steps you take when = receiving a SACK, and only mentions 7.2.4... :-/ Well, also 8.1 and 8.2 = are very important sections regarding SACK processing... I hadn't taken a look to the section 6.2.1 when I firstly read the = draft, but now that I have gone through it, it makes me feel kind of = uncomfortable (not for the draft, but for the RFC itself)... :-/ > Rule C4 tells you that you must back it down if you have some=20 > data that > is not partially reliable between the last sack point and the advance=20 > peer ack point. Yes. > Rule C5 tells you that you must maintain your timer.. Exactly. > So really A5 should use the procedures outlined in C2-5 not C1-5.. Yes, you are right... Only that the C3 is also SACK-related as it is = written... > So I guess we can consider these IETF-Last-Call comments aka.. >=20 > 1) Fix typos. >=20 > 2) add two implementation notes >=20 > 3) correct sequecne range in A5 to C2-C5 instead of C1-C5 >=20 >=20 > Does this sound ok to you Ivan? It does! Thanks! BR Iv=E1n Arias Rodr=EDguez > R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Nov 29 16:20:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27042 for ; Sat, 29 Nov 2003 16:20:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQCVc-0002Io-4J for tsvwg-archive@odin.ietf.org; Sat, 29 Nov 2003 16:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATLK7SX008830 for tsvwg-archive@odin.ietf.org; Sat, 29 Nov 2003 16:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQCVX-0002I9-Vq; Sat, 29 Nov 2003 16:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfvV-0008Eq-DA for tsvwg@optimus.ietf.org; Fri, 28 Nov 2003 05:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22468 for ; Fri, 28 Nov 2003 05:32:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfvR-00076B-00 for tsvwg@ietf.org; Fri, 28 Nov 2003 05:32:37 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1APfvQ-000768-00 for tsvwg@ietf.org; Fri, 28 Nov 2003 05:32:37 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAS9u0Q01988 for ; Fri, 28 Nov 2003 11:56:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Nov 2003 11:55:58 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 11:55:58 +0200 Received: from localhost.localdomain (hed041-186.research.nokia.com [172.21.41.186]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA09631 for ; Fri, 28 Nov 2003 11:56:02 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hASBubvw027611 for ; Fri, 28 Nov 2003 13:56:37 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hASBuaKZ027610; Fri, 28 Nov 2003 13:56:36 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: tsvwg@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Fri, 28 Nov 2003 13:56:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 28 Nov 2003 09:55:58.0537 (UTC) FILETIME=[D2A63B90:01C3B595] Subject: [Tsvwg] SCTP and fragmentation at IP level Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hello all, In the section 2.16 of draft-ietf-tsvwg-sctpimpguide-09.txt the fragmentation and reassembly section says (new text): ... If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message. Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However in so doing, it MUST react just like an implementation that does NOT support fragmentation i.e. it MUST reject sends that exceed the current P-MTU. So, if we play the game widely known as "Say it in ALL CAPS" (a variation of "Simon says", ages 15 to 65) the 2960 could be interpreted allowing that if the SCTP implementation does not support fragmentation, it may as well try to send a message exceeding path MTU as a single IP datagram (that will be fragmented). Now the note in sctpimpguide seems to contradict the end of first paragraph. WOuld it be a nice idea not to play the game in first paragraph and do it in caps, like "the endpoint MUST return an error", "the endpoint SHOULD return an error" or "the endpoint MAY return an error"? --Pekka _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg