From mailman-bounces@ietf.org Fri Oct 1 08:02:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21771 for ; Fri, 1 Oct 2004 08:02:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMFn-0005bD-J5 for tsvwg-archive@ietf.org; Fri, 01 Oct 2004 08:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJvZ-0005Zm-Hv for tsvwg-archive@ietf.org; Fri, 01 Oct 2004 05:42:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:17:14 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for tsvwg-archive@ietf.org: List Password // URL ---- -------- tsvwg@ietf.org xeowbe https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org From tsvwg-bounces@ietf.org Thu Oct 7 06:00:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29459; Thu, 7 Oct 2004 06:00:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFVEk-0008HN-DP; Thu, 07 Oct 2004 06:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFV2w-0008Vr-Eg; Thu, 07 Oct 2004 05:58:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFUvI-0006X1-PC for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 05:50:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28329 for ; Thu, 7 Oct 2004 05:50:53 -0400 (EDT) Received: from web51504.mail.yahoo.com ([206.190.38.196]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFV4y-0007bj-IJ for tsvwg@ietf.org; Thu, 07 Oct 2004 06:00:57 -0400 Message-ID: <20041007095025.91925.qmail@web51504.mail.yahoo.com> Received: from [194.237.142.5] by web51504.mail.yahoo.com via HTTP; Thu, 07 Oct 2004 11:50:25 CEST Date: Thu, 7 Oct 2004 11:50:25 +0200 (CEST) From: Salvatore Loreto To: lksctp-developers@lists.sourceforge.net, tsvwg@ietf.org, sctp-impl@external.cisco.com MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: alefelici@libero.it, gonzalo.camarillo@ericsson.com, pawel.hadam@imag.fr Subject: [Tsvwg] sctp performance X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1987548018==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============1987548018== Content-Type: multipart/alternative; boundary="0-185882640-1097142625=:88488" --0-185882640-1097142625=:88488 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, reading the experiments on SCTP performance LKSCTP http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm OPENSS7 http://www.openss7.org/sctp_perf.html If we ignore the gap underline between TCP and SCTP in LKSCTP, becose due to implementation problem ( and I think now the situation is better, isn't it? does someone have up to date results about?) and use just the result underline on OPENSSS7 I've some questions/doubts and I'd like know you opinion about: 1) the test SCTP with 1 interface shows a substanzial equivalent to TCP. Is it possible SCTP with 1 interface is TCP, or if you want if there is not HoL block there are not difference between two protocols due to the same congestion algorithm. 2) SCTP with 2 interface has a better performance just for message size greater than 64-byte. But SCTP was born for Signaling transport, and signaling messages are yes lager than 64-bye but not very large. when in the experiment is used SOCK_SEQPACKET 3) the real start up with 1 or 2 interfaces are both worse than the Theoretical one. The strange is the reale one with 2 interfaces is worse than the reale one with just one interface. 4) similar considerations ( done above ) could be done also for the other phases . So SOCK_SEQPACKET seems not so good. regards sal --------------------------------- Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai virus! --0-185882640-1097142625=:88488 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi all,
 
reading the experiments on SCTP performance
 
LKSCTP
 
If we ignore the gap underline between TCP and SCTP in LKSCTP, becose due to implementation problem ( and I think now the situation is better, isn't it? does someone have up to date results about?)
and use just the result underline on OPENSSS7
 
I've some questions/doubts and I'd like know you opinion about:
 
1) the test SCTP with 1 interface shows a substanzial equivalent to TCP.
Is it possible SCTP with 1 interface is TCP, or if you want if there is   not HoL block there are not difference between two protocols due to the same congestion algorithm.
 
2) SCTP with 2 interface has a better performance just for message size greater than 64-byte.
But SCTP was born for Signaling transport, and signaling messages are yes lager than 64-bye but not very large.
 
when in the experiment is used SOCK_SEQPACKET
3) the real start up with 1 or 2 interfaces are both worse than the Theoretical one. The strange is the reale one with 2 interfaces is worse than the reale one with just one interface.
4) similar considerations ( done above ) could be done also for the other phases . So SOCK_SEQPACKET seems not so good.
 
 
regards
sal

 
 

Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai virus! --0-185882640-1097142625=:88488-- --===============1987548018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1987548018==-- From tsvwg-bounces@ietf.org Thu Oct 7 08:25:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10499; Thu, 7 Oct 2004 08:25:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFXUO-0000O7-2K; Thu, 07 Oct 2004 08:35:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXEn-0005q9-JK; Thu, 07 Oct 2004 08:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXAj-0004gH-1X for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 08:15:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09677 for ; Thu, 7 Oct 2004 08:14:59 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[GwivgIJU4n4q/MInqJPyDw4YS1CQjook]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFXKG-0008DA-0D for tsvwg@ietf.org; Thu, 07 Oct 2004 08:25:02 -0400 Received: from ns.pigworks.openss7.net (IDENT:sxWZN6wQ6RLrta9N9HHVqgaTMqTPvJ68@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i97CBUJ25211; Thu, 7 Oct 2004 06:11:30 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i97CBTl18614; Thu, 7 Oct 2004 06:11:29 -0600 Date: Thu, 7 Oct 2004 06:11:29 -0600 From: "Brian F. G. Bidulock" To: Salvatore Loreto Subject: Re: [Tsvwg] sctp performance Message-ID: <20041007061129.A17650@openss7.org> References: <20041007095025.91925.qmail@web51504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041007095025.91925.qmail@web51504.mail.yahoo.com>; from loretosal@yahoo.it on Thu, Oct 07, 2004 at 11:50:25AM +0200 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 i97CBUJ25211 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: alefelici@libero.it, tsvwg@ietf.org, sctp-impl@external.cisco.com, gonzalo.camarillo@ericsson.com, lksctp-developers@lists.sourceforge.net, pawel.hadam@imag.fr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Salvatore, Performance tests on a clean network do not exercise SCTP's strong points. SCTP was not really intended to outperform TCP on a clean network with a single interface: it was intended to outperform TCP on a real network with noise, failures and reconfiguration. If you look at even single stream tests under noise SCTP rapidly outperforms TCP in dirty networks. The SOCK_SEQPACKET test deviation from theoretical is probably more of a software glitch in bundling, Nagle'ing and Minshall'ing in the OpenSS7 stack more than a problem with the protocol (that was noted in the results). The SOCK_STREAM tests on a single interface did outperform TCP, however, note that the tests saturated the network and both are running very close to theoretical maximums. The interesting thing about the OpenSS7 tests were the multiple interface tests on SOCK_STREAM, that showed that max throughput was a multiple of the number of available interfaces. Once TCP saturates a single interface it has nowhere else to go. SCTP can load multiple interfaces to saturation. These were throughput tests. Latency tests show SCTP has comparable results to TCP (with slight improvements) on clean networks, and SCTP exhibits significant reduced latencies to TCP under even as little as 5% noise. On distrupted networks (50% interface failure on a 1 or 2 second duty cycle) TCP stops and SCTP continues. There are a lot of good papers out there testing more real environments as well as NS-2 simulations that demonstrate the benefits of SCTP over TCP for its original intended application, telephony signalling. Search on "SCTP Performance" and you can read for the better part of a day. --brian On Thu, 07 Oct 2004, Salvatore Loreto wrote: >=20 > Hi all, >=20 >=20 >=20 > reading the experiments on SCTP performance >=20 >=20 >=20 > LKSCTP >=20 > [1]http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm >=20 > OPENSS7 > [2]http://www.openss7.org/sctp_perf.html >=20 >=20 >=20 > If we ignore the gap underline between TCP and SCTP in LKSCT= P, > becose due to implementation problem ( and I think now t= he > situation is better, isn't it? does someone have up to date resul= ts > about?) >=20 > and use just the result underline on OPENSSS7 >=20 >=20 >=20 > I've some questions/doubts and I'd like know you opinion about: >=20 >=20 >=20 > 1) the test SCTP with 1 interface shows a substanzial equivalent = to > TCP. >=20 > Is it possible SCTP with 1 interface is TCP, or if you want if the= re > is not HoL block there are not difference between two protocols d= ue > to the same congestion algorithm. >=20 >=20 >=20 > 2) SCTP with 2 interface has a better performance just for messa= ge > size greater than 64-byte. >=20 > But SCTP was born for Signaling transport, and signaling messages a= re > yes lager than 64-bye but not very large. >=20 >=20 >=20 > when in the experiment is used SOCK_SEQPACKET >=20 > 3) the real start up with 1 or 2 interfaces are both worse than t= he > Theoretical one. The strange is the reale one with 2 interfaces = is > worse than the reale one with just one interface. >=20 > 4) similar considerations ( done above ) could be done also for t= he > other phases . So SOCK_SEQPACKET seems not so good. >=20 >=20 >=20 >=20 >=20 > regards >=20 > sal >=20 >=20 >=20 >=20 > _________________________________________________________________ >=20 > [3]Yahoo! Mail ti protegge gratis dalla posta indesiderata e d= ai > virus! >=20 > References >=20 > 1. http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm > 2. http://www.openss7.org/sctp_perf.html > 3. http://it.rd.yahoo.com/mail/taglines/*http://it.mail.yahoo.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 09:04:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13363; Thu, 7 Oct 2004 09:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFY62-0002oO-CM; Thu, 07 Oct 2004 09:14:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXob-0004BV-3J; Thu, 07 Oct 2004 08:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFXln-0003UD-9J for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 08:53:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12377 for ; Thu, 7 Oct 2004 08:53:17 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFXvU-00028b-Tr for tsvwg@ietf.org; Thu, 07 Oct 2004 09:03:21 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2004 05:57:57 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97CqiEE026779; Thu, 7 Oct 2004 05:52:45 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AZT91563; Thu, 7 Oct 2004 05:51:26 -0700 (PDT) Message-ID: <41653B7A.7020302@cisco.com> Date: Thu, 07 Oct 2004 08:50:02 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brian F. G. Bidulock" , Salvatore Loreto Subject: Re: [Tsvwg] sctp performance References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> In-Reply-To: <200410071215.i97CF6Z4020379@nailgun.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: alefelici@libero.it, tsvwg@ietf.org, sctp-impl@external.cisco.com, gonzalo.camarillo@ericsson.com, lksctp-developers@lists.sourceforge.net, pawel.hadam@imag.fr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Brian/Salvatore: Just a couple of comments... Brian F. G. Bidulock wrote: > Salvatore, > > Performance tests on a clean network do not exercise SCTP's strong > points. SCTP was not really intended to outperform TCP on a clean > network with a single interface: it was intended to outperform TCP on a > real network with noise, failures and reconfiguration. If you look at > even single stream tests under noise SCTP rapidly outperforms TCP in > dirty networks. > > The SOCK_SEQPACKET test deviation from theoretical is probably more of a > software glitch in bundling, Nagle'ing and Minshall'ing in the OpenSS7 > stack more than a problem with the protocol (that was noted in the > results). I would tend to agree with Brian here.. SOCK_SEQPACKET is really an implementation shade.. In KAME other than controlling a few minor things all the same code runs... so it sould make very little difference.... > > The SOCK_STREAM tests on a single interface did outperform TCP, however, > note that the tests saturated the network and both are running very > close to theoretical maximums. > > The interesting thing about the OpenSS7 tests were the multiple > interface tests on SOCK_STREAM, that showed that max throughput was a > multiple of the number of available interfaces. Once TCP saturates > a single interface it has nowhere else to go. SCTP can load multiple > interfaces to saturation. > > These were throughput tests. Latency tests show SCTP has comparable > results to TCP (with slight improvements) on clean networks, and > SCTP exhibits significant reduced latencies to TCP under even as little > as 5% noise. On distrupted networks (50% interface failure on a 1 or > 2 second duty cycle) TCP stops and SCTP continues. > > There are a lot of good papers out there testing more real environments > as well as NS-2 simulations that demonstrate the benefits of SCTP over > TCP for its original intended application, telephony signalling. Search > on "SCTP Performance" and you can read for the better part of a day. > A couple of other things: a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which was NOT performance tuned at all.. I am not even sure if they have completed a pass yet of tuning.. I know its on their to-do list. b) IPERF ... which is used on both sites.. to me.. is NOT a very good benchmark. SCTP sends "messages" from one end to the other. TCP sends a byte stream from one end to the other. You then take and use IPERF to test the number of bytes streaming from one end to the other. This puts SCTP at a dis-advantage. Especially considering that MOST ALL applications send messages NOT streams of bytes. So if you added some additional overhead to TCP.. say framing messages at the app layer.. this would slow TCP down I would wager. I have always wanted to develop a variable message sender that could send a sequence of variable messages and get a reading of messages per second for various sizes.... c) CRC32c is extremely expensive (in overall terms of CPU use) on the TCP side they generally have an off-load engine they can use to not even do the c-sum... so in such a case when you begin to get CPU limited SCTP will lag behind TCP... just on the checksum basis alone. Bottom line is once you get CRC32c offload SCTP will be able to do a bit better :-D Regards R > --brian > > On Thu, 07 Oct 2004, Salvatore Loreto wrote: > > >> Hi all, >> >> >> >> reading the experiments on SCTP performance >> >> >> >> LKSCTP >> >> [1]http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm >> >> OPENSS7 >> [2]http://www.openss7.org/sctp_perf.html >> >> >> >> If we ignore the gap underline between TCP and SCTP in LKSCTP, >> becose due to implementation problem ( and I think now the >> situation is better, isn't it? does someone have up to date results >> about?) >> >> and use just the result underline on OPENSSS7 >> >> >> >> I've some questions/doubts and I'd like know you opinion about: >> >> >> >> 1) the test SCTP with 1 interface shows a substanzial equivalent to >> TCP. >> >> Is it possible SCTP with 1 interface is TCP, or if you want if there >> is not HoL block there are not difference between two protocols due >> to the same congestion algorithm. >> >> >> >> 2) SCTP with 2 interface has a better performance just for message >> size greater than 64-byte. >> >> But SCTP was born for Signaling transport, and signaling messages are >> yes lager than 64-bye but not very large. >> >> >> >> when in the experiment is used SOCK_SEQPACKET >> >> 3) the real start up with 1 or 2 interfaces are both worse than the >> Theoretical one. The strange is the reale one with 2 interfaces is >> worse than the reale one with just one interface. >> >> 4) similar considerations ( done above ) could be done also for the >> other phases . So SOCK_SEQPACKET seems not so good. >> >> >> >> >> >> regards >> >> sal >> >> >> >> >> _________________________________________________________________ >> >> [3]Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai >> virus! >> >>References >> >> 1. http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm >> 2. http://www.openss7.org/sctp_perf.html >> 3. http://it.rd.yahoo.com/mail/taglines/*http://it.mail.yahoo.com > > >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > > -- Randall Stewart ITD 803-345-0369 815-342-5222 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 11:45:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28142; Thu, 7 Oct 2004 11:45:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFabu-0004hu-Lb; Thu, 07 Oct 2004 11:55:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaN0-00041l-UB; Thu, 07 Oct 2004 11:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFa9N-0002IZ-MR for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 11:25:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26463 for ; Thu, 7 Oct 2004 11:25:46 -0400 (EDT) Received: from web51502.mail.yahoo.com ([206.190.38.194]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFaJ2-0003sd-2p for tsvwg@ietf.org; Thu, 07 Oct 2004 11:35:52 -0400 Message-ID: <20041007152511.90532.qmail@web51502.mail.yahoo.com> Received: from [194.237.142.5] by web51502.mail.yahoo.com via HTTP; Thu, 07 Oct 2004 17:25:11 CEST Date: Thu, 7 Oct 2004 17:25:11 +0200 (CEST) From: Salvatore Loreto Subject: Re: [Tsvwg] sctp performance To: Randall Stewart , "Brian F. G. Bidulock" In-Reply-To: <41653B7A.7020302@cisco.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org, lksctp-developers@lists.sourceforge.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0823339330==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 --===============0823339330== Content-Type: multipart/alternative; boundary="0-1021742537-1097162711=:90499" --0-1021742537-1097162711=:90499 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA26463 Content-Transfer-Encoding: quoted-printable Hi Randall =20 do you have some report or paper where I can find information about SCTP in KAME ...=20 I read it includes HighSpeed SCTP, is it true? Can I have more information about? =20 thanks in advance /Sal =20 =20 =20 Randall Stewart wrote: Brian/Salvatore: Just a couple of comments... Brian F. G. Bidulock wrote: > Salvatore, >=20 > Performance tests on a clean network do not exercise SCTP's strong > points. SCTP was not really intended to outperform TCP on a clean > network with a single interface: it was intended to outperform TCP on a > real network with noise, failures and reconfiguration. If you look at > even single stream tests under noise SCTP rapidly outperforms TCP in > dirty networks. >=20 > The SOCK_SEQPACKET test deviation from theoretical is probably more of = a > software glitch in bundling, Nagle'ing and Minshall'ing in the OpenSS7 > stack more than a problem with the protocol (that was noted in the > results). I would tend to agree with Brian here.. SOCK_SEQPACKET is really an implementation shade.. In KAME other than controlling a few minor things all the same code runs... so it sould make very little difference.... >=20 > The SOCK_STREAM tests on a single interface did outperform TCP, however= , > note that the tests saturated the network and both are running very > close to theoretical maximums. >=20 > The interesting thing about the OpenSS7 tests were the multiple > interface tests on SOCK_STREAM, that showed that max throughput was a > multiple of the number of available interfaces. Once TCP saturates > a single interface it has nowhere else to go. SCTP can load multiple > interfaces to saturation. >=20 > These were throughput tests. Latency tests show SCTP has comparable > results to TCP (with slight improvements) on clean networks, and > SCTP exhibits significant reduced latencies to TCP under even as little > as 5% noise. On distrupted networks (50% interface failure on a 1 or > 2 second duty cycle) TCP stops and SCTP continues. >=20 > There are a lot of good papers out there testing more real environments > as well as NS-2 simulations that demonstrate the benefits of SCTP over > TCP for its original intended application, telephony signalling. Search > on "SCTP Performance" and you can read for the better part of a day. >=20 A couple of other things: a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which was NOT performance tuned at all.. I am not even sure if they have completed a pass yet of tuning.. I know its on their to-do list. b) IPERF ... which is used on both sites.. to me.. is NOT a very good benchmark. SCTP sends "messages" from one end to the other. TCP sends a byte stream from one end to the other. You then take and use IPERF to test the number of bytes streaming from one end to the other. This puts SCTP at a dis-advantage. Especially considering that MOST ALL applications send messages NOT streams of bytes. So if you added some additional overhead to TCP.. say framing messages at the app layer.. this would slow TCP down I would wager. I have always wanted to develop a variable message sender that could send a sequence of variable messages and get a reading of messages per second for various sizes.... c) CRC32c is extremely expensive (in overall terms of CPU use) on the TCP side they generally have an off-load engine they can use to not even do the c-sum... so in such a case when you begin to get CPU limited SCTP will lag behind TCP... just on the checksum basis alone. Bottom line is once you get CRC32c offload SCTP will be able to do a bit better :-D Regards R > --brian >=20 > On Thu, 07 Oct 2004, Salvatore Loreto wrote: >=20 >=20 >> Hi all, >> >> >> >> reading the experiments on SCTP performance >> >> >> >> LKSCTP >> >> [1]http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm >> >> OPENSS7 >> [2]http://www.openss7.org/sctp_perf.html >> >> >> >> If we ignore the gap underline between TCP and SCTP in LKSCTP, >> becose due to implementation problem ( and I think now the >> situation is better, isn't it? does someone have up to date results >> about?) >> >> and use just the result underline on OPENSSS7 >> >> >> >> I've some questions/doubts and I'd like know you opinion about: >> >> >> >> 1) the test SCTP with 1 interface shows a substanzial equivalent to >> TCP. >> >> Is it possible SCTP with 1 interface is TCP, or if you want if there >> is not HoL block there are not difference between two protocols due >> to the same congestion algorithm. >> >> >> >> 2) SCTP with 2 interface has a better performance just for message >> size greater than 64-byte. >> >> But SCTP was born for Signaling transport, and signaling messages are >> yes lager than 64-bye but not very large. >> >> >> >> when in the experiment is used SOCK_SEQPACKET >> >> 3) the real start up with 1 or 2 interfaces are both worse than the >> Theoretical one. The strange is the reale one with 2 interfaces is >> worse than the reale one with just one interface. >> >> 4) similar considerations ( done above ) could be done also for the >> other phases . So SOCK_SEQPACKET seems not so good. >> >> >> >> >> >> regards >> >> sal >> >> >> >> >> _________________________________________________________________ >> >> [3]Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai >> virus! >> >>References >> >> 1. http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm >> 2. http://www.openss7.org/sctp_perf.html >> 3. http://it.rd.yahoo.com/mail/taglines/*http://it.mail.yahoo.com >=20 >=20 >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg >=20 >=20 >=20 --=20 Randall Stewart ITD 803-345-0369 815-342-5222 =09 --------------------------------- Nuovo Yahoo! Messenger E' molto pi=F9 divertente: Audibles, Avatar, Webca= m, Giochi, Rubrica=85 Scaricalo ora!=20 --0-1021742537-1097162711=:90499 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA26463 Content-Transfer-Encoding: quoted-printable
Hi Randall
 
do you have some report or paper where I can find information
about SCTP in  KAME  ...
I read it includes HighSpeed SCTP, is it true?
Can I have more information about?
 
thanks in advance
/Sal
 
 
 


Randall Stewart <rrs@cisco.com> wrote:
Brian/Salvatore:

Just a couple of = comments...


Brian F. G. Bidulock wrote:
> Salvatore,
= >
> Performance tests on a clean network do not exercise SCTP's= strong
> points. SCTP was not really intended to outperform TCP on= a clean
> network with a single interface: it was intended to outp= erform TCP on a
> real network with noise, failures and reconfigura= tion. If you look at
> even single stream tests under noise SCTP ra= pidly outperforms TCP in
> dirty networks.
>
> The SOC= K_SEQPACKET test deviation from theoretical is probably more of a
>= software glitch in bundling, Nagle'ing and Minshall'ing in the OpenSS7> stack more than a problem with the protocol (that was noted in the=
> results).

I would tend to agree with Brian here.. SOCK_SE= QPACKET is really
an implementation shade.. In KAME other than controlling a
few minor things all the same code runs= ... so it sould make
very little difference....

>
> T= he SOCK_STREAM tests on a single interface did outperform TCP, however,> note that the tests saturated the network and both are running ver= y
> close to theoretical maximums.
>
> The interesting= thing about the OpenSS7 tests were the multiple
> interface tests = on SOCK_STREAM, that showed that max throughput was a
> multiple of= the number of available interfaces. Once TCP saturates
> a single = interface it has nowhere else to go. SCTP can load multiple
> inter= faces to saturation.
>
> These were throughput tests. Latenc= y tests show SCTP has comparable
> results to TCP (with slight impr= ovements) on clean networks, and
> SCTP exhibits significant reduce= d latencies to TCP under even as little
> as 5% noise. On distrupte= d networks (50% interface failure on a 1 or
> 2 second duty cycle) TCP stops and SCTP continues.
> > There are a lot of good papers out there testing more real environ= ments
> as well as NS-2 simulations that demonstrate the benefits o= f SCTP over
> TCP for its original intended application, telephony = signalling. Search
> on "SCTP Performance" and you can read for the= better part of a day.
>

A couple of other things:

a= ) The CERN tests were done on an OLD OLD OLD version of lk-sctp which
= was NOT performance tuned at all.. I am not even sure if they have
com= pleted a pass yet of tuning.. I know its on their to-do list.

b) I= PERF ... which is used on both sites.. to me.. is NOT a very good
benc= hmark. SCTP sends "messages" from one end to the other. TCP sends
a by= te stream from one end to the other. You then take and use IPERF
to te= st the number of bytes streaming from one end to the other.
This puts = SCTP at a dis-advantage. Especially considering that MOST
ALL applications send messages NOT streams of bytes. So if = you added
some additional overhead to TCP.. say framing messages at th= e app
layer.. this would slow TCP down I would wager.

I have al= ways wanted to develop a variable message sender that could
send a seq= uence of variable messages and get a reading of messages
per second fo= r various sizes....

c) CRC32c is extremely expensive (in overall t= erms of CPU use) on the
TCP side they generally have an off-load engin= e they can use to
not even do the c-sum... so in such a case when you = begin to
get CPU limited SCTP will lag behind TCP... just on the check= sum
basis alone. Bottom line is once you get CRC32c offload SCTP will<= BR>be able to do a bit better :-D

Regards

R


>= --brian
>
> On Thu, 07 Oct 2004, Salvatore Loreto wrote:>
>
>> Hi all,
>>
>t;>
>><= BR>>> reading the experiments on SCTP performance
>>
>>
>>
>> LKSCTP
&g= t;>
>> [1]http://datatag.web.cern.ch/datatag/WP3/sctp/tests.h= tm
>>
>> OPENSS7
>> [2]http://www.openss7.org/= sctp_perf.html
>>
>>
>>
>> If we igno= re the gap underline between TCP and SCTP in LKSCTP,
>> becose d= ue to implementation problem ( and I think now the
>> situation = is better, isn't it? does someone have up to date results
>> abo= ut?)
>>
>> and use just the result underline on OPENSSS= 7
>>
>>
>>
>> I've some questions/dou= bts and I'd like know you opinion about:
>>
>>
>&= gt;
>> 1) the test SCTP with 1 interface shows a substanzial equ= ivalent to
>> TCP.
>>
>> Is it possible SCTP w= ith 1 interface is TCP, or if you want if there
>> is not HoL bl= ock there are not difference between two protocols due
>> to the same congestion algorithm.
>><= BR>>>
>>
>> 2) SCTP with 2 interface has a better= performance just for message
>> size greater than 64-byte.
&= gt;>
>> But SCTP was born for Signaling transport, and signal= ing messages are
>> yes lager than 64-bye but not very large.>>
>>
>>
>> when in the experiment is u= sed SOCK_SEQPACKET
>>
>> 3) the real start up with 1 or= 2 interfaces are both worse than the
>> Theoretical one. The st= range is the reale one with 2 interfaces is
>> worse than the re= ale one with just one interface.
>>
>> 4) similar consi= derations ( done above ) could be done also for the
>> other pha= ses . So SOCK_SEQPACKET seems not so good.
>>
>>
>= ;>
>>
>>
>> regards
>>
>> sal
>>
>>
>>
>>
>> ________= _________________________________________________________
>>
= >> [3]Yahoo! Mail ti protegge gratis dalla posta indesiderata e dai=
>> virus!
>>
>>References
>>
>= > 1. http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm
>>= 2. http://www.openss7.org/sctp_perf.html
>> 3. http://it.rd.yah= oo.com/mail/taglines/*http://it.mail.yahoo.com
>
>
>&= gt;_______________________________________________
>>tsvwg maili= ng list
>>tsvwg@ietf.org
>>https://www1.ietf.org/mailma= n/listinfo/tsvwg
>
>
>


--
Randall Ste= wart
ITD
803-345-0369 815-342-5222

=09 =09

Nuovo Yahoo! Mes= senger E' molto pi=F9 divertente: Audibles, Avatar, Webcam, Gioch= i, Rubrica=85 Scaricalo ora!=20 --0-1021742537-1097162711=:90499-- --===============0823339330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0823339330==-- From tsvwg-bounces@ietf.org Thu Oct 7 12:22:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01386; Thu, 7 Oct 2004 12:22:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbBw-0007Gb-VZ; Thu, 07 Oct 2004 12:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFap6-0002fM-Jp; Thu, 07 Oct 2004 12:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaPE-0004hJ-AO for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 11:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28002 for ; Thu, 7 Oct 2004 11:42:09 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaYx-0004f6-Hc for tsvwg@ietf.org; Thu, 07 Oct 2004 11:52:15 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 391FC32D0E; Thu, 7 Oct 2004 11:41:05 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 1477C32D13; Thu, 7 Oct 2004 11:41:03 -0400 (EDT) Date: Thu, 7 Oct 2004 11:41:03 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Pawel Hadam Subject: Re: [Tsvwg] sctp performance In-Reply-To: <200410071427.i97ERXZ4022390@nailgun.cisco.com> Message-ID: References: <200410071427.i97ERXZ4022390@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Randall Stewart , tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, sctp-impl@external.cisco.com, "Brian F. G. Bidulock" , lksctp-developers@lists.sourceforge.net, alefelici@libero.it X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi, Just adding another pointer - Sourabh Ladha had some (throughput) results on the KAME stack on FreeBSD 4.6 (TCP NewReno): http://www.cis.udel.edu/~amer/PEL/poc/pdf/IPCCC2004-ladha.FTP.over.SCTP.pdf regards, jana On Thu, 7 Oct 2004, Pawel Hadam wrote: > (I am sorry for my previous, signed e-mail) > > Hi > > > a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which > > was NOT performance tuned at all.. I am not even sure if they have > > completed a pass yet of tuning.. I know its on their to-do list. > > > I was working with linux kernel 2.6.7 with lkSCTP 1.0.1 and I obtained > much better results. > > > I have always wanted to develop a variable message sender that could > > send a sequence of variable messages and get a reading of messages > > per second for various sizes.... > > > Sounds like my own testing apps. I wrote a sender and receiver that > accept some customization parameters (message size, buffers). > > I wrote a raport about my measurements and experiments with lkSCTP on > 1Gb network, but: > > 1) It is now being read by my supervisors. > 2) It is in french :) - I really am sorry, it was written for a french > project. > > Once the raport finished, I will, I hope, try to publish something in > this subject. > > If anybody wants the french version, I may send him the PDF (there are a > lot of pictures :))). Any comments are always welcome. > > Regards > Pawel > --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 12:27:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01927; Thu, 7 Oct 2004 12:27:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbGq-0007fn-Fv; Thu, 07 Oct 2004 12:37:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFasN-0004Lb-F3; Thu, 07 Oct 2004 12:12:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFafk-0000LM-7a for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 11:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29278 for ; Thu, 7 Oct 2004 11:59:13 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[Q3JNWKulN4F8CU6FnbMDPNu5JXhxoiyY]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFapS-0005iO-Hl for tsvwg@ietf.org; Thu, 07 Oct 2004 12:09:20 -0400 Received: from ns.pigworks.openss7.net (IDENT:sbQh6khVuVh9ieUm7AUnHHXBO7sNksMR@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i97FtvJ29713; Thu, 7 Oct 2004 09:55:57 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i97Ftvx20873; Thu, 7 Oct 2004 09:55:57 -0600 Date: Thu, 7 Oct 2004 09:55:56 -0600 From: "Brian F. G. Bidulock" To: Janardhan Iyengar Subject: Re: [Tsvwg] sctp performance Message-ID: <20041007095556.A20730@openss7.org> References: <200410071427.i97ERXZ4022390@nailgun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from iyengar@mail.eecis.udel.edu on Thu, Oct 07, 2004 at 11:41:03AM -0400 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 i97FtvJ29713 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, Pawel Hadam X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Janardhan, Interesting: at 0% probability of loss, single homed KAME SCTP performed poorer than TCP. It looks like SCTP implementors still have something to learn from TCP implementors in some cases. SCTP wasn't really aimed exclusively at greater than 3% message loss networks... Signalling netwo= rks normally have far better than 1ppm BER. --brian On Thu, 07 Oct 2004, Janardhan Iyengar wrote: > Hi, >=20 > Just adding another pointer - >=20 > Sourabh Ladha had some (throughput) results on the KAME stack on FreeBS= D > 4.6 (TCP NewReno): > http://www.cis.udel.edu/~amer/PEL/poc/pdf/IPCCC2004-ladha.FTP.over.SCTP= .pdf >=20 > regards, > jana >=20 > On Thu, 7 Oct 2004, Pawel Hadam wrote: >=20 > > (I am sorry for my previous, signed e-mail) > > > > Hi > > > > > a) The CERN tests were done on an OLD OLD OLD version of lk-sctp w= hich > > > was NOT performance tuned at all.. I am not even sure if they h= ave > > > completed a pass yet of tuning.. I know its on their to-do list. > > > > > > I was working with linux kernel 2.6.7 with lkSCTP 1.0.1 and I obtaine= d > > much better results. > > > > > I have always wanted to develop a variable message sender that = could > > > send a sequence of variable messages and get a reading of messa= ges > > > per second for various sizes.... > > > > > > Sounds like my own testing apps. I wrote a sender and receiver that > > accept some customization parameters (message size, buffers). > > > > I wrote a raport about my measurements and experiments with lkSCTP on > > 1Gb network, but: > > > > 1) It is now being read by my supervisors. > > 2) It is in french :) - I really am sorry, it was written for a frenc= h > > project. > > > > Once the raport finished, I will, I hope, try to publish something in > > this subject. > > > > If anybody wants the french version, I may send him the PDF (there ar= e a > > lot of pictures :))). Any comments are always welcome. > > > > Regards > > Pawel > > >=20 > --------------------------------------------------------------- > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar > Protocol Engineering Lab -- CIS -- University Of Delaware > --------------------------------------------------------------- --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 13:33:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07305; Thu, 7 Oct 2004 13:33:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcIL-0003VN-9y; Thu, 07 Oct 2004 13:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFc4U-0006VA-KB; Thu, 07 Oct 2004 13:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbuy-0004oz-Bq for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 13:19:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06303 for ; Thu, 7 Oct 2004 13:19:00 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFc4h-0002hL-IE for tsvwg@ietf.org; Thu, 07 Oct 2004 13:29:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Oct 2004 10:19:19 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97HIQEE009337; Thu, 7 Oct 2004 10:18:26 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AZU14604; Thu, 7 Oct 2004 10:18:17 -0700 (PDT) Message-ID: <41657A1B.2090605@cisco.com> Date: Thu, 07 Oct 2004 13:17:15 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] sctp performance References: <200410071427.i97ERXZ4022390@nailgun.cisco.com> <20041007095556.A20730@openss7.org> In-Reply-To: <20041007095556.A20730@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Janardhan Iyengar , gonzalo.camarillo@ericsson.com, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, Pawel Hadam X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > Janardhan, > > Interesting: at 0% probability of loss, single homed KAME SCTP performed > poorer than TCP. It looks like SCTP implementors still have something to > learn from TCP implementors in some cases. SCTP wasn't really aimed > exclusively at greater than 3% message loss networks... Signalling networks > normally have far better than 1ppm BER. Hmm.. The results are interesting.. but I think your 3% figure is a bit off.. Thats only one of the many graphs present... Some considerations of these results: a) Netbsd does NOT apply maxburst in TCP. So this will definetly influence small transfers... and if you note the larger the transfer the less the difference between the graphs.. in fact the 1Meg transfer in the later pages looks like possibly SCTP in all cases did better instead of in 2 out of 3 cases as it did in all others. b) Note that at ALL times if you use all of sctp .. multi-streaming etc. it does better.. it is only one of the 3 graphs that is slower in small transfers. c) 2002 was about the time I was performance optimizing KAME.. which actually needs to have a second pass... so I am not really sure which version Sourabh was actually using... d) Considering the very very little difference between TCP and SCTP even in these cases .. thats pretty darn good.. especially when you consider that the netbsd stack as been tweaked and tuned for at least 10 years... and KAME was about 1 - 1.5 years when Sourabh did this work... all in all I think the results quite positive :-D Note to Salvatore: Yes KAME does have H-S TCP in it.. its a configurable option when you compile it. And no I have no papers on any results since my focus as been in other places then that :-0 R > > > --brian > > On Thu, 07 Oct 2004, Janardhan Iyengar wrote: > > >>Hi, >> >>Just adding another pointer - >> >>Sourabh Ladha had some (throughput) results on the KAME stack on FreeBSD >>4.6 (TCP NewReno): >>http://www.cis.udel.edu/~amer/PEL/poc/pdf/IPCCC2004-ladha.FTP.over.SCTP.pdf >> >>regards, >>jana >> >>On Thu, 7 Oct 2004, Pawel Hadam wrote: >> >> >>>(I am sorry for my previous, signed e-mail) >>> >>>Hi >>> >>> > a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which >>> > was NOT performance tuned at all.. I am not even sure if they have >>> > completed a pass yet of tuning.. I know its on their to-do list. >>> >>> >>>I was working with linux kernel 2.6.7 with lkSCTP 1.0.1 and I obtained >>>much better results. >>> >>> > I have always wanted to develop a variable message sender that could >>> > send a sequence of variable messages and get a reading of messages >>> > per second for various sizes.... >>> >>> >>>Sounds like my own testing apps. I wrote a sender and receiver that >>>accept some customization parameters (message size, buffers). >>> >>>I wrote a raport about my measurements and experiments with lkSCTP on >>>1Gb network, but: >>> >>>1) It is now being read by my supervisors. >>>2) It is in french :) - I really am sorry, it was written for a french >>>project. >>> >>>Once the raport finished, I will, I hope, try to publish something in >>>this subject. >>> >>>If anybody wants the french version, I may send him the PDF (there are a >>>lot of pictures :))). Any comments are always welcome. >>> >>>Regards >>>Pawel >>> >> >>--------------------------------------------------------------- >>Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar >>Protocol Engineering Lab -- CIS -- University Of Delaware >>--------------------------------------------------------------- > > -- Randall Stewart ITD 803-345-0369 815-342-5222 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 14:20:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08471; Thu, 7 Oct 2004 14:20:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcgQ-0005Q8-Vj; Thu, 07 Oct 2004 14:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcJ2-0001UC-32; Thu, 07 Oct 2004 13:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFZEl-00049G-Qw for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 10:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20075 for ; Thu, 7 Oct 2004 10:27:17 -0400 (EDT) Received: from imag.imag.fr ([129.88.30.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZOR-0008J6-CU for tsvwg@ietf.org; Thu, 07 Oct 2004 10:37:22 -0400 Received: from [IPv6:2001:660:5301:26:706a:2bbe:c674:b05e] ([IPv6:2001:660:5301:26:706a:2bbe:c674:b05e]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id i97E4Vsq016059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2004 16:04:32 +0200 (CEST) Message-ID: <41654CB5.5090407@imag.fr> Date: Thu, 07 Oct 2004 16:03:33 +0200 From: Pawel Hadam Organization: LSR-IMAG Grenoble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart Subject: Re: [Tsvwg] sctp performance References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> <41653B7A.7020302@cisco.com> In-Reply-To: <41653B7A.7020302@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.4 (imag.imag.fr [IPv6:2001:660:5301:1e::101]); Thu, 07 Oct 2004 16:04:33 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Oct 2004 13:43:54 -0400 Cc: "Brian F. G. Bidulock" , tsvwg@ietf.org, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel.Hadam@imag.fr List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit (I am sorry for my previous, signed e-mail) Hi > a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which > was NOT performance tuned at all.. I am not even sure if they have > completed a pass yet of tuning.. I know its on their to-do list. I was working with linux kernel 2.6.7 with lkSCTP 1.0.1 and I obtained much better results. > I have always wanted to develop a variable message sender that could > send a sequence of variable messages and get a reading of messages > per second for various sizes.... Sounds like my own testing apps. I wrote a sender and receiver that accept some customization parameters (message size, buffers). I wrote a raport about my measurements and experiments with lkSCTP on 1Gb network, but: 1) It is now being read by my supervisors. 2) It is in french :) - I really am sorry, it was written for a french project. Once the raport finished, I will, I hope, try to publish something in this subject. If anybody wants the french version, I may send him the PDF (there are a lot of pictures :))). Any comments are always welcome. Regards Pawel _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 14:20:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08475; Thu, 7 Oct 2004 14:20:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcg2-0005PX-Iu; Thu, 07 Oct 2004 14:07:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcJ1-0001U7-J9; Thu, 07 Oct 2004 13:43:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYeQ-00077I-MS for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 09:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16314 for ; Thu, 7 Oct 2004 09:49:44 -0400 (EDT) Received: from imag.imag.fr ([129.88.30.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYo8-0005r5-JB for tsvwg@ietf.org; Thu, 07 Oct 2004 09:59:49 -0400 Received: from [IPv6:2001:660:5301:26:706a:2bbe:c674:b05e] ([IPv6:2001:660:5301:26:706a:2bbe:c674:b05e]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id i97DQrTq004245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2004 15:26:54 +0200 (CEST) Message-ID: <416543E4.3090003@imag.fr> Date: Thu, 07 Oct 2004 15:25:56 +0200 From: Pawel Hadam Organization: LSR-IMAG Grenoble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart Subject: Re: [Tsvwg] sctp performance References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> <41653B7A.7020302@cisco.com> In-Reply-To: <41653B7A.7020302@cisco.com> X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.4 (imag.imag.fr [IPv6:2001:660:5301:1e::101]); Thu, 07 Oct 2004 15:26:55 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Thu, 07 Oct 2004 13:43:53 -0400 Cc: "Brian F. G. Bidulock" , tsvwg@ietf.org, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel.Hadam@imag.fr List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736130034==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a cryptographically signed message in MIME format. --===============0736130034== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090108060009050007010503" This is a cryptographically signed message in MIME format. --------------ms090108060009050007010503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi > a) The CERN tests were done on an OLD OLD OLD version of lk-sctp which > was NOT performance tuned at all.. I am not even sure if they have > completed a pass yet of tuning.. I know its on their to-do list. I was working with linux kernel 2.6.7 with lkSCTP 1.0.1 and I obtained much better results. > I have always wanted to develop a variable message sender that could > send a sequence of variable messages and get a reading of messages > per second for various sizes.... Sounds like my own testing apps. I wrote a sender and receiver that accept some customization parameters (message size, buffers). I wrote a raport about my measurements and experiments with lkSCTP on 1Gb network, but: 1) It is now being read by my supervisors. 2) It is in french :) - I really am sorry, it was written for a french project. Once the raport finished, I will, I hope, try to publish something in this subject. If anybody wants the french version, I may send him the PDF (there are a lot of pictures :))). Any comments are always welcome. Regards Pawel --------------ms090108060009050007010503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILuzCC A20wggJVoAMCAQICAQIwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NjQ5WhcNMTEwNDI1MDU0NjQ5WjA0 MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzhHiE9BovqvV60iNsPk5e0bQc9hmIA Lcr/tUqO51akj2Es8aAqq/Yq3Xwsv+91VQusCU7nTmHA5wzwkBVFEgLCjOvDEmTiYxAYLssH MdmB5dwpgpsxVuKBHopvp+ipWBFEVoNds054cC3ftv1ygUXV8e5Nzu++1T0MkCBFmgmArw9M 2iAOgL86s+sngMC5D8ChTkDcOv1qKr9A1SxxgPn4umvk6ioAqy++mvCndm2YKZwPL/BC8hiX W8n2zBlfusK+EtJcsJCUwLfLBgTvjzDtMi16SveTu6AJpLTuM8vQg5u1tbOQ3o6QHlmcINVL Hu3XTE+G+hw6KqHprAWgnb8CAwEAAaOBkjCBjzAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBRn WaXlB3RJA+8Fz8wupBjVEMiePDBTBgNVHSMETDBKgBRW62i50lx+mLWlU8ORb2NYxPlrt6Ev pC0wKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxDTALBgNVBAMTBENOUlOCAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4IBAQAGA0eDckWQwk7hIderF6kBVQbKQG1Voh1e 6+IUI1nkCeKQ9jyNNgYPS6cmI2XC6gaacru4jMuKX+95NiV+ANfzBpT7g0QpJjfH7umHzmyG gBtxPdJir/bNYmxTD+Z6kwCMey4z4EEdqr5lmHbxlQd0s+Y/U3XVSwY2SynE9tyOE4BAEHOC rRV7BHFQtTcz8shku6EQfjbGra9vcFKm0a7MzLqw6FkSj2INrQPdSyroiTmIUS/tYei3MIfb J1VtZoejUQmAYXFRBb4THdlBMPx1XwqWmxj/vpCBtBPAchEI/Wqaage99IMstGA2ZAf6PWqn sJAEdoPdM8s04heYBAuhMIIEITCCAwmgAwIBAgICENAwDQYJKoZIhvcNAQEEBQAwNDELMAkG A1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNOUlMtU3RhbmRhcmQwHhcNMDQw NzI3MDkzMTQ2WhcNMDUwNzI3MDkzMTQ2WjBoMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHVU1SNTUyNjEUMBIGA1UEAxMLUGF3ZWwgSGFkYW0xIjAgBgkqhkiG9w0B CQEWE1Bhd2VsLkhhZGFtQGltYWcuZnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOI/ jDrGmFEB1Pq/FjgkitSP9YTwZPWodhjben0L0lkLLZn1fvlDd8fknJuIsJwc8EjGyiiTujjj cLJlSOLE0c3DuSUA7MYNb6cbkrGgdkvISR48aeunO8Ox2rhT18ks3rpoBvY5hsDLxgjxNF6h zL37u1mwIhb8j2wj5jSLh70DAgMBAAGjggGLMIIBhzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG +EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAweAYJYIZIAYb4QgENBGsWaUNlcnRpZmljYXQg Q05SUy1TdGFuZGFyZC4gUG91ciB0b3V0ZSBpbmZvcm1hdGlvbiBzZSByZXBvcnRlciDgIGh0 dHA6Ly9pZ2Muc2VydmljZXMuY25ycy5mci9DTlJTLVN0YW5kYXJkLzAdBgNVHQ4EFgQUARMi FzdQAfUDDat290So6yWiPKswUwYDVR0jBEwwSoAUZ1ml5Qd0SQPvBc/MLqQY1RDInjyhL6Qt MCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMQ0wCwYDVQQDEwRDTlJTggECMB4GA1Ud EQQXMBWBE1Bhd2VsLkhhZGFtQGltYWcuZnIwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2Ny bHMuc2VydmljZXMuY25ycy5mci9DTlJTLVN0YW5kYXJkL2dldGRlci5jcmwwDQYJKoZIhvcN AQEEBQADggEBAH51zXas4Rl9ez6R4ARCDcuoInfKb5c8SCPuANTNo5VMtmfNj8GwoEE4iB79 vnwk9EM1eEENqDkywrVMOsd0GZewWTR1zL97uJrfFotIHpoUFHngqkBZPMF3/SIXfH8AyZD8 0ECd3HjUNl1yoBMVfejHhyKYqqRvjjMwZrLgxRghxe5cJTqskRsAK86twf5rEzY9wo566QWG bc221jcz4k2yKzfxgpxYvGGOdI9Koy7F7TpdjhtRS38AyEU1WFyBzF4okIYRKekLgH+7dxnO AASNEee6phBHHLt5fXerKVYMSmjz6wJWXAnhmAMaKbYoro6nOLeT1mO7a0vqLN+OvyUwggQh MIIDCaADAgECAgIQ0DANBgkqhkiG9w0BAQQFADA0MQswCQYDVQQGEwJGUjENMAsGA1UEChME Q05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZDAeFw0wNDA3MjcwOTMxNDZaFw0wNTA3Mjcw OTMxNDZaMGgxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVTVI1NTI2 MRQwEgYDVQQDEwtQYXdlbCBIYWRhbTEiMCAGCSqGSIb3DQEJARYTUGF3ZWwuSGFkYW1AaW1h Zy5mcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4j+MOsaYUQHU+r8WOCSK1I/1hPBk 9ah2GNt6fQvSWQstmfV++UN3x+Scm4iwnBzwSMbKKJO6OONwsmVI4sTRzcO5JQDsxg1vpxuS saB2S8hJHjxp66c7w7HauFPXySzeumgG9jmGwMvGCPE0XqHMvfu7WbAiFvyPbCPmNIuHvQMC AwEAAaOCAYswggGHMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DB4BglghkgBhvhCAQ0EaxZpQ2VydGlmaWNhdCBDTlJTLVN0YW5kYXJkLiBQb3Vy IHRvdXRlIGluZm9ybWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5j bnJzLmZyL0NOUlMtU3RhbmRhcmQvMB0GA1UdDgQWBBQBEyIXN1AB9QMNq3b3RKjrJaI8qzBT BgNVHSMETDBKgBRnWaXlB3RJA+8Fz8wupBjVEMiePKEvpC0wKzELMAkGA1UEBhMCRlIxDTAL BgNVBAoTBENOUlMxDTALBgNVBAMTBENOUlOCAQIwHgYDVR0RBBcwFYETUGF3ZWwuSGFkYW1A aW1hZy5mcjBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtU3RhbmRhcmQvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQQFAAOCAQEAfnXNdqzhGX17 PpHgBEINy6gid8pvlzxII+4A1M2jlUy2Z82PwbCgQTiIHv2+fCT0QzV4QQ2oOTLCtUw6x3QZ l7BZNHXMv3u4mt8Wi0gemhQUeeCqQFk8wXf9Ihd8fwDJkPzQQJ3ceNQ2XXKgExV96MeHIpiq pG+OMzBmsuDFGCHF7lwlOqyRGwArzq3B/msTNj3CjnrpBYZtzbbWNzPiTbIrN/GCnFi8YY50 j0qjLsXtOl2OG1FLfwDIRTVYXIHMXiiQhhEp6QuAf7t3Gc4ABI0R57qmEEccu3l9d6spVgxK aPPrAlZcCeGYAxoptiiujqc4t5PWY7trS+os346/JTGCAi0wggIpAgEBMDowNDELMAkGA1UE BhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNOUlMtU3RhbmRhcmQCAhDQMAkGBSsO AwIaBQCgggFJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0 MTAwNzEzMjU1NlowIwYJKoZIhvcNAQkEMRYEFHpkLZ7mYGUZ1NRd7pEmx5jXDwyJMEkGCSsG AQQBgjcQBDE8MDowNDELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNO UlMtU3RhbmRhcmQCAhDQMEsGCyqGSIb3DQEJEAILMTygOjA0MQswCQYDVQQGEwJGUjENMAsG A1UEChMEQ05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZAICENAwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBvuhdjtcoky/mkD4Dwdon5mCAfTSqT Cjw4U2gGQ1wvBdD++XH1beZZuxoeXohvUgnLJaoYRhhD4yT69MxlljQWjB6RHIMLpeBog1zp IGFZ1LBWTEM6tmxjM9FFIlmyRubzFKxynCtvJ+elEkGweO1XaKJcMTdZJfmIS0NoY/1TrQAA AAAAAA== --------------ms090108060009050007010503-- --===============0736130034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0736130034==-- From tsvwg-bounces@ietf.org Thu Oct 7 15:09:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08451; Thu, 7 Oct 2004 14:20:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFch8-0005RC-5S; Thu, 07 Oct 2004 14:08:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcJ2-0001UH-NM; Thu, 07 Oct 2004 13:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbpe-0003wO-42 for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 13:13:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05897 for ; Thu, 7 Oct 2004 13:13:30 -0400 (EDT) Received: from imag.imag.fr ([129.88.30.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbzK-0002J1-1A for tsvwg@ietf.org; Thu, 07 Oct 2004 13:23:38 -0400 Received: from [IPv6:2001:660:5301:26:706a:2bbe:c674:b05e] ([IPv6:2001:660:5301:26:706a:2bbe:c674:b05e]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id i97GobuE005378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2004 18:50:39 +0200 (CEST) Message-ID: <4165739F.6040202@imag.fr> Date: Thu, 07 Oct 2004 18:49:35 +0200 From: Pawel Hadam Organization: LSR-IMAG Grenoble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: salvatore.loreto@ieee.org References: <20041007095025.91925.qmail@web51504.mail.yahoo.com> In-Reply-To: <20041007095025.91925.qmail@web51504.mail.yahoo.com> X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.4 (imag.imag.fr [IPv6:2001:660:5301:1e::101]); Thu, 07 Oct 2004 18:50:39 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Thu, 07 Oct 2004 13:43:54 -0400 Cc: gonzalo.camarillo@ericsson.com, sctp-impl@external.cisco.com, tsvwg@ietf.org, lksctp-developers@lists.sourceforge.net, alefelici@libero.it Subject: [Tsvwg] Re: sctp performance X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel.Hadam@imag.fr List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0803172987==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a cryptographically signed message in MIME format. --===============0803172987== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060400040701020605080009" This is a cryptographically signed message in MIME format. --------------ms060400040701020605080009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi > OPENSS7 > http://www.openss7.org/sctp_perf.html I am interested in a case with 2 interfaces. How did they do the load-balancing between 2 interfaces? It was on SCTP or application (iperf ???) level ??? Does anybody know? Pawel --------------ms060400040701020605080009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILuzCC A20wggJVoAMCAQICAQIwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoT BENOUlMxDTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NjQ5WhcNMTEwNDI1MDU0NjQ5WjA0 MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzhHiE9BovqvV60iNsPk5e0bQc9hmIA Lcr/tUqO51akj2Es8aAqq/Yq3Xwsv+91VQusCU7nTmHA5wzwkBVFEgLCjOvDEmTiYxAYLssH MdmB5dwpgpsxVuKBHopvp+ipWBFEVoNds054cC3ftv1ygUXV8e5Nzu++1T0MkCBFmgmArw9M 2iAOgL86s+sngMC5D8ChTkDcOv1qKr9A1SxxgPn4umvk6ioAqy++mvCndm2YKZwPL/BC8hiX W8n2zBlfusK+EtJcsJCUwLfLBgTvjzDtMi16SveTu6AJpLTuM8vQg5u1tbOQ3o6QHlmcINVL Hu3XTE+G+hw6KqHprAWgnb8CAwEAAaOBkjCBjzAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBRn WaXlB3RJA+8Fz8wupBjVEMiePDBTBgNVHSMETDBKgBRW62i50lx+mLWlU8ORb2NYxPlrt6Ev pC0wKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxDTALBgNVBAMTBENOUlOCAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4IBAQAGA0eDckWQwk7hIderF6kBVQbKQG1Voh1e 6+IUI1nkCeKQ9jyNNgYPS6cmI2XC6gaacru4jMuKX+95NiV+ANfzBpT7g0QpJjfH7umHzmyG gBtxPdJir/bNYmxTD+Z6kwCMey4z4EEdqr5lmHbxlQd0s+Y/U3XVSwY2SynE9tyOE4BAEHOC rRV7BHFQtTcz8shku6EQfjbGra9vcFKm0a7MzLqw6FkSj2INrQPdSyroiTmIUS/tYei3MIfb J1VtZoejUQmAYXFRBb4THdlBMPx1XwqWmxj/vpCBtBPAchEI/Wqaage99IMstGA2ZAf6PWqn sJAEdoPdM8s04heYBAuhMIIEITCCAwmgAwIBAgICENAwDQYJKoZIhvcNAQEEBQAwNDELMAkG A1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNOUlMtU3RhbmRhcmQwHhcNMDQw NzI3MDkzMTQ2WhcNMDUwNzI3MDkzMTQ2WjBoMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05S UzEQMA4GA1UECxMHVU1SNTUyNjEUMBIGA1UEAxMLUGF3ZWwgSGFkYW0xIjAgBgkqhkiG9w0B CQEWE1Bhd2VsLkhhZGFtQGltYWcuZnIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOI/ jDrGmFEB1Pq/FjgkitSP9YTwZPWodhjben0L0lkLLZn1fvlDd8fknJuIsJwc8EjGyiiTujjj cLJlSOLE0c3DuSUA7MYNb6cbkrGgdkvISR48aeunO8Ox2rhT18ks3rpoBvY5hsDLxgjxNF6h zL37u1mwIhb8j2wj5jSLh70DAgMBAAGjggGLMIIBhzAMBgNVHRMBAf8EAjAAMBEGCWCGSAGG +EIBAQQEAwIEsDAOBgNVHQ8BAf8EBAMCBeAweAYJYIZIAYb4QgENBGsWaUNlcnRpZmljYXQg Q05SUy1TdGFuZGFyZC4gUG91ciB0b3V0ZSBpbmZvcm1hdGlvbiBzZSByZXBvcnRlciDgIGh0 dHA6Ly9pZ2Muc2VydmljZXMuY25ycy5mci9DTlJTLVN0YW5kYXJkLzAdBgNVHQ4EFgQUARMi FzdQAfUDDat290So6yWiPKswUwYDVR0jBEwwSoAUZ1ml5Qd0SQPvBc/MLqQY1RDInjyhL6Qt MCsxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMQ0wCwYDVQQDEwRDTlJTggECMB4GA1Ud EQQXMBWBE1Bhd2VsLkhhZGFtQGltYWcuZnIwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2Ny bHMuc2VydmljZXMuY25ycy5mci9DTlJTLVN0YW5kYXJkL2dldGRlci5jcmwwDQYJKoZIhvcN AQEEBQADggEBAH51zXas4Rl9ez6R4ARCDcuoInfKb5c8SCPuANTNo5VMtmfNj8GwoEE4iB79 vnwk9EM1eEENqDkywrVMOsd0GZewWTR1zL97uJrfFotIHpoUFHngqkBZPMF3/SIXfH8AyZD8 0ECd3HjUNl1yoBMVfejHhyKYqqRvjjMwZrLgxRghxe5cJTqskRsAK86twf5rEzY9wo566QWG bc221jcz4k2yKzfxgpxYvGGOdI9Koy7F7TpdjhtRS38AyEU1WFyBzF4okIYRKekLgH+7dxnO AASNEee6phBHHLt5fXerKVYMSmjz6wJWXAnhmAMaKbYoro6nOLeT1mO7a0vqLN+OvyUwggQh MIIDCaADAgECAgIQ0DANBgkqhkiG9w0BAQQFADA0MQswCQYDVQQGEwJGUjENMAsGA1UEChME Q05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZDAeFw0wNDA3MjcwOTMxNDZaFw0wNTA3Mjcw OTMxNDZaMGgxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVTVI1NTI2 MRQwEgYDVQQDEwtQYXdlbCBIYWRhbTEiMCAGCSqGSIb3DQEJARYTUGF3ZWwuSGFkYW1AaW1h Zy5mcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4j+MOsaYUQHU+r8WOCSK1I/1hPBk 9ah2GNt6fQvSWQstmfV++UN3x+Scm4iwnBzwSMbKKJO6OONwsmVI4sTRzcO5JQDsxg1vpxuS saB2S8hJHjxp66c7w7HauFPXySzeumgG9jmGwMvGCPE0XqHMvfu7WbAiFvyPbCPmNIuHvQMC AwEAAaOCAYswggGHMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQDAgSwMA4GA1UdDwEB /wQEAwIF4DB4BglghkgBhvhCAQ0EaxZpQ2VydGlmaWNhdCBDTlJTLVN0YW5kYXJkLiBQb3Vy IHRvdXRlIGluZm9ybWF0aW9uIHNlIHJlcG9ydGVyIOAgaHR0cDovL2lnYy5zZXJ2aWNlcy5j bnJzLmZyL0NOUlMtU3RhbmRhcmQvMB0GA1UdDgQWBBQBEyIXN1AB9QMNq3b3RKjrJaI8qzBT BgNVHSMETDBKgBRnWaXlB3RJA+8Fz8wupBjVEMiePKEvpC0wKzELMAkGA1UEBhMCRlIxDTAL BgNVBAoTBENOUlMxDTALBgNVBAMTBENOUlOCAQIwHgYDVR0RBBcwFYETUGF3ZWwuSGFkYW1A aW1hZy5mcjBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3Jscy5zZXJ2aWNlcy5jbnJzLmZy L0NOUlMtU3RhbmRhcmQvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQQFAAOCAQEAfnXNdqzhGX17 PpHgBEINy6gid8pvlzxII+4A1M2jlUy2Z82PwbCgQTiIHv2+fCT0QzV4QQ2oOTLCtUw6x3QZ l7BZNHXMv3u4mt8Wi0gemhQUeeCqQFk8wXf9Ihd8fwDJkPzQQJ3ceNQ2XXKgExV96MeHIpiq pG+OMzBmsuDFGCHF7lwlOqyRGwArzq3B/msTNj3CjnrpBYZtzbbWNzPiTbIrN/GCnFi8YY50 j0qjLsXtOl2OG1FLfwDIRTVYXIHMXiiQhhEp6QuAf7t3Gc4ABI0R57qmEEccu3l9d6spVgxK aPPrAlZcCeGYAxoptiiujqc4t5PWY7trS+os346/JTGCAi0wggIpAgEBMDowNDELMAkGA1UE BhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNOUlMtU3RhbmRhcmQCAhDQMAkGBSsO AwIaBQCgggFJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0 MTAwNzE2NDkzNVowIwYJKoZIhvcNAQkEMRYEFM4MII82v0ap3Qs1yM0C8I5vmkV5MEkGCSsG AQQBgjcQBDE8MDowNDELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNO UlMtU3RhbmRhcmQCAhDQMEsGCyqGSIb3DQEJEAILMTygOjA0MQswCQYDVQQGEwJGUjENMAsG A1UEChMEQ05SUzEWMBQGA1UEAxMNQ05SUy1TdGFuZGFyZAICENAwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDErij6KJEVnB2virge2tMHOS1xwkSf j0PFuVl08kn3cala1Up1MJj1jZXA6kv+XyVSiQgu6Pig9ta1hWiedM7wwfRucYnvULuwnNqQ Vlnx6hk4b1ewP1FtHKCecf2ygjfDMvXAOvHj1TCy9+njE0DCAM6lD4ew95n8D0SYcBcnOAAA AAAAAA== --------------ms060400040701020605080009-- --===============0803172987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0803172987==-- From tsvwg-bounces@ietf.org Thu Oct 7 15:54:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16994; Thu, 7 Oct 2004 15:54:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFeUi-0006Ac-UA; Thu, 07 Oct 2004 16:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFe3Y-0000aY-Tt; Thu, 07 Oct 2004 15:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFe0L-00071i-Bk; Thu, 07 Oct 2004 15:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15600; Thu, 7 Oct 2004 15:32:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFeA6-0004Xx-VC; Thu, 07 Oct 2004 15:42:51 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CFdpG-0000wC-2E; Thu, 07 Oct 2004 15:21:18 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 07 Oct 2004 15:21:18 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tsvwg, Internet Architecture Board , tsvwg mailing list , chair , tsvwg chair , RFC Editor Subject: [Tsvwg] Protocol Action: 'The Eifel Response Algorithm for TCP' to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following document: - 'The Eifel Response Algorithm for TCP ' as a Proposed Standard 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 This document recommends a way for a sender to respond to a spurious TCP timeout, provided that one has been detected (such detection mechanisms are ou of scope of this document). Furthermore, it adapts the retransmission timer to avoid additional spurious timeouts, and restores congestion state in such a wa that packet bursts are avoided. Working Group Summary The TSVWG working group supports the advancement of this document. It describe a building block for a complete system that avoids spurious TCP retransmissions. Although there are a number of different philosophies for overall approaches to this problem, this document provides a modular component that could be integrated into several such approaches. Protocol Quality This document was reviewed for the IESG by Jon Peterson. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 7 22:12:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26942; Thu, 7 Oct 2004 22:12:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkPN-0007Py-Mf; Thu, 07 Oct 2004 22:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFkDb-0007LR-Dn; Thu, 07 Oct 2004 22:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFk9O-0006ZL-CD for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 22:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25694 for ; Thu, 7 Oct 2004 22:06:27 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[Tzl5zUxVqmVazIXe4SbglawDh3yY5NJy]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFkJ3-0006td-4x for tsvwg@ietf.org; Thu, 07 Oct 2004 22:16:39 -0400 Received: from ns.pigworks.openss7.net (IDENT:nnSxBUcX8GXPxqddzibnyuAPjbtE+T6d@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9826BJ09302; Thu, 7 Oct 2004 20:06:11 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i98269t26457; Thu, 7 Oct 2004 20:06:09 -0600 Date: Thu, 7 Oct 2004 20:06:09 -0600 From: "Brian F. G. Bidulock" To: Pawel Hadam Subject: Re: [Tsvwg] Re: sctp performance Message-ID: <20041007200609.A26095@openss7.org> References: <20041007095025.91925.qmail@web51504.mail.yahoo.com> <4165739F.6040202@imag.fr> 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: <4165739F.6040202@imag.fr>; from Pawel.Hadam@imag.fr on Thu, Oct 07, 2004 at 06:49:35PM +0200 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 i9826BJ09302 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, salvatore.loreto@ieee.org, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Pawel, The load balancing is performed in the SCTP implementation. It's the sam= e algorithm that allowed us to acheive 20ms nominal fail-over times between interfaces in lmco's testing. --brian On Thu, 07 Oct 2004, Pawel Hadam wrote: > Hi >=20 > > OPENSS7 > > http://www.openss7.org/sctp_perf.html >=20 > I am interested in a case with 2 interfaces. > How did they do the load-balancing between 2 interfaces? > It was on SCTP or application (iperf ???) level ??? >=20 > Does anybody know? >=20 > Pawel >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 8 07:23:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15314; Fri, 8 Oct 2004 07:23:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFt0j-0004G9-2m; Fri, 08 Oct 2004 07:34:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsp2-0007kN-PW; Fri, 08 Oct 2004 07:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsle-0007EV-MG for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 07:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15075 for ; Fri, 8 Oct 2004 07:18:31 -0400 (EDT) Received: from imag.imag.fr ([129.88.30.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsvX-0004As-Vc for tsvwg@ietf.org; Fri, 08 Oct 2004 07:28:48 -0400 Received: from [IPv6:2001:660:5301:26:c1a6:1605:5b16:ff3b] ([IPv6:2001:660:5301:26:c1a6:1605:5b16:ff3b]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id i98Ath39002858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2004 12:55:44 +0200 (CEST) Message-ID: <4166722E.9060801@imag.fr> Date: Fri, 08 Oct 2004 12:55:42 +0200 From: Pawel Hadam Organization: LSR-IMAG Grenoble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> <41653B7A.7020302@cisco.com> In-Reply-To: <41653B7A.7020302@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Message not sent from an IPv4 address, not delayed by milter-greylist-1.4 (imag.imag.fr [IPv6:2001:660:5301:1e::101]); Fri, 08 Oct 2004 12:55:45 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "Brian F. G. Bidulock" , tsvwg@ietf.org, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com Subject: [Tsvwg] [sctp performance] english version presentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel.Hadam@imag.fr List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi all Together with my report I did a presentation. It is in english, and it presents the same work and the same results as described in the report. http://www-lsr.imag.fr/Les.Personnes/Pawel.Hadam/work/index.html -> "Multihoming & SCTP" Available as PPT and PDF Any comments are welcome. Regards Pawel _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 8 14:57:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23349; Fri, 8 Oct 2004 14:57:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG068-0006AY-CM; Fri, 08 Oct 2004 15:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzr0-0001g6-1Y; Fri, 08 Oct 2004 14:52:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzeK-0007RG-LR for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 14:39:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20069 for ; Fri, 8 Oct 2004 14:39:29 -0400 (EDT) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzoK-0005Y6-HF for tsvwg@ietf.org; Fri, 08 Oct 2004 14:49:48 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 63BEE6BA01 for ; Fri, 8 Oct 2004 14:38:57 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i98IcvV2005127 for ; Fri, 8 Oct 2004 14:38:57 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 403944FD48; Fri, 8 Oct 2004 14:37:02 -0400 (EDT) Date: Fri, 8 Oct 2004 14:37:02 -0400 From: Wesley Eddy To: tsvwg@ietf.org Message-ID: <20041008183702.GJ27317@grc.nasa.gov> Mime-Version: 1.0 X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Tsvwg] architecture for transport layer mobility X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0941088069==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --===============0941088069== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6J7GEvtanOfV9oXA" Content-Disposition: inline --6J7GEvtanOfV9oXA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline At the San Diego meeting last August, Allison closed the meeting by talking very broadly about hosts having multiple addresses, and how this affects the transport layer [1]. One of the potential uses is for handling host mobility at the transport layer. This has been done experimentally several times in several different transport protocols, but not within any specific unified architecture. For example, over the years there have been mobile SCTP, TCP, and DCCP proposals that all have used different code for supporting movement detection (finding out when the local host has moved) and doing location management (providing some way for the mobile node to be reached for new connections). These are two common problems for all transport layer mobility protocols, which happen to be independent of the particular transport protocol used. It makes sense to define a common framework to provide this functionality, so that individual transports don't have to worry about it. As a first step, we've begun exploring a simple architecture to provide these two services using existing standards (eg neighbor discovery, dynamic DNS, etc), and described our architecture in: http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt We would appreciate any feedback from the community on this, and would welcome the opportunity to speak breifly in Washington if the group is interested. We feel that while there is little new here, providing the common framework for transport protocols to easily develop mobility support with little replication of effort, is an important step. Additionally, this draft attempts to provide a detailed comparison of the architectural differences between transport layer mobility and Mobile IP, the predominant mobility protocol which operates at a completely different layer and has different deployment and stack-design considerations. -Wes [1] See meeting notes at http://www.ietf.org/proceedings/04aug/261.htm --6J7GEvtanOfV9oXA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBZt5OzBuYqbnj3IwRApTFAJ4sZvo2rJh7RrRlf3CKR58ZJixiywCeNVyJ zhfTecm6TAWC+GGaBE+vaRk= =jOTZ -----END PGP SIGNATURE----- --6J7GEvtanOfV9oXA-- --===============0941088069== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0941088069==-- From tsvwg-bounces@ietf.org Fri Oct 8 17:24:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18418; Fri, 8 Oct 2004 17:24:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2Np-00058L-5E; Fri, 08 Oct 2004 17:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1wG-0007UB-47; Fri, 08 Oct 2004 17:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG16H-0003Sq-4I for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 16:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04099 for ; Fri, 8 Oct 2004 16:12:23 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG1GG-0000V9-1V for tsvwg@ietf.org; Fri, 08 Oct 2004 16:22:44 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i98KB3J28501; Fri, 8 Oct 2004 13:11:03 -0700 (PDT) Message-ID: <4166F459.7080907@isi.edu> Date: Fri, 08 Oct 2004 13:11:05 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] architecture for transport layer mobility References: <20041008183702.GJ27317@grc.nasa.gov> In-Reply-To: <20041008183702.GJ27317@grc.nasa.gov> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1529207618==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1529207618== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0E9302A419D94BB93D1BA41" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0E9302A419D94BB93D1BA41 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This work is being explored in the Multi6 WG; it might be useful to check with their current state. In particular, one of their early conclusions was that there were multiple layers at which this problem _could_ be fixed (transport, net, shim under net, etc.), but that some were more appropriate than others (I think they concluded that transport solutions to mobility weren't as useful in the general sense since they need to be recapitulated for each transport design). Joe Wesley Eddy wrote: > At the San Diego meeting last August, Allison closed the meeting by > talking very broadly about hosts having multiple addresses, and how this > affects the transport layer [1]. One of the potential uses is for > handling host mobility at the transport layer. This has been done > experimentally several times in several different transport protocols, > but not within any specific unified architecture. > > For example, over the years there have been mobile SCTP, TCP, and DCCP > proposals that all have used different code for supporting movement > detection (finding out when the local host has moved) and doing location > management (providing some way for the mobile node to be reached for new > connections). These are two common problems for all transport layer > mobility protocols, which happen to be independent of the particular > transport protocol used. It makes sense to define a common framework to > provide this functionality, so that individual transports don't have to > worry about it. > > As a first step, we've begun exploring a simple architecture to provide > these two services using existing standards (eg neighbor discovery, > dynamic DNS, etc), and described our architecture in: > > http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt > > We would appreciate any feedback from the community on this, and would > welcome the opportunity to speak breifly in Washington if the group is > interested. We feel that while there is little new here, providing the > common framework for transport protocols to easily develop mobility > support with little replication of effort, is an important step. > Additionally, this draft attempts to provide a detailed comparison of > the architectural differences between transport layer mobility and > Mobile IP, the predominant mobility protocol which operates at a > completely different layer and has different deployment and stack-design > considerations. > > -Wes > > [1] See meeting notes at http://www.ietf.org/proceedings/04aug/261.htm > > > ------------------------------------------------------------------------ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --------------enigA0E9302A419D94BB93D1BA41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBZvRZE5f5cImnZrsRAjO9AKCne63hUqlYltV0xLjcn2sXybjBvwCfUO1A kn8o1J8gOCrFXY9QLvgN6QA= =2raR -----END PGP SIGNATURE----- --------------enigA0E9302A419D94BB93D1BA41-- --===============1529207618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1529207618==-- From tsvwg-bounces@ietf.org Fri Oct 8 17:44:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20400; Fri, 8 Oct 2004 17:44:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2h0-0005f1-BQ; Fri, 08 Oct 2004 17:54:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2OE-0003Br-NS; Fri, 08 Oct 2004 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Cn-0005rn-Sy for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 17:23:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18216 for ; Fri, 8 Oct 2004 17:23:11 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[JRYteRjWmIUzIGB0j1aiBA0bTz6YwciV]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2Mc-00053K-LR for tsvwg@ietf.org; Fri, 08 Oct 2004 17:33:33 -0400 Received: from ns.pigworks.openss7.net (IDENT:ogHgybl1x5YdPCEHpW01mxNnzaKy8bLv@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i98LJlJ00391; Fri, 8 Oct 2004 15:19:47 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i98LJji04548; Fri, 8 Oct 2004 15:19:45 -0600 Date: Fri, 8 Oct 2004 15:19:45 -0600 From: "Brian F. G. Bidulock" To: Pawel Hadam Message-ID: <20041008151945.B3881@openss7.org> References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> <41653B7A.7020302@cisco.com> <4166722E.9060801@imag.fr> 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: <4166722E.9060801@imag.fr>; from Pawel.Hadam@imag.fr on Fri, Oct 08, 2004 at 12:55:42PM +0200 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 i98LJlJ00391 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Randall Stewart , tsvwg@ietf.org, sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com Subject: [Tsvwg] Re: [sctp performance] english version presentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Pawel, Take a look at http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentations= /5-4_Thaker_etal.pdf which presents failover results nominal 10ms in test situations similar to your full mesh experiment on slide 35 of your presentation and also show much better 1% packet loss latencies. --brian On Fri, 08 Oct 2004, Pawel Hadam wrote: > Hi all >=20 > Together with my report I did a presentation. It is in english, and it=20 > presents the same work and the same results as described in the report. >=20 > http://www-lsr.imag.fr/Les.Personnes/Pawel.Hadam/work/index.html > -> > "Multihoming & SCTP" >=20 > Available as PPT and PDF >=20 > Any comments are welcome. >=20 > Regards > Pawel --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 8 20:19:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03383; Fri, 8 Oct 2004 20:19:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG57o-0000lB-PT; Fri, 08 Oct 2004 20:30:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG4gc-00058J-6I; Fri, 08 Oct 2004 20:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG4WF-00016D-2t for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 19:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29652 for ; Fri, 8 Oct 2004 19:51:23 -0400 (EDT) Received: from pedigree.cs.ubc.ca ([142.103.6.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG4gC-00083c-G4 for tsvwg@ietf.org; Fri, 08 Oct 2004 20:01:47 -0400 Received: from keiths.cs.ubc.ca (keiths.cs.ubc.ca [142.103.10.46]) by pedigree.cs.ubc.ca (8.12.10/8.11.4) with ESMTP id i98NpLOr010008; Fri, 8 Oct 2004 16:51:21 -0700 (PDT) Date: Fri, 8 Oct 2004 16:51:21 -0700 (PDT) From: Brad Penoff To: tsvwg@ietf.org, lksctp-developers@lists.sourceforge.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Tsvwg] SCTP one-to-one style feature clarification X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Greetings, We have noticed differing descriptions of the feature set for the one-to-one style in SCTP, and were hoping to receive some clarification. In the 3rd ed. of Stephen's "Unix Network Programming, Vol. 1", p.288 mentions that using the SOCK_STREAM "would not take advantage of any of the additional features provided by SCTP except multihoming." It doesn't specify exactly what features are NOT taken advantage. Are there any? More recently, in the latest release of draft-ietf-tsvwg-sctpsocket-09.txt , it says on p.5 that "all new SCTP features can be used with both styles of socket". This is seemingly contradictory to the Stephen's book. Understanding that this is a draft, we are just curious as to what the current exact features are that are supported in the one-to-one style of LKSCTP. Any assistance would be appreciated. Thanks, brad _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 8 21:21:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06702; Fri, 8 Oct 2004 21:21:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG65o-0001qa-SU; Fri, 08 Oct 2004 21:32:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG5rO-00031w-8v; Fri, 08 Oct 2004 21:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG5qp-0002el-5S for tsvwg@megatron.ietf.org; Fri, 08 Oct 2004 21:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06514 for ; Fri, 8 Oct 2004 21:16:45 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG60p-0001ly-83 for tsvwg@ietf.org; Fri, 08 Oct 2004 21:27:08 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA05444; Fri, 8 Oct 2004 18:16:11 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i991GAD17904; Fri, 8 Oct 2004 18:16:10 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 18:16:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] architecture for transport layer mobility Date: Fri, 8 Oct 2004 18:16:05 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060895@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] architecture for transport layer mobility Thread-Index: AcStfUGk9DjTfCInRxGVKyKxHmSlOQAH5uvw From: "Henderson, Thomas R" To: "Joe Touch" , X-OriginalArrivalTime: 09 Oct 2004 01:16:06.0164 (UTC) FILETIME=[8D14D540:01C4AD9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Friday, October 08, 2004 1:11 PM > To: weddy@grc.nasa.gov > Cc: tsvwg@ietf.org > Subject: Re: [Tsvwg] architecture for transport layer mobility >=20 >=20 > This work is being explored in the Multi6 WG; it might be useful to=20 > check with their current state. See also the CELP proposal from earlier this year, which was proposing a framework that also included transport layer (and layer 3.5 "wedge" layer): http://www.brandenburg.com/specifications/draft-crocker-celp-00.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sat Oct 9 14:04:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29393; Sat, 9 Oct 2004 14:04:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLjo-0002ng-Bu; Sat, 09 Oct 2004 14:14:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLUk-0003wf-2I; Sat, 09 Oct 2004 13:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLSe-0003CW-I9 for tsvwg@megatron.ietf.org; Sat, 09 Oct 2004 13:56:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29112 for ; Sat, 9 Oct 2004 13:56:51 -0400 (EDT) Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLco-0002hf-1i for tsvwg@ietf.org; Sat, 09 Oct 2004 14:07:22 -0400 Received: from [192.168.1.22] (p5089F2B2.dip.t-dialin.net [80.137.242.178]) by ilsa.franken.de (Postfix) with ESMTP id 451BA245C9; Sat, 9 Oct 2004 19:56:48 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <92F8A9C9-1A1C-11D9-AFC2-000D932C78D8@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Sat, 9 Oct 2004 19:56:41 +0200 To: Brad Penoff X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, lksctp-developers@lists.sourceforge.net Subject: [Tsvwg] Re: [Lksctp-developers] SCTP one-to-one style feature clarification X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Brad, see my comments below. Best regards Michael On Oct 9, 2004, at 1:51 Uhr, Brad Penoff wrote: > Greetings, > > We have noticed differing descriptions of the feature set for the > one-to-one style in SCTP, and were hoping to receive some > clarification. In the 3rd ed. of Stephen's "Unix Network Programming, > Vol. 1", p.288 mentions that using the SOCK_STREAM "would not take > advantage of any of the additional features provided by SCTP except > multihoming." It doesn't specify exactly what features are NOT taken > advantage. Are there any? This sentence is in the context of an existing TCP application which you 'port' to SCTP by simply changing the socket() call. By not using any additional function you do not use for example - multiple streams - unordered delivery - special parameter settings available by SCTP socket options > > More recently, in the latest release of > draft-ietf-tsvwg-sctpsocket-09.txt , it says on p.5 that "all new SCTP > features can be used with both styles of socket". This is seemingly > contradictory to the Stephen's book. No it is not. The point is that you need additional code (sctp_* functions, SCTP socket options) to make use of the additional functionality. > > Understanding that this is a draft, we are just curious as to what the > current exact features are that are supported in the one-to-one style > of LKSCTP. > > Any assistance would be appreciated. Thanks, > > brad > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give > us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Lksctp-developers mailing list > Lksctp-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 10 17:09:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12642; Sun, 10 Oct 2004 17:09:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGl7K-0007UZ-Md; Sun, 10 Oct 2004 17:20:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGkqX-0004id-7J; Sun, 10 Oct 2004 17:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFd8E-0004aV-6f for tsvwg@megatron.ietf.org; Thu, 07 Oct 2004 14:36:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09644 for ; Thu, 7 Oct 2004 14:36:47 -0400 (EDT) Received: from copland.udel.edu ([128.175.13.92]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdDu-0000Re-M2 for tsvwg@ietf.org; Thu, 07 Oct 2004 14:42:42 -0400 Received: from AMERPC (amerpc.pc.cis.udel.edu [128.4.133.62]) by copland.udel.edu (8.12.11/8.12.11) with SMTP id i97I9ZZq007974; Thu, 7 Oct 2004 14:09:42 -0400 (EDT) Message-ID: <007101c4ac99$5efc18d0$3e850480@AMERPC> From: "Paul D. Amer" To: References: <200410071427.i97ERXZ4022390@nailgun.cisco.com> <20041007095556.A20730@openss7.org> Subject: Re: [Tsvwg] sctp performance Date: Thu, 7 Oct 2004 14:13:22 -0400 Organization: CISC Department; University of Delaware MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-CanItPRO-Stream: default X-Spam-Score: 0 () X-Scanned-By: CanIt (www . canit . ca) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 10 Oct 2004 17:03:11 -0400 Cc: Randall Stewart , tsvwg@ietf.org, Pawel Hadam , sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, gonzalo.camarillo@ericsson.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hello Brian: > Interesting: at 0% probability of loss, single homed KAME SCTP performed > poorer than TCP. It looks like SCTP implementors still have something to > learn from TCP implementors in some cases. SCTP wasn't really aimed > exclusively at greater than 3% message loss networks... Signalling netwo= > rks > normally have far better than 1ppm BER. A more important result is that by exploiting SCTP's multistreaming mechanism (a feature unavailable with TCP), FTP over KAME SCTP was able to perform the same or slightly better than TCP at 0% loss, and increasingly much better as loss increases. Thanks, Paul Paul D. Amer, Professor CISC Graduate Admissions Committee, Chair 101C Smith Hall University of Delaware Newark, DE 19716-2586 (302) 831-1944 (office) (302) 831-8458 (fax) http://www.cis.udel.edu/~amer/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 10 20:50:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28095; Sun, 10 Oct 2004 20:50:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGoZ2-0002ln-8w; Sun, 10 Oct 2004 21:01:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGoMy-0001tJ-7H; Sun, 10 Oct 2004 20:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGoMK-0001mn-H4 for tsvwg@megatron.ietf.org; Sun, 10 Oct 2004 20:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27913 for ; Sun, 10 Oct 2004 20:48:13 -0400 (EDT) Received: from bh.kyungpook.ac.kr ([155.230.10.32] helo=bh.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGoWk-0002iE-69 for tsvwg@ietf.org; Sun, 10 Oct 2004 20:59:03 -0400 Received: from samsung6cjspyx ([155.230.17.186]) by bh.knu.ac.kr (8.12.11/8.12.11) with SMTP id i9B0hTCV027459; Mon, 11 Oct 2004 09:43:30 +0900 (KST) Message-ID: <017001c4af2b$f4772500$ba11e69b@samsung6cjspyx> From: "Seok J. Koh" To: , References: <20041008183702.GJ27317@grc.nasa.gov> Subject: Re: [Tsvwg] architecture for transport layer mobility Date: Mon, 11 Oct 2004 09:47:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hello Wesley, I think this kind of work will be very useful so to foster the further refinements of the existing several approaches for transport and network layer mobility. Basically, this will help service providers offer a lot of mobility solutions to users. Two minor comments on your draft: 1) We may consider SIP (session initiation protocol) as a candidate location management scheme in the application layer 2) As such, a transport layer mobility may be used tegether with the other network or application layer mobility schemes such as Mobile IP and SIP, if necessary. On use of MIP and mSCTP, you might refer to this I-D. http://www.ietf.org/internet-drafts/draft-sjkoh-mobile-sctp-mobileip-04.txt Seok J. Koh http://protocol.knu.ac.kr/ ----- Original Message ----- From: "Wesley Eddy" To: Sent: Saturday, October 09, 2004 3:37 AM Subject: [Tsvwg] architecture for transport layer mobility At the San Diego meeting last August, Allison closed the meeting by talking very broadly about hosts having multiple addresses, and how this affects the transport layer [1]. One of the potential uses is for handling host mobility at the transport layer. This has been done experimentally several times in several different transport protocols, but not within any specific unified architecture. For example, over the years there have been mobile SCTP, TCP, and DCCP proposals that all have used different code for supporting movement detection (finding out when the local host has moved) and doing location management (providing some way for the mobile node to be reached for new connections). These are two common problems for all transport layer mobility protocols, which happen to be independent of the particular transport protocol used. It makes sense to define a common framework to provide this functionality, so that individual transports don't have to worry about it. As a first step, we've begun exploring a simple architecture to provide these two services using existing standards (eg neighbor discovery, dynamic DNS, etc), and described our architecture in: http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt We would appreciate any feedback from the community on this, and would welcome the opportunity to speak breifly in Washington if the group is interested. We feel that while there is little new here, providing the common framework for transport protocols to easily develop mobility support with little replication of effort, is an important step. Additionally, this draft attempts to provide a detailed comparison of the architectural differences between transport layer mobility and Mobile IP, the predominant mobility protocol which operates at a completely different layer and has different deployment and stack-design considerations. -Wes [1] See meeting notes at http://www.ietf.org/proceedings/04aug/261.htm > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 10 21:03:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29134; Sun, 10 Oct 2004 21:03:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGolX-0002y1-1e; Sun, 10 Oct 2004 21:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGoZa-0003Y7-Lz; Sun, 10 Oct 2004 21:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGoY0-0003Bc-Kn for tsvwg@megatron.ietf.org; Sun, 10 Oct 2004 21:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28709 for ; Sun, 10 Oct 2004 21:00:18 -0400 (EDT) Received: from bh.kyungpook.ac.kr ([155.230.10.32] helo=bh.knu.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGoiR-0002v6-J9 for tsvwg@ietf.org; Sun, 10 Oct 2004 21:11:08 -0400 Received: from samsung6cjspyx ([155.230.17.186]) by bh.knu.ac.kr (8.12.11/8.12.11) with SMTP id i9B0tj2G002002; Mon, 11 Oct 2004 09:55:46 +0900 (KST) Message-ID: <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> From: "Seok J. Koh" To: "Joe Touch" , References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> Subject: Re: [Tsvwg] architecture for transport layer mobility Date: Mon, 11 Oct 2004 10:00:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi Joe, > (I think they concluded that transport solutions to mobility weren't as > useful in the general sense since they need to be recapitulated for each > transport design). The above opinion may come from the network-layer point of view. We note that the Transport Layer Mobility (TLM) does not try to add a new transport protocol just for mobility. Instead, we consider the case in which the user's host (and its peering server) are already equipped with the newly developed transport protocol such as SCTP or DCCP. The point is that in this case, the SCTP, DCCP or any new scheme could be used for supporting the mobility, possibly with the other existing schemes (such as DDNS, MIP, SIP, etc) Regards, Seok ----- Original Message ----- From: "Joe Touch" To: Cc: Sent: Saturday, October 09, 2004 5:11 AM Subject: Re: [Tsvwg] architecture for transport layer mobility This work is being explored in the Multi6 WG; it might be useful to check with their current state. In particular, one of their early conclusions was that there were multiple layers at which this problem _could_ be fixed (transport, net, shim under net, etc.), but that some were more appropriate than others (I think they concluded that transport solutions to mobility weren't as useful in the general sense since they need to be recapitulated for each transport design). Joe > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 11 12:19:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19215; Mon, 11 Oct 2004 12:19:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH33w-0002WS-4B; Mon, 11 Oct 2004 12:30:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH2qs-0004Jo-16; Mon, 11 Oct 2004 12:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH2e6-0000ma-NP for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 12:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18335 for ; Mon, 11 Oct 2004 12:03:32 -0400 (EDT) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH2of-0002E5-HH for tsvwg@ietf.org; Mon, 11 Oct 2004 12:14:29 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E701B6B9E9 for ; Mon, 11 Oct 2004 12:03:02 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i9BG31V2024353; Mon, 11 Oct 2004 12:03:01 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id BBE844FBF3; Mon, 11 Oct 2004 12:01:02 -0400 (EDT) Date: Mon, 11 Oct 2004 12:01:02 -0400 From: Wesley Eddy To: "Seok J. Koh" Subject: Re: [Tsvwg] architecture for transport layer mobility Message-ID: <20041011160102.GA30688@grc.nasa.gov> References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> Mime-Version: 1.0 In-Reply-To: <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1308410653==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --===============1308410653== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2004 at 10:00:15AM +0900, Seok J. Koh wrote: > Hi Joe, >=20 > > (I think they concluded that transport solutions to mobility weren't as= =20 > > useful in the general sense since they need to be recapitulated for eac= h=20 > > transport design). >=20 > The above opinion may come from the network-layer point of view. > We note that the Transport Layer Mobility (TLM) does not try to add=20 > a new transport protocol just for mobility. Instead, we consider the case= =20 > in which the user's host (and its peering server) are already equipped wi= th=20 > the newly developed transport protocol such as SCTP or DCCP. > Right. The main idea behind the draft was that we boil "mobility support" down into three components: 1) movement detection - using mechanisms like link triggers, neighbor/router discovery, etc to determine when a new network is available, and using some form of autoconfiguration to obtain an address and routing configuration. 2) location managment - maintaining some globally reachable "address". In Mobile IP, it's just the IP address. In this draft, we use the hostname in DNS, which may be preferable for a number of reasons. Other proposals use SIP, or a "host identity", etc. 3) binding updates - transport protocols are bound to some address, and if the location management is such that the address changes with location, then bindings need to be updated to maintain existing connections. Some congestion control state should be reset too for new paths, etc. We view #1 and #2 as independent of individual transport protocols. These are services that an operating system or daemon can handle in one place. T= he only modifications that transports have to support in this architecture are some form of #3, which are mechanisms like ADDIP and Change Primary in SCTP. In short summary, our goal was to combat precisely the problem that Joe brought up of every transport having to be modified, by making the required modifications as light as possible, while avoiding burdening the infrastructure with warts like HAs, FAs, and handover-smoothing goop. -Wes --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBaq4+zBuYqbnj3IwRAjKsAJ9r8+7MgAwJ3xTV6bM1O0yylc4y2gCfYE6t JUQucG2expVXew78ovx3qbc= =yHa2 -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- --===============1308410653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1308410653==-- From tsvwg-bounces@ietf.org Mon Oct 11 13:24:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24604; Mon, 11 Oct 2004 13:24:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH45S-0003zq-NV; Mon, 11 Oct 2004 13:35:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3tB-0000wq-Oh; Mon, 11 Oct 2004 13:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3se-0000kD-Bt for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 13:22:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24393 for ; Mon, 11 Oct 2004 13:22:37 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH43A-0003vR-RI for tsvwg@ietf.org; Mon, 11 Oct 2004 13:33:36 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9BHLGJ18508; Mon, 11 Oct 2004 10:21:16 -0700 (PDT) Message-ID: <416AC10D.4030302@isi.edu> Date: Mon, 11 Oct 2004 10:21:17 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] architecture for transport layer mobility References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> <20041011160102.GA30688@grc.nasa.gov> In-Reply-To: <20041011160102.GA30688@grc.nasa.gov> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Seok J. Koh" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559016777==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1559016777== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig307983E1C6CF795897F86793" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig307983E1C6CF795897F86793 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Mon, Oct 11, 2004 at 10:00:15AM +0900, Seok J. Koh wrote: > >>Hi Joe, >> >> >>>(I think they concluded that transport solutions to mobility weren't as >>>useful in the general sense since they need to be recapitulated for each >>>transport design). >> >>The above opinion may come from the network-layer point of view. >>We note that the Transport Layer Mobility (TLM) does not try to add >>a new transport protocol just for mobility. Instead, we consider the case >>in which the user's host (and its peering server) are already equipped with >>the newly developed transport protocol such as SCTP or DCCP. >> > > > Right. The main idea behind the draft was that we boil "mobility > support" down into three components: > > 1) movement detection - using mechanisms like link triggers, neighbor/router > discovery, etc to determine when a new network is available, and using some > form of autoconfiguration to obtain an address and routing configuration. > > 2) location managment - maintaining some globally reachable "address". In > Mobile IP, it's just the IP address. In this draft, we use the hostname in > DNS, which may be preferable for a number of reasons. Other proposals use > SIP, or a "host identity", etc. > > 3) binding updates - transport protocols are bound to some address, and > if the location management is such that the address changes with > location, then bindings need to be updated to maintain existing > connections. Some congestion control state should be reset too for new > paths, etc. > > We view #1 and #2 as independent of individual transport protocols. My point is that Multi-6 views #3 as independent of transport protocols as well, and that they have a number of documents discussing alternatives for #1, #2, and #3. > These > are services that an operating system or daemon can handle in one place. The > only modifications that transports have to support in this architecture are > some form of #3, which are mechanisms like ADDIP and Change Primary in SCTP. > > In short summary, our goal was to combat precisely the problem that Joe > brought up of every transport having to be modified, by making the > required modifications as light as possible, while avoiding burdening the > infrastructure with warts like HAs, FAs, and handover-smoothing goop. > > -Wes One issue is whether to burden the infrastructure with mobility support or to burden each transport protocol implementation. I like the idea of minimizing the impact on transport protocols, and certainly orthogonalization is a step in the right direction, but is this _really_ something that needs to happen at the transport layer? Joe --------------enig307983E1C6CF795897F86793 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBasERE5f5cImnZrsRAvGZAJwNdSkAYoNqk+WcHGuO1zuNZbAHzQCfd9oA M6/pEr5ursB+5mOu20DSOJM= =mccS -----END PGP SIGNATURE----- --------------enig307983E1C6CF795897F86793-- --===============1559016777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1559016777==-- From tsvwg-bounces@ietf.org Mon Oct 11 13:43:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26472; Mon, 11 Oct 2004 13:43:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4NQ-0004bw-3b; Mon, 11 Oct 2004 13:54:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH48x-0004hd-H7; Mon, 11 Oct 2004 13:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3va-0001FB-Mi for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 13:25:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24651 for ; Mon, 11 Oct 2004 13:25:39 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH46A-000404-B3 for tsvwg@ietf.org; Mon, 11 Oct 2004 13:36:38 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9BHNxJ19393; Mon, 11 Oct 2004 10:23:59 -0700 (PDT) Message-ID: <416AC1B3.7000001@isi.edu> Date: Mon, 11 Oct 2004 10:24:03 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Seok J. Koh" Subject: Re: [Tsvwg] architecture for transport layer mobility References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> In-Reply-To: <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0250919022==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0250919022== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4CE30BFB671DF89E7642D75D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4CE30BFB671DF89E7642D75D Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Seok J. Koh wrote: > Hi Joe, > > >>(I think they concluded that transport solutions to mobility weren't as >>useful in the general sense since they need to be recapitulated for each >>transport design). > > The above opinion may come from the network-layer point of view. It came from a discussion about the desire to have a single solution, rather than to proscribe requirements for each new protocol being designed, as Eddy is doing. It's simpler to fix a problem once than to provide a set of 'rules for current and future protocol mods'. Yes, it does come from the view that the network provides one set of services, and the transport provides a different set of services. And that the complexity of a network layer solution isn't different from that of a transport solution, except that a single network solution could be used by multiple transport protocols, and that the same is not true for transport solutions. > We note that the Transport Layer Mobility (TLM) does not try to add > a new transport protocol just for mobility. Instead, we consider the case > in which the user's host (and its peering server) are already equipped with > the newly developed transport protocol such as SCTP or DCCP. That works only where _each_ new protocol has support for mobility. Any new protocol would need to incorporate mobility as well. > The point is that in this case, the SCTP, DCCP or any new scheme could be > used for supporting the mobility, possibly with the other existing schemes > (such as DDNS, MIP, SIP, etc) > > Regards, > > Seok There can be interactions between schemes implemented at multiple layers as well. Joe --------------enig4CE30BFB671DF89E7642D75D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBasG0E5f5cImnZrsRAvTbAJwNXr7l/9tGvPX4ZdZY/OXE7/RGagCfW5TD t7+sNqgR/thgQDtpFfyvWyI= =mfmo -----END PGP SIGNATURE----- --------------enig4CE30BFB671DF89E7642D75D-- --===============0250919022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0250919022==-- From tsvwg-bounces@ietf.org Mon Oct 11 13:57:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27701; Mon, 11 Oct 2004 13:57:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4b0-0004wl-TM; Mon, 11 Oct 2004 14:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4LM-0001N3-BT; Mon, 11 Oct 2004 13:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4IJ-0000rc-21 for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 13:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26817 for ; Mon, 11 Oct 2004 13:49:09 -0400 (EDT) Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4Sp-0004iL-SH for tsvwg@ietf.org; Mon, 11 Oct 2004 14:00:07 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 902A86896D for ; Mon, 11 Oct 2004 13:48:34 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i9BHmXV2010828; Mon, 11 Oct 2004 13:48:33 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 10A254FBF3; Mon, 11 Oct 2004 13:46:35 -0400 (EDT) Date: Mon, 11 Oct 2004 13:46:35 -0400 From: Wesley Eddy To: Joe Touch Subject: Re: [Tsvwg] architecture for transport layer mobility Message-ID: <20041011174635.GA31120@grc.nasa.gov> References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> <416AC1B3.7000001@isi.edu> Mime-Version: 1.0 In-Reply-To: <416AC1B3.7000001@isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Seok J. Koh" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0844748470==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============0844748470== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote: >=20 > >We note that the Transport Layer Mobility (TLM) does not try to add=20 > >a new transport protocol just for mobility. Instead, we consider the cas= e=20 > >in which the user's host (and its peering server) are already equipped= =20 > >with the newly developed transport protocol such as SCTP or DCCP. >=20 > That works only where _each_ new protocol has support for mobility. Any > new protocol would need to incorporate mobility as well. >=20 Not really. Transports are build to suit classes of applications. View "robust to mobility" as we would other transport features like "ordered byte stream", "congestion-controlled", "reliable datagram service", "multi-streaming", etc. We don't put features into transports for applications that don't want them (at least we shouldn't). Just because SCTP does multi-streaming doesn't mean we now have to build it into TCP =2E.. TCP applications figure out their own way to do that if they have to. Mobility could work similarly, either use a mobility-robust transport, or do it yourself at a higher layer (if your application wants it). In this case, we'd only be building the binding updates into transports for long-lived types of applications that we expect mobile hosts to use. That may or may not be a large group of protocols. Building mobility support too low, as in the network layer, is a *terrible* idea, as it has unforseen consequences at higher layers that haven't been built with mobility specifically in mind. As evidence, TCP congestion control can be observed to exhibit quite inappropriate behavior when Mobile IP moves a host between two widely differing networks. -Wes --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBasb7zBuYqbnj3IwRAlyFAJ0UhcNK/Ug3W/P+JRSv8q6ZySAJ3QCgiyj8 xMp/RFGAYzC6iXRKAxNeFe0= =66Iq -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- --===============0844748470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0844748470==-- From tsvwg-bounces@ietf.org Mon Oct 11 14:01:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28056; Mon, 11 Oct 2004 14:01:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4eQ-00051S-Uf; Mon, 11 Oct 2004 14:12:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4Og-0004Qt-CN; Mon, 11 Oct 2004 13:55:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGuNa-0007CL-Av; Mon, 11 Oct 2004 03:13:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08064; Mon, 11 Oct 2004 03:13:56 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGuY2-0000ma-MI; Mon, 11 Oct 2004 03:24:48 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9B7DrWR028211; Mon, 11 Oct 2004 09:13:54 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 09:13:53 +0200 Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [213.159.188.246]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J5NZSLM; Mon, 11 Oct 2004 09:13:53 +0200 Received: from diadem.ted.dk.eu.ericsson.se (diadem.ted.dk.eu.ericsson.se [213.159.189.76]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id i9B7Dn326999; Mon, 11 Oct 2004 09:13:52 +0200 (MEST) X-Sybari-Trust: 741b5675 74898554 68ce30f7 00000139 From: Michael Vittrup Larsen Organization: Ericsson To: tsvwg@ietf.org Date: Mon, 11 Oct 2004 09:13:47 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410110913.47867.michael.vittrup.larsen@ericsson.com> X-OriginalArrivalTime: 11 Oct 2004 07:13:53.0752 (UTC) FILETIME=[DD964D80:01C4AF61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Oct 2004 13:55:44 -0400 Cc: tcpm@ietf.org Subject: [Tsvwg] New ID on efficient port randomisation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi all, A new ID on efficient port randomisation is now available at: http://www.ietf.org/internet-drafts/draft-larsen-tsvwg-port-randomisation-00.txt The draft describes and algorithm for port randomisation with a reasonable compromise between: * Obfuscation (port randomisation is obfuscation) * Fast convergence (i.e. port selection) in cases where many active sockets exist (i.e. probability of port collision is high). * Ease of implementation, i.e. little code and no additional data structures (e.g. port free-lists) to describe current port usage. The algorithm somewhat follows the idea of RFC1948, which describe TCP ISN randomisation. Feedback appreciated. (Sorry for the cross-post to TCPM. Port randomisation was discussed during the summer on TCPM, but IMHO belongs to TSVWG.) Michael Vittrup Larsen _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 11 14:21:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29519; Mon, 11 Oct 2004 14:21:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4xu-0005Uc-Sr; Mon, 11 Oct 2004 14:32:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4gW-0008Mx-DJ; Mon, 11 Oct 2004 14:14:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4VT-0006Fl-1k for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 14:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28155 for ; Mon, 11 Oct 2004 14:02:45 -0400 (EDT) Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4g1-00053P-TI for tsvwg@ietf.org; Mon, 11 Oct 2004 14:13:43 -0400 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7F3C46B9CE for ; Mon, 11 Oct 2004 14:02:12 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i9BI2BV2012884; Mon, 11 Oct 2004 14:02:12 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id EA2A44FBF3; Mon, 11 Oct 2004 14:00:12 -0400 (EDT) Date: Mon, 11 Oct 2004 14:00:12 -0400 From: Wesley Eddy To: Joe Touch Subject: Re: [Tsvwg] architecture for transport layer mobility Message-ID: <20041011180012.GB31120@grc.nasa.gov> References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> <20041011160102.GA30688@grc.nasa.gov> <416AC10D.4030302@isi.edu> Mime-Version: 1.0 In-Reply-To: <416AC10D.4030302@isi.edu> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Seok J. Koh" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148997995==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 --===============0148997995== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2004 at 10:21:17AM -0700, Joe Touch wrote: >=20 > My point is that Multi-6 views #3 as independent of transport protocols= =20 > as well, and that they have a number of documents discussing=20 > alternatives for #1, #2, and #3. > Yep, I think there is room for a lot of views here though, given the number of layers and slots between layers where people have been cramming mobility schemes. Certainly some are more palletable than others ... =20 > One issue is whether to burden the infrastructure with mobility support= =20 > or to burden each transport protocol implementation. I like the idea of= =20 > minimizing the impact on transport protocols, and certainly=20 > orthogonalization is a step in the right direction, but is this _really_= =20 > something that needs to happen at the transport layer? >=20 A question I think is better: Given the Internet architecture, where is the best place to build mobility support? Or: How can we build mobility support into the architecture without screwing it up? -Wes --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBasoszBuYqbnj3IwRAg2BAKCK8fLhSpKuS6Z/Qt4VbzZfhaTbqgCfcwXw VDVovHoP47pSDWjAJa3aBAQ= =SM12 -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- --===============0148997995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0148997995==-- From tsvwg-bounces@ietf.org Mon Oct 11 14:22:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29714; Mon, 11 Oct 2004 14:22:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4yx-0005Xn-SR; Mon, 11 Oct 2004 14:33:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4gb-0008Qj-7y; Mon, 11 Oct 2004 14:14:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4d4-0007hA-Mv for tsvwg@megatron.ietf.org; Mon, 11 Oct 2004 14:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28540 for ; Mon, 11 Oct 2004 14:10:37 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4nd-0005AL-Mj for tsvwg@ietf.org; Mon, 11 Oct 2004 14:21:35 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9BI9RJ04698; Mon, 11 Oct 2004 11:09:27 -0700 (PDT) Message-ID: <416ACC58.2070308@isi.edu> Date: Mon, 11 Oct 2004 11:09:28 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] architecture for transport layer mobility References: <20041008183702.GJ27317@grc.nasa.gov> <4166F459.7080907@isi.edu> <019001c4af2d$ab524060$ba11e69b@samsung6cjspyx> <416AC1B3.7000001@isi.edu> <20041011174635.GA31120@grc.nasa.gov> In-Reply-To: <20041011174635.GA31120@grc.nasa.gov> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Seok J. Koh" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1675816102==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1675816102== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7180088250E41EC24FEE3137" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7180088250E41EC24FEE3137 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wesley Eddy wrote: > On Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote: > .... > Building mobility support too low, as in the network layer, is a > *terrible* idea, as it has unforseen consequences at higher layers that > haven't been built with mobility specifically in mind. As evidence, TCP > congestion control can be observed to exhibit quite inappropriate > behavior when Mobile IP moves a host between two widely differing > networks. > > -Wes That can be said of any transport layer service, given particular link conditions; e.g., TCP works horribly over paths that have wireless hops. Does that mean we need TCP to be aware of wireless hops? Or does that mean that we should have a link that 'plays nice' (ala the recent PILC BCP). TCP and other transport protocols need to know addresses, and thus address mobility, only as an artifact of using the address as a connection identifer. IMO, mobility support should happen at the network layer; if the transport layer needs to detect and adjust to changing path properties, then make it more agile or deploy sub-path enhancements to 'play nice'. Much of the rest of this overal direction seems to be pushing transport protocols to provide telco-like services (rapid handover, etc.); IMO, being different from telco-service is the defining useful property of the Internet, not something to be 'patched over'. Joe --------------enig7180088250E41EC24FEE3137 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBasxcE5f5cImnZrsRAmHvAJ0SOgBLVg1P8lvJClnjfRA86lbXswCfatwb CMC3duMY7endLecMdMt4XDc= =8fcE -----END PGP SIGNATURE----- --------------enig7180088250E41EC24FEE3137-- --===============1675816102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1675816102==-- From tsvwg-bounces@ietf.org Tue Oct 12 03:18:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24321; Tue, 12 Oct 2004 03:18:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHH5v-00075U-S6; Tue, 12 Oct 2004 03:29:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGnm-0006P4-8w; Tue, 12 Oct 2004 03:10:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGcv-0002JC-FF for tsvwg@megatron.ietf.org; Tue, 12 Oct 2004 02:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23471 for ; Tue, 12 Oct 2004 02:59:15 -0400 (EDT) Received: from web51509.mail.yahoo.com ([206.190.38.201]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHGnb-0006p8-3u for tsvwg@ietf.org; Tue, 12 Oct 2004 03:10:19 -0400 Message-ID: <20041012065842.8051.qmail@web51509.mail.yahoo.com> Received: from [194.237.142.7] by web51509.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 08:58:42 CEST Date: Tue, 12 Oct 2004 08:58:42 +0200 (CEST) From: Salvatore Loreto Subject: Re: [Tsvwg] architecture for transport layer mobility To: Joe Touch , weddy@grc.nasa.gov In-Reply-To: <416ACC58.2070308@isi.edu> MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "Seok J. Koh" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1450800706==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 --===============1450800706== Content-Type: multipart/alternative; boundary="0-1766325685-1097564322=:7867" --0-1766325685-1097564322=:7867 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA23471 Content-Transfer-Encoding: quoted-printable Hello =20 the mobility support is becoming a hot issue. The mobility is always more request from people, but when we think mobility in Internet=20 =20 IMO we can't forget 1) the telco approach: continuity in communication or if you want in sess= ion, especially for real time application 2) the congestion problem... if we change network, maybe we change the th= roughput too, the link capacity and other... 3) the security problems... there are some good papers about all the poss= ible intrusion made take advantages from mobility =20 =20 /Sal Joe Touch wrote: Wesley Eddy wrote: > On Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote: >=20 .... > Building mobility support too low, as in the network layer, is a > *terrible* idea, as it has unforseen consequences at higher layers that > haven't been built with mobility specifically in mind. As evidence, TCP > congestion control can be observed to exhibit quite inappropriate > behavior when Mobile IP moves a host between two widely differing > networks. >=20 > -Wes That can be said of any transport layer service, given particular link=20 conditions; e.g., TCP works horribly over paths that have wireless hops.=20 Does that mean we need TCP to be aware of wireless hops? Or does that=20 mean that we should have a link that 'plays nice' (ala the recent PILC BC= P). TCP and other transport protocols need to know addresses, and thus=20 address mobility, only as an artifact of using the address as a=20 connection identifer. IMO, mobility support should happen at the network=20 layer; if the transport layer needs to detect and adjust to changing=20 path properties, then make it more agile or deploy sub-path enhancements=20 to 'play nice'. Much of the rest of this overal direction seems to be pushing transport=20 protocols to provide telco-like services (rapid handover, etc.); IMO,=20 being different from telco-service is the defining useful property of=20 the Internet, not something to be 'patched over'. Joe > ATTACHMENT part 1.2 application/pgp-signature name=3Dsignature.asc _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg =09 --------------------------------- Nuovo Yahoo! Messenger E' molto pi=F9 divertente: Audibles, Avatar, Webca= m, Giochi, Rubrica=85 Scaricalo ora!=20 --0-1766325685-1097564322=:7867 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA23471 Content-Transfer-Encoding: quoted-printable
Hello
 
the mobility support is becoming a hot issue.
The mobility is always more request from people,
but when we think mobility in Internet
 
IMO we can't forget
1) the telco approach: continuity in communication or if you wa= nt in session, especially for real time application
2) the congestion problem... if we change network, maybe we change t= he throughput too, the link capacity and other...
3) the security problems... there are some good papers about all the= possible intrusion made take advantages from mobility
 
 
/Sal


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


Wesley Eddy wrote:

> On= Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote:
>
....=
> Building mobility support too low, as in the network layer, is a=
> *terrible* idea, as it has unforseen consequences at higher laye= rs that
> haven't been built with mobility specifically in mind. As= evidence, TCP
> congestion control can be observed to exhibit quit= e inappropriate
> behavior when Mobile IP moves a host between two = widely differing
> networks.
>
> -Wes

That can = be said of any transport layer service, given particular link
conditi= ons; e.g., TCP works horribly over paths that have wireless hops.
Doe= s that mean we need TCP to be aware of wireless hops? Or does that
me= an that we should have a link that 'plays nice' (ala the recent PILC BCP)= .

TCP and other transport protocols need to know addresses, and thus
address mobility, only as an artifact of us= ing the address as a
connection identifer. IMO, mobility support shou= ld happen at the network
layer; if the transport layer needs to detec= t and adjust to changing
path properties, then make it more agile or = deploy sub-path enhancements
to 'play nice'.

Much of the rest = of this overal direction seems to be pushing transport
protocols to p= rovide telco-like services (rapid handover, etc.); IMO,
being differe= nt from telco-service is the defining useful property of
the Internet= , not something to be 'patched over'.

Joe





&= gt; ATTACHMENT part 1.2 application/pgp-signature name=3Dsignature.asc_______________________________________________
tsvwg mailing listtsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

=09 =09

Nuovo Yahoo! Mes= senger E' molto pi=F9 divertente: Audibles, Avatar, Webcam, Gioch= i, Rubrica=85 Scaricalo ora!=20 --0-1766325685-1097564322=:7867-- --===============1450800706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1450800706==-- From tsvwg-bounces@ietf.org Tue Oct 12 10:49:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26519; Tue, 12 Oct 2004 10:49:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHO9C-0006rj-Lj; Tue, 12 Oct 2004 11:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNla-00045m-AR; Tue, 12 Oct 2004 10:36:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNfO-0000sF-JI for tsvwg@megatron.ietf.org; Tue, 12 Oct 2004 10:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24041 for ; Tue, 12 Oct 2004 10:30:17 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNq8-0006TR-Mf for tsvwg@ietf.org; Tue, 12 Oct 2004 10:41:26 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 99AC032AFD; Tue, 12 Oct 2004 10:30:12 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 67E3C329F1; Tue, 12 Oct 2004 10:30:11 -0400 (EDT) Date: Tue, 12 Oct 2004 10:30:11 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" Subject: Re: [Tsvwg] sctp performance In-Reply-To: <200410071559.i97FxWZ4023738@nailgun.cisco.com> Message-ID: References: <200410071559.i97FxWZ4023738@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Randall Stewart , sctp-impl@external.cisco.com, "Paul D. Amer" , lksctp-developers@lists.sourceforge.net, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi Brian/all, Sorry about the late reply - I was on a paper deadline. My thoughts have been voiced by Randy and Prof. Amer. The experiments were performed about 2 years ago, and performance tuning has happened since then in the KAME stack. > It looks like SCTP implementors still have something to learn from TCP > implementors in some cases. I'm not sure much else can replace performance tuning that happens with time and usage. That a new SCTP could match up to an aged TCP stack is quite good, I think. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 13 23:47:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13480; Wed, 13 Oct 2004 23:47:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHwlI-0007fq-J9; Wed, 13 Oct 2004 23:58:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHwUf-0005oC-1a; Wed, 13 Oct 2004 23:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHnvW-0005Le-P1 for tsvwg@megatron.ietf.org; Wed, 13 Oct 2004 14:32:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22292 for ; Wed, 13 Oct 2004 14:32:43 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHo6W-0002R8-4O for tsvwg@ietf.org; Wed, 13 Oct 2004 14:44:05 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id AF7A332E1E; Wed, 13 Oct 2004 14:26:11 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 194BB32E17; Wed, 13 Oct 2004 14:26:10 -0400 (EDT) Date: Wed, 13 Oct 2004 14:26:09 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" Subject: Re: [Tsvwg] sctp performance In-Reply-To: <200410071215.i97CF6Z4020379@nailgun.cisco.com> Message-ID: References: <200410071215.i97CF6Z4020379@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Wed, 13 Oct 2004 23:41:29 -0400 Cc: Janardhan Iyengar , tsvwg@ietf.org, "Paul D. Amer" , pawel.hadam@imag.fr, sctp-impl@external.cisco.com, gonzalo.camarillo@ericsson.com, lksctp-developers@lists.sourceforge.net, alefelici@libero.it X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Sorry for reviving an old thread, but I'm just getting caught up on this list. On Thu, 7 Oct 2004, Brian F. G. Bidulock wrote: > The interesting thing about the OpenSS7 tests were the multiple > interface tests on SOCK_STREAM, that showed that max throughput was a > multiple of the number of available interfaces. Once TCP saturates > a single interface it has nowhere else to go. SCTP can load multiple > interfaces to saturation. I am curious about SCTP is able to increase throughput as the number of interfaces increase. Jana has showed that simply using all paths with SCTP is counter-productive. The transport has to be "smart" about getting around different issues when doing Concurrent Multipath Transfer (CMT). Jana has found several issues with "naive" CMT, but has done a nice job of addressing them one by one. He's still in the process of tackling more of these issues. http://www.cis.udel.edu/~iyengar/publications/2004.spects.iyengar.pdf http://www.cis.udel.edu/~iyengar/publications/2004.icon.iyengar.pdf ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 13 23:51:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13985; Wed, 13 Oct 2004 23:51:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHwpC-0007uD-3T; Thu, 14 Oct 2004 00:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHwUg-0005oH-5J; Wed, 13 Oct 2004 23:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHnzA-000636-Ln for tsvwg@megatron.ietf.org; Wed, 13 Oct 2004 14:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22643 for ; Wed, 13 Oct 2004 14:36:29 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHoAB-0002V2-3w for tsvwg@ietf.org; Wed, 13 Oct 2004 14:47:51 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 728013289D; Wed, 13 Oct 2004 14:29:33 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id DCC0932B6F; Wed, 13 Oct 2004 14:29:31 -0400 (EDT) Date: Wed, 13 Oct 2004 14:29:31 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" In-Reply-To: <200410082123.i98LNJZ4019774@nailgun.cisco.com> Message-ID: References: <200410082123.i98LNJZ4019774@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Wed, 13 Oct 2004 23:41:29 -0400 Cc: Janardhan Iyengar , Randall Stewart , tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, "Paul D. Amer" , sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, Pawel Hadam Subject: [Tsvwg] Re: [sctp performance] english version presentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, 8 Oct 2004, Brian F. G. Bidulock wrote: > Take a look at > > http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentations/5-4_Thaker_etal.pdf > > which presents failover results nominal 10ms in test situations similar > to your full mesh experiment on slide 35 of your presentation and also > show much better 1% packet loss latencies. 10ms failover?! Clearly this is a special case network and not operating over a WAN. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 13 23:53:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14118; Wed, 13 Oct 2004 23:53:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHwr4-0007wa-9k; Thu, 14 Oct 2004 00:04:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHwUh-0005oM-4y; Wed, 13 Oct 2004 23:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpAH-0005Xj-M7 for tsvwg@megatron.ietf.org; Wed, 13 Oct 2004 15:52:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29665 for ; Wed, 13 Oct 2004 15:52:02 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpLH-0004ld-F2 for tsvwg@ietf.org; Wed, 13 Oct 2004 16:03:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2004 12:57:52 -0700 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.10/8.12.6) with ESMTP id i9DJpPOE028583; Wed, 13 Oct 2004 12:51:25 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AZZ73914; Wed, 13 Oct 2004 12:51:10 -0700 (PDT) Message-ID: <416D86E9.8030001@cisco.com> Date: Wed, 13 Oct 2004 15:50:01 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." References: <200410082123.i98LNJZ4019774@nailgun.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Oct 2004 23:41:29 -0400 Cc: Janardhan Iyengar , "Brian F. G. Bidulock" , tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, "Paul D. Amer" , sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, Pawel Hadam Subject: [Tsvwg] Re: [sctp performance] english version presentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit My guess is RTO.Min must be set down to about 1ms and RTO.Max to some other low value... Of course this is fine for special case networks.. not the big-I :-D R Armando L. Caro Jr. wrote: > On Fri, 8 Oct 2004, Brian F. G. Bidulock wrote: > > >>Take a look at >> >> http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentations/5-4_Thaker_etal.pdf >> >>which presents failover results nominal 10ms in test situations similar >>to your full mesh experiment on slide 35 of your presentation and also >>show much better 1% packet loss latencies. > > > 10ms failover?! Clearly this is a special case network and not operating > over a WAN. > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 > -- Randall Stewart ITD 803-345-0369 815-342-5222 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 13 23:56:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14249; Wed, 13 Oct 2004 23:56:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHwtn-0007zL-0L; Thu, 14 Oct 2004 00:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHwUh-0005oS-Q0; Wed, 13 Oct 2004 23:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHq87-0004ZW-B4 for tsvwg@megatron.ietf.org; Wed, 13 Oct 2004 16:53:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06114 for ; Wed, 13 Oct 2004 16:53:51 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[2xK5CZl7ah9EZTUUfPyjxMCITG5zCUZW]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHqJ6-00066s-J7 for tsvwg@ietf.org; Wed, 13 Oct 2004 17:05:15 -0400 Received: from ns.pigworks.openss7.net (IDENT:6irSS/OnM5mxf8GDYje7c9UVWzC7/q8e@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9DKoNJ16548; Wed, 13 Oct 2004 14:50:23 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9DKoMv14072; Wed, 13 Oct 2004 14:50:22 -0600 Date: Wed, 13 Oct 2004 14:50:21 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Message-ID: <20041013145021.A13974@openss7.org> References: <200410131847.i9DIlv7U014788@nailgun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200410131847.i9DIlv7U014788@nailgun.cisco.com>; from me@armandocaro.net on Wed, Oct 13, 2004 at 02:29:31PM -0400 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 i9DKoNJ16548 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 13 Oct 2004 23:41:29 -0400 Cc: Janardhan Iyengar , Randall Stewart , tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, "Paul D. Amer" , sctp-impl@external.cisco.com, alefelici@libero.it, lksctp-developers@lists.sourceforge.net, Pawel Hadam Subject: [Tsvwg] Re: [sctp performance] english version presentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Armando, On Wed, 13 Oct 2004, Armando L. Caro Jr. wrote: > On Fri, 8 Oct 2004, Brian F. G. Bidulock wrote: >=20 > > Take a look at > > > > http://www.omg.org/news/meetings/workshops/RT_2003_Manual/Presentat= ions/5-4_Thaker_etal.pdf > > > > which presents failover results nominal 10ms in test situations simil= ar > > to your full mesh experiment on slide 35 of your presentation and als= o > > show much better 1% packet loss latencies. >=20 > 10ms failover?! Clearly this is a special case network and not operatin= g > over a WAN. The presentation details the network and test harness. I believe it was = ethernet connected directly through the harness. RTT for the network was substati= ally below 10ms. The RTO.Min was set to zero (which with Linux 2.4 timer granularit= y is 10ms). I would expect 1ms failovers for 1000Hz kernel clocks. For a WAN, the experiment would lead one to believe that failover times o= f one RTT can be acheived. 10ms should get you across a continent. 100ms should g= et you around the planet. 1s, part way to the moon. I suppose the point is that, when implemented with performance in mind, S= CTP at the transport layer can perform better than many Ethernet bonding solutions a= t the link layer. --brian >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 13 23:56:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14267; Wed, 13 Oct 2004 23:56:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHwtz-0007zh-7h; Thu, 14 Oct 2004 00:07:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHwUl-0005ok-NA; Wed, 13 Oct 2004 23:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHqei-0002uj-4L for tsvwg@megatron.ietf.org; Wed, 13 Oct 2004 17:27:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12799 for ; Wed, 13 Oct 2004 17:27:32 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[jB6FQjjNXWhp9ML2eY0NF7ShV7f5XXOR]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHqpj-0008Fo-7N for tsvwg@ietf.org; Wed, 13 Oct 2004 17:38:56 -0400 Received: from ns.pigworks.openss7.net (IDENT:V+DUDVjiZDYqJBffeu6MPDZSMMvXTyWf@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9DLOFJ17038; Wed, 13 Oct 2004 15:24:15 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9DLOFU14405; Wed, 13 Oct 2004 15:24:15 -0600 Date: Wed, 13 Oct 2004 15:24:14 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro Jr." Subject: Re: [Tsvwg] sctp performance Message-ID: <20041013152414.B13974@openss7.org> References: <200410131844.i9DIi67U014725@nailgun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200410131844.i9DIi67U014725@nailgun.cisco.com>; from me@armandocaro.net on Wed, Oct 13, 2004 at 02:26:09PM -0400 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 i9DLOFJ17038 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 13 Oct 2004 23:41:29 -0400 Cc: Janardhan Iyengar , tsvwg@ietf.org, "Paul D. Amer" , pawel.hadam@imag.fr, sctp-impl@external.cisco.com, gonzalo.camarillo@ericsson.com, lksctp-developers@lists.sourceforge.net, alefelici@libero.it X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Armando, As I'm sure you know, the OpenSS7 SCTP implementation has been using a weighted version of the algorithms from the second paper since 2001. It also uses a fast restoration technique for restoring suspect destinations since 2001. The implementation also uses a (patentable) FR algorithm that is far simpler than the split-FR presented in the first paper. These allow the implementation to exhibit multiplicative throughput and single RTO fail-over simultaneously. Neither algorithm violates AIMD, FR or max burst rules. They are in fact more conservative. I believe I sent you this weighted algorithm some years ago and said it was worthy of attention. ;) Perhaps more interesting than just the pure multiplicative increase is the way that the implementation smoothly adapts and moves out of the way of a single-interface TCP load resulting in maximization of both throughputs. Unfortunately, those results haven't been presented yet. --brian On Wed, 13 Oct 2004, Armando L. Caro Jr. wrote: > Sorry for reviving an old thread, but I'm just getting caught up on thi= s > list. >=20 > On Thu, 7 Oct 2004, Brian F. G. Bidulock wrote: >=20 > > The interesting thing about the OpenSS7 tests were the multiple > > interface tests on SOCK_STREAM, that showed that max throughput was a > > multiple of the number of available interfaces. Once TCP saturates > > a single interface it has nowhere else to go. SCTP can load multiple > > interfaces to saturation. >=20 > I am curious about SCTP is able to increase throughput as the number of > interfaces increase. Jana has showed that simply using all paths with S= CTP > is counter-productive. The transport has to be "smart" about getting > around different issues when doing Concurrent Multipath Transfer (CMT). > Jana has found several issues with "naive" CMT, but has done a nice > job of addressing them one by one. He's still in the process of tacklin= g > more of these issues. >=20 > http://www.cis.udel.edu/~iyengar/publications/2004.spects.iyengar.pdf > http://www.cis.udel.edu/~iyengar/publications/2004.icon.iyengar.pdf >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 14 07:53:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05726; Thu, 14 Oct 2004 07:53:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI4Lr-0008Ra-Io; Thu, 14 Oct 2004 08:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI45t-0000qx-1l; Thu, 14 Oct 2004 07:48:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3uK-0006xY-7e for tsvwg@megatron.ietf.org; Thu, 14 Oct 2004 07:36:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04392 for ; Thu, 14 Oct 2004 07:36:31 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[TXaj+UG/bKJr8dAmPVm1nfRjX30Sp6gF]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI45J-0007vB-JP for tsvwg@ietf.org; Thu, 14 Oct 2004 07:48:04 -0400 Received: from ns.pigworks.openss7.net (IDENT:67LVAi5ExNuSiPOEB8+0E1IXJbZTkxxb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9EBXBJ32228; Thu, 14 Oct 2004 05:33:11 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9EBXA722036; Thu, 14 Oct 2004 05:33:10 -0600 Date: Thu, 14 Oct 2004 05:33:10 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] sctp performance Message-ID: <20041014053310.A21982@openss7.org> References: <200410131844.i9DIi67U014725@nailgun.cisco.com> <20041013152414.B13974@openss7.org> <416E4CB9.3020702@stewart.chicago.il.us> 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: <416E4CB9.3020702@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Thu, Oct 14, 2004 at 05:54:01AM -0400 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 i9EBXBJ32228 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Janardhan Iyengar , tsvwg@ietf.org, "Armando L. Caro Jr." , sctp-impl@external.cisco.com, "Paul D. Amer" , lksctp-developers@lists.sourceforge.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Randall, Armando listed two papers: 1st paper: http://www.cis.udel.edu/~iyengar/publications/2004.spects.iye= ngar.pdf 2nd paper: http://www.cis.udel.edu/~iyengar/publications/2004.icon.iyeng= ar.pdf --brian On Thu, 14 Oct 2004, Randall Stewart wrote: > Brian F. G. Bidulock wrote: > > Armando, > >=20 > > As I'm sure you know, the OpenSS7 SCTP implementation has been using = a > > weighted version of the algorithms from the second paper since 2001.=20 >=20 > Question.... >=20 > What is the "second paper" ... are you refering to some of the > work Armando and Jana have been doing at the U-D or some other > paper? >=20 > R > -- > Randall Stewart --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 14 12:56:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06980; Thu, 14 Oct 2004 12:56:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI94u-0006fU-To; Thu, 14 Oct 2004 13:07:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8h4-00039S-VV; Thu, 14 Oct 2004 12:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8ax-0001v0-6x for tsvwg@megatron.ietf.org; Thu, 14 Oct 2004 12:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05599 for ; Thu, 14 Oct 2004 12:36:48 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8m7-0006FU-Pt for tsvwg@ietf.org; Thu, 14 Oct 2004 12:48:26 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id C45D932BD8; Thu, 14 Oct 2004 12:36:48 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 100E032ADD; Thu, 14 Oct 2004 12:36:47 -0400 (EDT) Date: Thu, 14 Oct 2004 12:36:47 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" Subject: Re: [Tsvwg] sctp performance In-Reply-To: <200410132127.i9DLRf7U017166@nailgun.cisco.com> Message-ID: References: <200410132127.i9DLRf7U017166@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Janardhan Iyengar , sctp-impl@external.cisco.com, tsvwg@ietf.org, lksctp-developers@lists.sourceforge.net, "Paul D. Amer" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Wed, 13 Oct 2004, Brian F. G. Bidulock wrote: > As I'm sure you know, the OpenSS7 SCTP implementation has been using a > weighted version of the algorithms from the second paper since 2001. It > also uses a fast restoration technique for restoring suspect > destinations since 2001. The implementation also uses a (patentable) FR > algorithm that is far simpler than the split-FR presented in the first > paper. These allow the implementation to exhibit multiplicative > throughput and single RTO fail-over simultaneously. Neither algorithm > violates AIMD, FR or max burst rules. They are in fact more > conservative. > > I believe I sent you this weighted algorithm some years ago and said it > was worthy of attention. ;) To be honest, I didn't remember you sending me an algorithm. I dug through my old mails and found a private discussion we had in Nov 2001. I found the weighted algorithm that you're talking about, but the algorithm you sent me was for selecting a destination to retransmit to and failover to. Since the email was sent privately, I don't want to post the algorithm in this public forum without your permission. But in any case, the algorithm/selection process looks reasonable, but I don't see how it applies to Concurrent Multipath Transfer (CMT). Maybe I am misunerstanding you, and you are not doing CMT? Are you saying that additional interfaces multiplies the throughput performance because your failover algorithm is so agressive? You are advocating using PMR=0, RTO.Min=0-10ms, etc. I have also done work that comes to the conclusion that PMR=0 provides the best performance (http://www.armandocaro.net/papers/2004.TR2005-04.acaro.pdf), but an RTO.Min=0-10ms would only work on special case networks (eg, SS7) and not the Internet. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 14 13:03:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07668; Thu, 14 Oct 2004 13:03:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI9Bj-0006qV-0m; Thu, 14 Oct 2004 13:14:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8ua-0006qb-Vf; Thu, 14 Oct 2004 12:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8nF-0004HL-OL for tsvwg@megatron.ietf.org; Thu, 14 Oct 2004 12:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06532 for ; Thu, 14 Oct 2004 12:49:30 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8yS-0006X4-0H for tsvwg@ietf.org; Thu, 14 Oct 2004 13:01:08 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 74DF232CDF; Thu, 14 Oct 2004 12:49:32 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7F83032BD8; Thu, 14 Oct 2004 12:49:30 -0400 (EDT) Date: Thu, 14 Oct 2004 12:49:30 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" Subject: Concurrent Multipath Transfer (was Re: [Tsvwg] sctp performance) In-Reply-To: <200410132127.i9DLRf7U017166@nailgun.cisco.com> Message-ID: References: <200410132127.i9DLRf7U017166@nailgun.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Janardhan Iyengar , tsvwg@ietf.org, sctp-impl@external.cisco.com, "Paul D. Amer" , lksctp-developers@lists.sourceforge.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Brian/all, (I trimmed the Cc list. And I apologize for posting on several lists. But this discussion started on all these lists. Maybe it could move to one/more lists as per interest?) The papers that are referred to in this thread are: http://www.cis.udel.edu/~iyengar/publications/2004.spects.iyengar.pdf http://www.cis.udel.edu/~iyengar/publications/2004.icon.iyengar.pdf I add another paper here, which is currently under submission and is a continuation of CMT work: http://www.cis.udel.edu/~iyengar/publications/2005.icdcs.iyengar.pdf > As I'm sure you know, the OpenSS7 SCTP implementation has been using a > weighted version of the algorithms from the second paper since 2001. [...] > The implementation also uses a (patentable) FR algorithm that is far > simpler than the split-FR presented in the first paper. I certainly did not know that you already implemented these algorithms. I don't think any of the co-authors on the papers knew either. Could you post the algos, or send a reference that we could look up? If your FR algo is far simpler, I would certainly like to look at it, because I could not get the SFR-CACC algo to be simpler than it is. Well, it is simpler than it _was_, but I do not know how to make it any simpler. Also, the first paper presents two other algos - the CUC and DAC algos. At least the CUC algorithm is, IMHO, necessary to see expected throughput, at least if the paths in question have different end-to-end delays. Did you implement something like CUC too? You say the algo is "patentable" - I do not understand what that means. Did you mean to say the algo is "patentED"? So, can you post the algo? Note: The ID (draft-iyengar-sctp-cacc-xx.txt) which was first published in Feb 2002 has expired now, but I'm planning to resubmit it in a new form and with significant additions/modifications. I wanted to spend more time looking at changeover/CMT concerns with SCTP before putting something out as an ID. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Sun Oct 17 19:07:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02824; Sun, 17 Oct 2004 19:07:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJKJH-000106-Rm; Sun, 17 Oct 2004 19:19:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJK3q-0000CW-W6; Sun, 17 Oct 2004 19:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI2le-0007Oy-Qf for tsvwg@megatron.ietf.org; Thu, 14 Oct 2004 06:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26538 for ; Thu, 14 Oct 2004 06:23:28 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI2wj-0006Rh-C8 for tsvwg@ietf.org; Thu, 14 Oct 2004 06:35:01 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9E9tAKG022666; Thu, 14 Oct 2004 05:55:12 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <416E4CB9.3020702@stewart.chicago.il.us> Date: Thu, 14 Oct 2004 05:54:01 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] sctp performance References: <200410131844.i9DIi67U014725@nailgun.cisco.com> <20041013152414.B13974@openss7.org> In-Reply-To: <20041013152414.B13974@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 17 Oct 2004 19:03:33 -0400 Cc: Janardhan Iyengar , alefelici@libero.it, tsvwg@ietf.org, gonzalo.camarillo@ericsson.com, sctp-impl@external.cisco.com, "Paul D. Amer" , lksctp-developers@lists.sourceforge.net, pawel.hadam@imag.fr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Brian F. G. Bidulock wrote: > Armando, > > As I'm sure you know, the OpenSS7 SCTP implementation has been using a > weighted version of the algorithms from the second paper since 2001. Question.... What is the "second paper" ... are you refering to some of the work Armando and Jana have been doing at the U-D or some other paper? R -- Randall Stewart _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 18 08:22:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10648; Mon, 18 Oct 2004 08:22:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWig-0007GB-U2; Mon, 18 Oct 2004 08:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWUr-0000g3-IQ; Mon, 18 Oct 2004 08:20:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWTg-0000VU-Kk for tsvwg@megatron.ietf.org; Mon, 18 Oct 2004 08:19:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10513 for ; Mon, 18 Oct 2004 08:19:03 -0400 (EDT) Received: from baobab.unisa.it ([193.205.160.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWfe-0007Cc-SG for tsvwg@ietf.org; Mon, 18 Oct 2004 08:31:28 -0400 Received: from dimec2.diiie.unisa.it (dimec2.diiie.unisa.it [193.205.164.90]) by baobab.unisa.it (8.13.1/8.13.1) with ESMTP id i9ICIBU2156020 for ; Mon, 18 Oct 2004 14:18:21 +0200 (CEST) From: giuseppe de marco To: TSWG Content-Type: text/plain Message-Id: <1098101957.18185.2.camel@cori9.linux> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 18 Oct 2004 14:19:18 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: (-4.9) BAYES_00 X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Tsvwg] source add X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Anyone know if the problem of source addressing in SCTP has been ever solved? Giuseppe -- Giuseppe De Marco, Ph.D Departement of Information and Electrical Engineering (DIIIE) University of Salerno - Italy via ponte don Melillo Fisciano (SA) tel: +39 089 964012 mail: gdemarco@unisa.it _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 18 12:41:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00532; Mon, 18 Oct 2004 12:41:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJalI-00045X-1c; Mon, 18 Oct 2004 12:53:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJa5n-0001gU-Vr; Mon, 18 Oct 2004 12:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJZsI-0000WD-Q0 for tsvwg@megatron.ietf.org; Mon, 18 Oct 2004 11:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27068 for ; Mon, 18 Oct 2004 11:56:35 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJa4A-0003C4-B3 for tsvwg@ietf.org; Mon, 18 Oct 2004 12:09:03 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9IFuAtr013449; Mon, 18 Oct 2004 11:56:10 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <4173E73E.9040500@stewart.chicago.il.us> Date: Mon, 18 Oct 2004 11:54:38 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: giuseppe de marco Subject: Re: [Tsvwg] source add References: <1098101957.18185.2.camel@cori9.linux> In-Reply-To: <1098101957.18185.2.camel@cori9.linux> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit giuseppe de marco wrote: > Anyone know if the problem of source addressing in SCTP has been ever > solved? > Giuseppe > And what is the 'source addressing problem' in SCTP to be solved? R -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 19 19:35:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01812; Tue, 19 Oct 2004 19:35:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3iN-0007bl-29; Tue, 19 Oct 2004 19:48:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsnF-0007Cv-W9; Tue, 19 Oct 2004 08:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsVb-00042m-NF; Tue, 19 Oct 2004 07:50:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14673; Tue, 19 Oct 2004 07:50:30 -0400 (EDT) Message-Id: <200410191150.HAA14673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:50:30 -0400 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Implementer's Guide Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpimpguide-12.txt Pages : 96 Date : 2004-10-18 This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document. This document updates RFC2960 [6] and text within this document supersedes the text found in RFC2960 [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpimpguide-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18173318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpimpguide-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18173318.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Wed Oct 20 01:06:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28855; Wed, 20 Oct 2004 01:06:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8s9-0007D0-Iv; Wed, 20 Oct 2004 01:18:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5FB-0001yf-SU; Tue, 19 Oct 2004 21:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3fz-0007G4-7B for tsvwg@megatron.ietf.org; Tue, 19 Oct 2004 19:45:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03420 for ; Tue, 19 Oct 2004 19:45:55 -0400 (EDT) Received: from pedigree.cs.ubc.ca ([142.103.6.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3sG-00085h-Iw for tsvwg@ietf.org; Tue, 19 Oct 2004 19:58:41 -0400 Received: from keiths.cs.ubc.ca (keiths.cs.ubc.ca [142.103.10.46]) by pedigree.cs.ubc.ca (8.12.10/8.11.4) with ESMTP id i9JNjpOr021712 for ; Tue, 19 Oct 2004 16:45:51 -0700 (PDT) Date: Tue, 19 Oct 2004 16:45:51 -0700 (PDT) From: Brad Penoff To: tsvwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Tsvwg] chunk bundling X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Greetings, We have been reading about the ability to perform chunk bundling within SCTP, specifically the coalescing of multiple DATA chunks into a single SCTP packet. It is said that this is an option by the application programmer; is the only control simply the ability to turn off/on Nagle's algorithm (SCTP_NODELAY), or is there a finer degree of control (i.e. can we pack a packet with specific DATA chunks) ? If there are other ways, what are they? If SCTP_NODELAY is the only option, is this saying that chunk bundling is applicable to an entire association rather than per stream? Thanks, brad _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed Oct 20 05:25:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13853; Wed, 20 Oct 2004 05:25:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCv1-0003ha-A0; Wed, 20 Oct 2004 05:38:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9P5-0005yO-8M; Wed, 20 Oct 2004 01:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK8Kk-0000tV-64 for tsvwg@megatron.ietf.org; Wed, 20 Oct 2004 00:44:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27138 for ; Wed, 20 Oct 2004 00:44:14 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8Wz-0006fr-8I for tsvwg@ietf.org; Wed, 20 Oct 2004 00:57:02 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.8) with ESMTP id i9K4iBpV045692; Tue, 19 Oct 2004 21:44:11 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200410200444.i9K4iBpV045692@cougar.icir.org> To: mankin@psg.com, Jon Peterson From: Sally Floyd Date: Tue, 19 Oct 2004 21:44:11 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tsvwg@ietf.org Subject: [Tsvwg] agenda item for tsvwg in DC? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This is a request to give a talk on our resurrected and significantly-revised quickstart draft at tsvwg in DC. (I will have to leave IETF this time on Thursday afternoon, so I will see if someone else can give the presentation if tsvwg is being held after that...) The draft: http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt Quick-Start for TCP and IP. Amit Jain, Sally Floyd, Mark Allman, and Pasi Sarolahti. We will also be asking if QuickStart can be added to tsvwg as a work item. Many thanks. - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 07:40:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05574; Thu, 21 Oct 2004 07:40:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbVE-0005Pp-Hb; Thu, 21 Oct 2004 07:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUM2-0008ET-2t; Thu, 21 Oct 2004 00:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKJS-00033X-QF for tsvwg@megatron.ietf.org; Wed, 20 Oct 2004 13:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29748 for ; Wed, 20 Oct 2004 13:31:42 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKVk-0006WX-RB for tsvwg@ietf.org; Wed, 20 Oct 2004 13:44:38 -0400 Received: from Mpierce1@aol.com by imo-m20.mx.aol.com (mail_out_v37_r3.8.) id l.db.1762de46 (17228) for ; Wed, 20 Oct 2004 13:30:50 -0400 (EDT) Message-ID: Date: Wed, 20 Oct 2004 13:30:50 EDT To: tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Tsvwg] New version of draft-silverman-tsvwg-mlefphb-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1030531820==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============1030531820== Content-Type: multipart/alternative; boundary="part1_db.1762de46.2ea7faca_boundary" --part1_db.1762de46.2ea7faca_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit A revised version of the subject document has been placed on the IETF site. For those of you who haven't been following this topic, MLEF allows the application of different handling to different priority of Expedited Forwarding traffic so that higher priority traffic is less affected by congestion which results is packet discard. It is not intended as a replacement for congestion management via some sort of call admission or call manager but complements this option. It must be used in conjuction with these other techniques to provide a complete QoS solution. MLEF operates at the packet level, not the call level using various Diffserv codepoints to distinguish among the various priority of traffic and provides for different discard probabalities, as Assured Forwarding does. It is currently the authors' intention to request that this be published as an individual submission as an Experimental RFC. Comments specific to the described mechanism would be appreciated. Mike Pierce Artel --part1_db.1762de46.2ea7faca_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable A revised ver= sion of the subject document has been placed on the IETF site.

For those of you who haven't been following this topic, MLEF allows the=20= application of different handling to different priority of Expedited Forward= ing traffic so that higher priority traffic is less affected by congestion w= hich results is packet discard.

It is not intended as a replacement for congestion management via some s= ort of call admission or call manager but complements this option. It must b= e used in conjuction with these other techniques to provide a complete QoS s= olution.

MLEF operates at the packet level, not the call level using various Diff= serv codepoints to distinguish among the various priority of traffic and pro= vides for different discard probabalities, as Assured Forwarding does.

It is currently the authors' intention to request that this be published= as an individual submission as an Experimental RFC.

Comments specific to the described mechanism would be appreciated.

Mike Pierce
Artel

--part1_db.1762de46.2ea7faca_boundary-- --===============1030531820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1030531820==-- From tsvwg-bounces@ietf.org Thu Oct 21 07:40:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05710; Thu, 21 Oct 2004 07:40:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbVh-0005RA-7x; Thu, 21 Oct 2004 07:53:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUMF-0008Up-DQ; Thu, 21 Oct 2004 00:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKMP-0003ZU-Cu for tsvwg@megatron.ietf.org; Wed, 20 Oct 2004 13:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00444 for ; Wed, 20 Oct 2004 13:34:45 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKYl-0006lZ-TQ for tsvwg@ietf.org; Wed, 20 Oct 2004 13:47:41 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i9KHYfKM006479; Wed, 20 Oct 2004 10:34:41 -0700 (MST) Received: from motorola.com (d1421-0a1071e2.cig.mot.com [10.16.113.226]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9KHQdtD016492; Wed, 20 Oct 2004 12:26:39 -0500 Message-ID: <4176A229.7080009@motorola.com> Date: Wed, 20 Oct 2004 12:36:41 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brad Penoff Subject: Re: [Tsvwg] chunk bundling References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Brad, To put it in a simple way, SCTP DATA chunk bundling is an opportunistic procedure - where the SCTP sender (not the application above) always tries to bundle as many ready-to-go DATA chunks as the current congestion window allows. There are only very few rules, such as that chunks marked for retrans will go first, etc. Turning SCTP_NODELAY off/on by the app simply increases/decreases the __opportunity__ for the SCTP sender to bundle, and that's all. The idea for this is to maximize the bandwidth efficiency. I am afraid if we create finer controls to this bundling procedure (such as dis-allowing bundling across streams), we will be less successful in maximizing the bandwidth efficiency, which will mean poorer achievable throughput. regards, -Qiaobing Brad Penoff wrote: > Greetings, > > We have been reading about the ability to perform chunk bundling within > SCTP, specifically the coalescing of multiple DATA chunks into a single > SCTP packet. It is said that this is an option by the application > programmer; is the only control simply the ability to turn off/on > Nagle's algorithm (SCTP_NODELAY), or is there a finer degree of control > (i.e. can we pack a packet with specific DATA chunks) ? If there are > other ways, what are they? If SCTP_NODELAY is the only option, is this > saying that chunk bundling is applicable to an entire association rather > than per stream? > > Thanks, > brad > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 08:23:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14182; Thu, 21 Oct 2004 08:23:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcB6-0007fO-0I; Thu, 21 Oct 2004 08:36:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKazI-0002ke-HM; Thu, 21 Oct 2004 07:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKQ1p-00085Y-CA for tsvwg@megatron.ietf.org; Wed, 20 Oct 2004 19:38:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18219 for ; Wed, 20 Oct 2004 19:37:57 -0400 (EDT) Message-Id: <200410202337.TAA18219@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKQEJ-0002xn-PW for tsvwg@ietf.org; Wed, 20 Oct 2004 19:50:57 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKQ1m-0003z8-DY; Wed, 20 Oct 2004 23:37:58 +0000 To: Sally Floyd In-reply-to: Your message of Tue, 19 Oct 2004 21:44:11 -0700. <200410200444.i9K4iBpV045692@cougar.icir.org> Date: Wed, 20 Oct 2004 16:37:58 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tsvwg@ietf.org, Jon Peterson , mankin@psg.com Subject: [Tsvwg] Re: agenda item for tsvwg in DC? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi, Sally, This slot request is fine: there's been significant past discussion and interest on this draft. I assume this would be a proposal for an Experimental work item? Folks, please review. Allison > This is a request to give a talk on our resurrected and > significantly-revised quickstart draft at tsvwg in DC. > > (I will have to leave IETF this time on Thursday afternoon, > so I will see if someone else can give the presentation if > tsvwg is being held after that...) > > The draft: > http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt > Quick-Start for TCP and IP. > Amit Jain, Sally Floyd, Mark Allman, and Pasi Sarolahti. > > We will also be asking if QuickStart can be added to tsvwg > as a work item. > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 08:25:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14566; Thu, 21 Oct 2004 08:25:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcDO-0007lY-DP; Thu, 21 Oct 2004 08:38:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb0s-00077g-UX; Thu, 21 Oct 2004 07:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKQa4-0001vw-P2 for tsvwg@megatron.ietf.org; Wed, 20 Oct 2004 20:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22966 for ; Wed, 20 Oct 2004 20:13:17 -0400 (EDT) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKQmU-0004dv-5b for tsvwg@ietf.org; Wed, 20 Oct 2004 20:26:15 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.8) with ESMTP id i9L0DEq9066555; Wed, 20 Oct 2004 17:13:14 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200410210013.i9L0DEq9066555@cougar.icir.org> To: mankin@psg.com From: Sally Floyd Date: Wed, 20 Oct 2004 17:13:14 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tsvwg@ietf.org, Jon Peterson Subject: [Tsvwg] Re: agenda item for tsvwg in DC? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >I assume this would be a proposal for an Experimental work >item? We have done a lot of work on it, and what we would *really* like would be for QuickStart to end up as Proposed Standard, and to in fact really happen. But it would be a long path from here to there, including developing rough consensus in the working group, the IESG, and the IETF. One possibility would be a step through Experimental on the way to Proposed, as happened with ECN, NewReno, and the like. - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 09:24:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27075; Thu, 21 Oct 2004 09:24:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKd8U-0002T4-TN; Thu, 21 Oct 2004 09:37:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcdR-0002bC-0Y; Thu, 21 Oct 2004 09:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbku-0007zm-GP for tsvwg@megatron.ietf.org; Thu, 21 Oct 2004 08:09:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12457 for ; Thu, 21 Oct 2004 08:09:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbxV-0007CB-AP for tsvwg@ietf.org; Thu, 21 Oct 2004 08:22:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 05:16:40 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9LC8hYJ001658 for ; Thu, 21 Oct 2004 05:08:43 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA06424 for ; Thu, 21 Oct 2004 05:08:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20041021070144.026d91a0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 07:08:43 -0500 To: tsvwg@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Tsvwg] New version of RSVP Bandwidth Reduction ID posted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 All Yesterday draft-polk-tsvwg-rsvp-bw-reduction-00.txt was posted. This is a revision to our original ID given last meeting about bandwidth reduction of RSVP flows. Previously, this ID focused on reducing aggregate flows. This version opens the scope up to individual and encrypted reservation flows as well. This ID can be found at: http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-bw-reduction-00.txt Comments are welcome cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 09:46:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29324; Thu, 21 Oct 2004 09:46:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdU1-000362-IW; Thu, 21 Oct 2004 10:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKd0N-0001Af-Ie; Thu, 21 Oct 2004 09:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcio-0005XT-MA for tsvwg@megatron.ietf.org; Thu, 21 Oct 2004 09:11:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25535 for ; Thu, 21 Oct 2004 09:11:12 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcvQ-00021T-6e for tsvwg@ietf.org; Thu, 21 Oct 2004 09:24:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 06:18:35 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LDAUk2005541; Thu, 21 Oct 2004 06:10:31 -0700 (PDT) Received: from [10.185.205.118] (che-vpn-cluster-1-49.cisco.com [10.86.240.49]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AML46444; Thu, 21 Oct 2004 09:10:35 -0400 (EDT) Date: Thu, 21 Oct 2004 09:10:38 -0400 From: Bruce Davie To: mankin@psg.com Message-ID: <2147483647.1098349837@30-5-158.wireless.csail.mit.edu> In-Reply-To: <200410202337.TAA18219@ietf.org> References: <200410202337.TAA18219@ietf.org> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Jon Peterson Subject: [Tsvwg] agenda item for tsvwg in DC? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit I would also like to request a slot to discuss the new version of "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels" (draft-lefaucheur-rsvp-dste-01.txt). We've revised the draft in response to feedback received during and after the last IETF. The significant changes from the previous (-00) version of this draft are: - added discussion of the relationship to RFC 2746 [RSVP-TUN] - added discussion of mapping policy at aggregator - added discussion of "RSVP proxy" behavior in conjunction with the aggregation scheme described here - added discussion on TTL processing on Deaggregator Bruce _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 21 10:53:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09412; Thu, 21 Oct 2004 10:53:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeVw-00056i-Dv; Thu, 21 Oct 2004 11:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe94-00021v-AP; Thu, 21 Oct 2004 10:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdyP-0006aL-Pt for tsvwg@megatron.ietf.org; Thu, 21 Oct 2004 10:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06141 for ; Thu, 21 Oct 2004 10:31:23 -0400 (EDT) Message-Id: <200410211431.KAA06141@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeB3-0004Sq-9f for tsvwg@ietf.org; Thu, 21 Oct 2004 10:44:29 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKdyO-000563-R4; Thu, 21 Oct 2004 14:31:24 +0000 To: Bruce Davie In-Reply-To: Message from Bruce Davie of "Thu, 21 Oct 2004 09:10:38 EDT." <2147483647.1098349837@30-5-158.wireless.csail.mit.edu> Date: Thu, 21 Oct 2004 07:31:24 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tsvwg@ietf.org, Jon Peterson Subject: [Tsvwg] Re: agenda item for tsvwg in DC? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Bruce, Thanks for the email describing the updates of rsvp-dste. With this new material, in response to the previous discussion, a tsvwg slot makes a lot of sense. > > I would also like to request a slot to discuss the new version of > "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels" > (draft-lefaucheur-rsvp-dste-01.txt). We've revised the draft in response to > feedback received during and after the last IETF. > > The significant changes from the previous (-00) version of this draft > are: > - added discussion of the relationship to RFC 2746 [RSVP-TUN] > - added discussion of mapping policy at aggregator > - added discussion of "RSVP proxy" behavior in conjunction with > the aggregation scheme described here > - added discussion on TTL processing on Deaggregator > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 22 14:32:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27383; Fri, 22 Oct 2004 14:32:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4QW-0003uY-Aw; Fri, 22 Oct 2004 14:46:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL48b-0006X7-32; Fri, 22 Oct 2004 14:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL45h-0005kV-Iq for tsvwg@megatron.ietf.org; Fri, 22 Oct 2004 14:24:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26736 for ; Fri, 22 Oct 2004 14:24:38 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4IS-0003ki-GX for tsvwg@ietf.org; Fri, 22 Oct 2004 14:37:57 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9MIOEtr026234 for ; Fri, 22 Oct 2004 14:24:15 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41795007.1020500@stewart.chicago.il.us> Date: Fri, 22 Oct 2004 14:23:03 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> In-Reply-To: <200410191150.HAA14673@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit All: A point and a question.. We probably need to think about last calling this and closing up the document. I think, based on the last inter-op, we have things pretty well complete as far as clearifications go.. The question.. One thing that has off and on nagged at me is the following wording from RFC2960 ... From 8.4: The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise, ******************************************************************* and From 11.2.4.1 Flooding - not responding to unexpected packets sent to non-unicast addresses. ******************************************************************* Now I realize that these strictures were put there to keep us from setting up an association with a smurf like attack i.e. src from X (the victim) and send an INIT broadcast 255.255.255.255... or even multi-cast... But I wonder, is the wording too strict here?? In the future if you are dealing with "Anycast" .. this is NON-Unicast... and so you have to discard it.. but I could see sometime down the road when we would WANT to respond when sent to an ANYCAST address.... right now V6 limits that to routers... some day anycast may go beyond routers... And SCTP won't be able to use it due to the above wording... I could see... From:IP-A ---INIT(IP-A) -->To:Anycast Address <----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z --From:IP-A-COOKIE-ECHO------->To IP-Z From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z Working just great...and making it so you could establish an SCTP association with an ANYCAST address.... neat idea.. but right now NOT allowed... Soo.. should we just cross that bridge when we come to it... or should we attempt to loosen up the wording for anycast?? R Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Stream Control Transmission Protocol (SCTP) Implementer's Guide > Author(s) : R. Stewart, et al. > Filename : draft-ietf-tsvwg-sctpimpguide-12.txt > Pages : 96 > Date : 2004-10-18 > > This document contains a compilation of all defects found up until > the publishing of this document for the Stream Control Transmission > Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or > technical nature. This document may be thought of as a companion > document to be used in the implementation of SCTP to clarify errors > in the original SCTP document. > > This document updates RFC2960 [6] and text within this document > supersedes the text found in RFC2960 [6]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-tsvwg-sctpimpguide-12.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 22 15:41:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03250; Fri, 22 Oct 2004 15:41:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Un-00056z-Qu; Fri, 22 Oct 2004 15:54:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5AW-0002ol-JF; Fri, 22 Oct 2004 15:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL57H-0008Vw-OB for tsvwg@megatron.ietf.org; Fri, 22 Oct 2004 15:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02635 for ; Fri, 22 Oct 2004 15:30:19 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[fjMUQHm+K92QD1scWbFyUhNmTIwTP+wQ]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Jw-0004ui-UD for tsvwg@ietf.org; Fri, 22 Oct 2004 15:43:39 -0400 Received: from ns.pigworks.openss7.net (IDENT:/gbLX4nTkknQPRH6PsU/M8fpFRygPZew@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9MJU4J31708; Fri, 22 Oct 2004 13:30:04 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9MJU4708702; Fri, 22 Oct 2004 13:30:04 -0600 Date: Fri, 22 Oct 2004 13:30:04 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt Message-ID: <20041022133004.A8554@openss7.org> References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> 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: <41795007.1020500@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Fri, Oct 22, 2004 at 02:23:03PM -0400 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 i9MJU4J31708 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Randall, Loosen 1) to SHOULD. --brian On Fri, 22 Oct 2004, Randall Stewart wrote: > All: >=20 > A point and a question.. >=20 > We probably need to think about last calling this and closing > up the document. I think, based on the last inter-op, we have > things pretty well complete as far as clearifications go.. >=20 >=20 > The question.. >=20 > One thing that has off and on nagged at me is the > following wording from RFC2960 ... >=20 > From 8.4: >=20 > The receiver of an OOTB packet MUST do the following: >=20 > 1) If the OOTB packet is to or from a non-unicast address, silently > discard the packet. Otherwise, > ******************************************************************* > and From 11.2.4.1 Flooding >=20 > - not responding to unexpected packets sent to non-unicast > addresses. >=20 > ******************************************************************* >=20 > Now I realize that these strictures were put there to keep us > from setting up an association with a smurf like attack > i.e. src from X (the victim) and send an INIT > broadcast 255.255.255.255... or even multi-cast... >=20 > But I wonder, is the wording too strict here?? >=20 > In the future if you are dealing with "Anycast" .. this is > NON-Unicast... and so you have to discard it.. but I could > see sometime down the road when we would WANT to respond > when sent to an ANYCAST address.... right now V6 limits that to > routers... some day anycast may go beyond routers... > And SCTP won't be able to use it due to the above > wording... >=20 >=20 > I could see... >=20 > From:IP-A ---INIT(IP-A) -->To:Anycast Address >=20 > <----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z > --From:IP-A-COOKIE-ECHO------->To IP-Z > From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z >=20 > Working just great...and making it so you could > establish an SCTP association with an ANYCAST address.... neat > idea.. but right now NOT allowed... >=20 > Soo.. should we just cross that bridge when we come > to it... or should we attempt to loosen up the wording > for anycast?? >=20 > R >=20 >=20 > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > > This draft is a work item of the Transport Area Working Group Working= Group of the IETF. > >=20 > > Title : Stream Control Transmission Protocol (SCTP) Implementer's G= uide > > Author(s) : R. Stewart, et al. > > Filename : draft-ietf-tsvwg-sctpimpguide-12.txt > > Pages : 96 > > Date : 2004-10-18 > > =09 > > This document contains a compilation of all defects found up until > > the publishing of this document for the Stream Control Transmissio= n > > Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial= or > > technical nature. This document may be thought of as a companion > > document to be used in the implementation of SCTP to clarify error= s > > in the original SCTP document. > >=20 > > This document updates RFC2960 [6] and text within this document > > supersedes the text found in RFC2960 [6]. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.= txt > >=20 > > To remove yourself from the I-D Announcement list, send a message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in the body o= f the message. =20 > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announc= e=20 > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the u= sername > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-tsvwg-sctpimpguide-12.txt". > >=20 > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html=20 > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > >=20 > >=20 > > ---------------------------------------------------------------------= --- > >=20 > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg >=20 >=20 > --=20 > Randall Stewart > 803-345-0369 815-342-5222(cell) >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 22 18:13:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01063; Fri, 22 Oct 2004 18:13:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7sS-0005Ls-Cg; Fri, 22 Oct 2004 18:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6kv-0000hw-Da; Fri, 22 Oct 2004 17:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL61O-0003kh-48 for tsvwg@megatron.ietf.org; Fri, 22 Oct 2004 16:28:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08854 for ; Fri, 22 Oct 2004 16:28:18 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6E9-0006bI-8T for tsvwg@ietf.org; Fri, 22 Oct 2004 16:41:38 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9MKRttr026456; Fri, 22 Oct 2004 16:27:55 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <41796D03.3020902@stewart.chicago.il.us> Date: Fri, 22 Oct 2004 16:26:43 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <20041022133004.A8554@openss7.org> In-Reply-To: <20041022133004.A8554@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit If no one else objects that seems to me like a logical way to do it.. SHOULD throw it away and SHOULD NOT be responding to..... or something like that :-D R Brian F. G. Bidulock wrote: > Randall, > > Loosen 1) to SHOULD. > > --brian > > On Fri, 22 Oct 2004, Randall Stewart wrote: > > >>All: >> >>A point and a question.. >> >> We probably need to think about last calling this and closing >> up the document. I think, based on the last inter-op, we have >> things pretty well complete as far as clearifications go.. >> >> >>The question.. >> >>One thing that has off and on nagged at me is the >>following wording from RFC2960 ... >> >> From 8.4: >> >> The receiver of an OOTB packet MUST do the following: >> >> 1) If the OOTB packet is to or from a non-unicast address, silently >> discard the packet. Otherwise, >>******************************************************************* >>and From 11.2.4.1 Flooding >> >> - not responding to unexpected packets sent to non-unicast >> addresses. >> >>******************************************************************* >> >>Now I realize that these strictures were put there to keep us >>from setting up an association with a smurf like attack >>i.e. src from X (the victim) and send an INIT >>broadcast 255.255.255.255... or even multi-cast... >> >>But I wonder, is the wording too strict here?? >> >>In the future if you are dealing with "Anycast" .. this is >>NON-Unicast... and so you have to discard it.. but I could >>see sometime down the road when we would WANT to respond >>when sent to an ANYCAST address.... right now V6 limits that to >>routers... some day anycast may go beyond routers... >>And SCTP won't be able to use it due to the above >>wording... >> >> >>I could see... >> >>From:IP-A ---INIT(IP-A) -->To:Anycast Address >> >><----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z >>--From:IP-A-COOKIE-ECHO------->To IP-Z >> From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z >> >>Working just great...and making it so you could >>establish an SCTP association with an ANYCAST address.... neat >>idea.. but right now NOT allowed... >> >>Soo.. should we just cross that bridge when we come >>to it... or should we attempt to loosen up the wording >>for anycast?? >> >>R >> >> >>Internet-Drafts@ietf.org wrote: >> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>This draft is a work item of the Transport Area Working Group Working Group of the IETF. >>> >>> Title : Stream Control Transmission Protocol (SCTP) Implementer's Guide >>> Author(s) : R. Stewart, et al. >>> Filename : draft-ietf-tsvwg-sctpimpguide-12.txt >>> Pages : 96 >>> Date : 2004-10-18 >>> >>>This document contains a compilation of all defects found up until >>> the publishing of this document for the Stream Control Transmission >>> Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or >>> technical nature. This document may be thought of as a companion >>> document to be used in the implementation of SCTP to clarify errors >>> in the original SCTP document. >>> >>> This document updates RFC2960 [6] and text within this document >>> supersedes the text found in RFC2960 [6]. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt >>> >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the username >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-ietf-tsvwg-sctpimpguide-12.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>tsvwg mailing list >>>tsvwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/tsvwg >> >> >>-- >>Randall Stewart >>803-345-0369 815-342-5222(cell) >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 22 18:19:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02307; Fri, 22 Oct 2004 18:19:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7yK-0005dC-Kr; Fri, 22 Oct 2004 18:33:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6vP-0007zM-Uu; Fri, 22 Oct 2004 17:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6MK-0007nF-CV for tsvwg@megatron.ietf.org; Fri, 22 Oct 2004 16:50:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13258 for ; Fri, 22 Oct 2004 16:49:56 -0400 (EDT) Received: from nak.isi.edu ([128.9.168.79]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6Z9-00084m-Ob for tsvwg@ietf.org; Fri, 22 Oct 2004 17:03:17 -0400 Received: by nak.isi.edu (Postfix, from userid 3494) id E5F5D4F5391; Fri, 22 Oct 2004 13:49:24 -0700 (PDT) Date: Fri, 22 Oct 2004 13:49:24 -0700 From: Aaron Falk To: tsvwg@ietf.org Message-ID: <20041022204923.GB1215@isi.edu> Mail-Followup-To: tsvwg@ietf.org, xcp@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Cynicism-Level: 3 Organization: USC ISI X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: xcp@isi.edu Subject: [Tsvwg] new XCP draft to be discussed at TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi- We've published an Internet Draft with a spec of XCP, the eXplicit Control Protocol, an experimental congestion control protocol. As the draft's abstract says: XCP is designed to deliver the highest possible end-to-end throughput over a broad range of network infrastructure, including links with very large bandwidth-delay products, which are not well served by the current control algorithms. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular. XCP routers are required to perform a small calculation on congestion state carried in each data packet. XCP routers also periodically recalculate the local parameters required to provide fairness. On the other hand, there is no per-flow congestion state in XCP routers. Our plan is to publish it as an Experimental RFC. Allison and Jon have given us an agenda slot at TSVWG to talk a little about the protocol, preliminary results, and our plans. Find the draft at: http://www.ietf.org/internet-drafts/draft-falk-xcp-spec-00.txt Project page (w/code) at: http://www.isi.edu/isi-xcp Regards, --aaron _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 22 22:03:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22364; Fri, 22 Oct 2004 22:03:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLBSv-00036r-Ms; Fri, 22 Oct 2004 22:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBEd-00014g-Ub; Fri, 22 Oct 2004 22:02:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLB8y-0006p7-N4 for tsvwg@megatron.ietf.org; Fri, 22 Oct 2004 21:56:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21995 for ; Fri, 22 Oct 2004 21:56:31 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLBLu-0002yS-SC for tsvwg@ietf.org; Fri, 22 Oct 2004 22:09:55 -0400 Received: from [10.10.0.75] (c-24-13-174-21.client.comcast.net[24.13.174.21]) by comcast.net (sccrmhc12) with ESMTP id <2004102301553001200h4jm1e> (Authid: peterlei); Sat, 23 Oct 2004 01:55:46 +0000 Message-ID: <4179B9ED.60408@ieee.org> Date: Fri, 22 Oct 2004 20:54:53 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <20041022133004.A8554@openss7.org> <41796D03.3020902@stewart.chicago.il.us> In-Reply-To: <41796D03.3020902@stewart.chicago.il.us> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.1 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: bidulock@openss7.org, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1202415681==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 This is a cryptographically signed message in MIME format. --===============1202415681== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030600040506050807090905" This is a cryptographically signed message in MIME format. --------------ms030600040506050807090905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yup, I'd like to see it as SHOULD silently discard the packet in the first section you excerpted and SHOULD NOT respond to unexpected packets in the second section. regards, --peter Randall Stewart wrote: > If no one else objects that seems to me > like a logical way to do it.. > > SHOULD throw it away > > and SHOULD NOT be responding to..... > > or something like that :-D > > R > > Brian F. G. Bidulock wrote: > >> Randall, >> >> Loosen 1) to SHOULD. >> >> --brian >> >> On Fri, 22 Oct 2004, Randall Stewart wrote: >> >> >>> All: >>> >>> A point and a question.. >>> >>> We probably need to think about last calling this and closing >>> up the document. I think, based on the last inter-op, we have >>> things pretty well complete as far as clearifications go.. >>> >>> >>> The question.. >>> >>> One thing that has off and on nagged at me is the >>> following wording from RFC2960 ... >>> >>> From 8.4: >>> >>> The receiver of an OOTB packet MUST do the following: >>> >>> 1) If the OOTB packet is to or from a non-unicast address, silently >>> discard the packet. Otherwise, >>> ******************************************************************* >>> and From 11.2.4.1 Flooding >>> >>> - not responding to unexpected packets sent to non-unicast >>> addresses. >>> >>> ******************************************************************* >>> >>> Now I realize that these strictures were put there to keep us >>> from setting up an association with a smurf like attack >>> i.e. src from X (the victim) and send an INIT >>> broadcast 255.255.255.255... or even multi-cast... >>> >>> But I wonder, is the wording too strict here?? >>> >>> In the future if you are dealing with "Anycast" .. this is >>> NON-Unicast... and so you have to discard it.. but I could >>> see sometime down the road when we would WANT to respond >>> when sent to an ANYCAST address.... right now V6 limits that to >>> routers... some day anycast may go beyond routers... >>> And SCTP won't be able to use it due to the above >>> wording... >>> >>> >>> I could see... >>> >>> From:IP-A ---INIT(IP-A) -->To:Anycast Address >>> >>> <----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z >>> --From:IP-A-COOKIE-ECHO------->To IP-Z >>> From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z >>> >>> Working just great...and making it so you could >>> establish an SCTP association with an ANYCAST address.... neat >>> idea.. but right now NOT allowed... >>> >>> Soo.. should we just cross that bridge when we come >>> to it... or should we attempt to loosen up the wording >>> for anycast?? >>> >>> R >>> >>> >>> Internet-Drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Transport Area Working Group >>>> Working Group of the IETF. >>>> >>>> Title : Stream Control Transmission Protocol (SCTP) >>>> Implementer's Guide >>>> Author(s) : R. Stewart, et al. >>>> Filename : draft-ietf-tsvwg-sctpimpguide-12.txt >>>> Pages : 96 >>>> Date : 2004-10-18 >>>> >>>> This document contains a compilation of all defects found up until >>>> the publishing of this document for the Stream Control Transmission >>>> Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or >>>> technical nature. This document may be thought of as a companion >>>> document to be used in the implementation of SCTP to clarify errors >>>> in the original SCTP document. >>>> >>>> This document updates RFC2960 [6] and text within this document >>>> supersedes the text found in RFC2960 [6]. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt >>>> >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>>> of the message. You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>>> subscription settings. >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username >>>> "anonymous" and a password of your e-mail address. After logging in, >>>> type "cd internet-drafts" and then >>>> "get draft-ietf-tsvwg-sctpimpguide-12.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant mail >>>> readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> tsvwg mailing list >>>> tsvwg@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >>> >>> -- >>> Randall Stewart >>> 803-345-0369 815-342-5222(cell) >>> >>> _______________________________________________ >>> tsvwg mailing list >>> tsvwg@ietf.org >>> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> >> > > --------------ms030600040506050807090905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwvwrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzE3MjE1NjMzWhcNMDUwMzE3MjE1NjMz WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDX4PR3 QP+rgEBZtv1Q4YhKjRXUZQSk+9xNzesbK7pyirmUxKnm209ZGibDUAb/yC0ghvl3GbvNv/72 cyfC7JVjiABrDxY19L9mRGLKzjlK/bgBPY8SIu4blM/RtyabN4CdYk24LoGPHuLLkJIvvvQR LG0IJIfP8zvoHy0UGzyXOM/S4msxF1zDpBu7lYMe4Dpu5O9uaE2j1G/jswVmO2KMyQmffOGx 0Mw18tiGNMWkjMAwSJnXO2VSHzvh+I3OM71ReFo9ET2TtiXzqdDM5z0/LTsIyy1vP4Ib3Co9 xZNTe6JqVk2BsH7EZKPxi+oD7f/HctNWTZk0sesgba7D97jLAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AB86WuVOs/pHjC4SPdbKb+obiQZVqR813FD3JcW+stkaZQHTPHoln/SYRd3TZcZIXageyme6 f5Gl3lOsamSUrtkov5u6B0vvtuDuMQH7deh1ARTQfC+R3hv29vVQ+uSPlLo/AGWaPcW030NW Bp96xBIESmHBMWGuYWkxMDHII/R+MIIC0TCCAjqgAwIBAgIDC/CtMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAz MTcyMTU2MzNaFw0wNTAzMTcyMTU2MzNaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANfg9HdA/6uAQFm2/VDhiEqNFdRlBKT73E3N6xsrunKKuZTE qebbT1kaJsNQBv/ILSCG+XcZu82//vZzJ8LslWOIAGsPFjX0v2ZEYsrOOUr9uAE9jxIi7huU z9G3Jps3gJ1iTbgugY8e4suQki++9BEsbQgkh8/zO+gfLRQbPJc4z9LiazEXXMOkG7uVgx7g Om7k725oTaPUb+OzBWY7YozJCZ984bHQzDXy2IY0xaSMwDBImdc7ZVIfO+H4jc4zvVF4Wj0R PZO2JfOp0MznPT8tOwjLLW8/ghvcKj3Fk1N7ompWTYGwfsRko/GL6gPt/8dy01ZNmTSx6yBt rsP3uMsCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAHzpa5U6z+keMLhI91spv6huJBlWpHzXcUPclxb6y 2RplAdM8eiWf9JhF3dNlxkhdqB7KZ7p/kaXeU6xqZJSu2Si/m7oHS++24O4xAft16HUBFNB8 L5HeG/b29VD65I+Uuj8AZZo9xbTfQ1YGn3rEEgRKYcExYa5haTEwMcgj9H4wggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjMwMTU0NTNaMCMGCSqGSIb3DQEJ BDEWBBR+EBTnJXq6/J6oKAdrpEWfU1q+uDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC/CtMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTANBgkqhkiG9w0BAQEFAASCAQBh4zus wJ9OWjwircbs6qbRG7zkXVWq0poC7KlVQCllPvQHmDOcL61Uc8eVcPOtmY641IVGvFG3QAJ2 ZgLHPolhCToShdNHJyh+SbRcbjmxevKXgtGElbMX+d5DABfo5bBdlvpn8bqTMYqFoKXoO1eO syvuIiRiwJWp8snIRi5x+j/LKzmvzNriuklx/54yS0F/YS1V4oQNoHmW68ZYDY20cCMRDcIL P4hIIegBDe7D8eEV0EiOqgVbEDZXu4YJUpue/cFRo7Iqgr7LDDrviE2wBuL9GczyfdO45PfY GRj57jpZ35yxgcTl+4Y9npAtAmVeBaKhUNdbemyyiHfM0B+GAAAAAAAA --------------ms030600040506050807090905-- --===============1202415681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1202415681==-- From tsvwg-bounces@ietf.org Sun Oct 24 19:54:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11283; Sun, 24 Oct 2004 19:54:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLsPA-00086u-4G; Sun, 24 Oct 2004 20:08:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLsAD-00049c-SW; Sun, 24 Oct 2004 19:52:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLs7j-000433-50 for tsvwg@megatron.ietf.org; Sun, 24 Oct 2004 19:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11101 for ; Sun, 24 Oct 2004 19:50:03 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLsL1-000835-Jn for tsvwg@ietf.org; Sun, 24 Oct 2004 20:03:54 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9ONnSF28691; Sun, 24 Oct 2004 19:49:29 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Oct 2004 19:49:29 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646501CC02D2@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: Brian E Carpenter , Fred Baker , "Kwok-Ho Chan" Date: Sun, 24 Oct 2004 19:49:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: "Jozef Babiarz \(babiarz@nortelnetworks.com\)" , tsvwg@ietf.org Subject: [Tsvwg] RE: Review comments diffserv-basic-classes-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1868121027==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1868121027== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA24.15896781" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BA24.15896781 Content-Type: text/plain Thanks Brian for the review and comments. Your list of changes has been incorporated into version 04. See below for details. Fred Baker wrote: > At 01:41 PM 08/25/04 +0200, Brian E Carpenter wrote: > >> A couple more thoughts, after a side conversation with Kathie. >> >> As I said, my comfort level is higher, but this doesn't remove some >> older basic concerns... maybe I should have mentioned these in the >> tsvwg meeting, but I was rushing between sessions. >> >> 1. Thirteen classes is about eight too many for real deployments. It >> will be far too easy for readers to miss the essential comment hidden >> in the middle of section 2.1: >> >>> It is expected that network administrators will choose the service >>> classes that they will support based on their need, starting off with >>> three or four service classes for user traffic and add others as the >>> need arises. >> >> >> This really needs to be mentioned earlier and more prominently, with >> some emphasis that all classes are OPTIONAL except that the default >> class is REQUIRED. > > > OK. Specifically where would you like this? How about the end of section 1.2? I think it needs to be in the reader's mind before hitting the details. > [Joe] Added below paragraph to section 1.2: The Default Forwarding "Standard" service class is REQUIRED, all other service classes are OPTIONAL. It is expected that network administrators will choose the level of service differentiation that they will support based on their need, starting off with three or four service classes for user traffic and add others as the need arises. -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, July 16, 2004 10:45 AM To: Fred Baker; Babiarz, Jozef [CAR:0S03:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH] Subject: Re: I-D ACTION:draft-baker-diffserv-basic-classes-03.txt Hi, My comfort level with this is much higher than with the earlier versions. I still have a couple of substantive comments, however. 1. I think you need to add a clear statement somewhere in section 1 like: The facts that four code points are recommended for AF, and that one code point is recommended for EF, are arbitrary choices, and the architecture allows any reasonable number of AF and EF classes simultaneously. The choice of four AF classes and one EF class in the current document is also arbitrary, and operators MAY choose to operate more or fewer of either. [Joe] Added the above statement to Section 1.4 Key Service Concepts, at the end of the first paragraph. 2. Going further in the same direction, since all choices of code points and service classes are arbitrary in the diffserv architecture, I think that almost all the MUSTs in the document should be SHOULDs. There are just a few that could reasonably be left as MUST, namely > The service MUST be engineered so that EF marked packet flows > have sufficient bandwidth in the network to provide guaranteed > delivery. (which really just repeating part of the definition of EF) and > The probability of loss of AF41 traffic MUST NOT > exceed the probability of loss of AF42 traffic, which in turn MUST > NOT exceed the probability of loss of AF43 traffic. (ditto for AF) and > The Standard service class MUST use the Default Forwarding (DF) PHB > defined in [RFC2474] [Joe] Changed all MUST to SHOULD except as noted above. (ditto for DF) You certainly can't have constructs like > RECOMMENDED Network Edge Conditioning: > o At peering points (between two DiffServ networks) where SLAs are > in place, CS6 marked packets MUST be policed, e.g. using a single > rate with burst size (sr+bs) token bucket policer to keep the CS6 > marked packet flows to within the traffic rate specified in the > SLA. with a MUST governed by a RECOMMENDED. [Joe] Changed the MUST to SHOULD throughout the draft. Regards Brian Regards, Joe. email: babiarz@nortelnetworks.com ------_=_NextPart_001_01C4BA24.15896781 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Review comments diffserv-basic-classes-03

Thanks Brian for the review and comments. Your list = of changes has been incorporated into version 04. See below for = details.

Fred Baker wrote:
> At 01:41 PM 08/25/04 +0200, Brian E Carpenter = wrote:
>
>> A couple more thoughts, after a side = conversation with Kathie.
>>
>> As I said, my comfort level is higher, but = this doesn't remove some
>> older basic concerns... maybe I should have = mentioned these in the
>> tsvwg meeting, but I was rushing between = sessions.
>>
>> 1. Thirteen classes is about eight too many = for real deployments. It
>> will be far too easy for readers to miss = the essential comment hidden
>> in the middle of section 2.1:
>>
>>> It is expected that network = administrators will choose the service
>>> classes that they will support based on = their need, starting off with
>>> three or four service classes for user = traffic and add others as the
>>> need arises.
>>
>>
>> This really needs to be mentioned earlier = and more prominently, with
>> some emphasis that all classes are OPTIONAL = except that the default
>> class is REQUIRED.
>
>
> OK. Specifically where would you like = this?

How about the end of section 1.2? I think it needs to = be in the reader's mind before hitting the details.
>
[Joe] Added below paragraph to section 1.2:
The Default Forwarding "Standard" service = class is REQUIRED, all other service classes are OPTIONAL. It is = expected that network administrators will choose the level of service = differentiation that they will support based on their need, starting = off with three or four service classes for user traffic and add others = as the need arises.


-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com] =
Sent: Friday, July 16, 2004 10:45 AM
To: Fred Baker; Babiarz, Jozef [CAR:0S03:EXCH]; = Chan, Kwok-Ho [BL60:470:EXCH]
Subject: Re: I-D = ACTION:draft-baker-diffserv-basic-classes-03.txt

Hi,

My comfort level with this is much higher than with = the
earlier versions. I still have a couple of = substantive
comments, however.

1. I think you need to add a clear statement = somewhere in
section 1 like: The facts that four code points are = recommended
for AF, and that one code point is recommended for = EF, are
arbitrary choices, and the architecture allows any = reasonable
number of AF and EF classes simultaneously. The = choice of
four AF classes and one EF class in the current = document is
also arbitrary, and operators MAY choose to operate = more or
fewer of either.

[Joe] Added the above statement to Section 1.4 Key = Service Concepts, at the end of the first paragraph.

2. Going further in the same direction, since all = choices
of code points and service classes are arbitrary in = the diffserv
architecture, I think that almost all the MUSTs in = the document
should be SHOULDs. There are just a few that could = reasonably
be left as MUST, namely

> The service MUST be engineered so that EF marked = packet flows
>    have sufficient bandwidth in = the network to provide guaranteed
>    delivery. 

(which really just repeating part of the definition = of EF)

and

>   The probability of loss of AF41 = traffic MUST NOT
>    exceed the probability of = loss of AF42 traffic, which in turn MUST
>    NOT exceed the probability of = loss of AF43 traffic.

(ditto for AF)

and

>    The Standard service class = MUST use the Default Forwarding (DF) PHB
>    defined in [RFC2474]

[Joe] Changed all MUST to SHOULD except as noted = above.
(ditto for DF)

You certainly can't have constructs like

>    RECOMMENDED Network Edge = Conditioning:
>    o  At peering points = (between two DiffServ networks) where SLAs are
>       in place, = CS6 marked packets MUST be policed, e.g.  using a single
>       rate with = burst size (sr+bs) token bucket policer to keep the CS6
>       marked = packet flows to within the traffic rate specified in the
>       SLA.

with a MUST governed by a RECOMMENDED.
[Joe] Changed the MUST to SHOULD throughout the = draft.

Regards
     Brian

Regards, Joe.
email: babiarz@nortelnetworks.com

------_=_NextPart_001_01C4BA24.15896781-- --===============1868121027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1868121027==-- From tsvwg-bounces@ietf.org Mon Oct 25 04:59:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02361; Mon, 25 Oct 2004 04:59:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0uj-0000wX-2F; Mon, 25 Oct 2004 05:13:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0el-0005F1-R9; Mon, 25 Oct 2004 04:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0d8-0004in-Gj for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 04:55:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02188 for ; Mon, 25 Oct 2004 04:55:04 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0qY-0000t9-15 for tsvwg@ietf.org; Mon, 25 Oct 2004 05:08:58 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9P8t4WR020546 for ; Mon, 25 Oct 2004 10:55:04 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 10:55:04 +0200 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSKX3ZP; Mon, 25 Oct 2004 10:55:03 +0200 Received: from [164.48.140.123] (dhcp4-123.eed.ericsson.se [164.48.140.123]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id KAA01294 for ; Mon, 25 Oct 2004 10:55:02 +0200 (MET DST) Message-ID: <417CBF66.2030603@ericsson.com> Date: Mon, 25 Oct 2004 10:55:02 +0200 X-Sybari-Trust: 4f507a22 bfd556f1 62836ef0 00000139 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> In-Reply-To: <41795007.1020500@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2004 08:55:04.0404 (UTC) FILETIME=[51C2C940:01C4BA70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Hi all, I'd like to bring up another clarification which didn't make it into the imp-guide in time (although I understand that the authors in principle agree to include it). It is a clarification of Karn's algorithm which sometimes results in wrong RTT samples being taken if not properly implemented. AFAIK this problem is not clearly spelled out in RFC 2918 or other related IETF docs (please correct me if I'm wrong). I know of at least one SCTP stack (and a certain simulator :) where this is currently not correctly implemented. In essence, a cumulative ACK resulting from a retransmission of an earlier packet can be mistaken for an ACK for a timed packet. For illustration, consider the following example: - Host A sends packets 1, 2 and 3 to host B, and choses packet 3 for an RTT measurement - Host B receives all packets correctly and sends ACK1, ACK2, and ACK3 - ACK2 and ACK3 are lost on the return path - Eventually a timeout fires for packet 2, and A retransmits 2 - Upon receipt of 2, B sends a cumulative ACK3 (since it has received 2 and 3 before) - Since packet 3 has never been retransmitted, even an SCTP implementation strictly following 2960 could actually accept the ACK for an RTT measurement, although it was sent in reply to the retransmission of 2, resulting in a much too high RTT estimate. Since this tends to happen in case of longer link interruptions, the error is often amplified by subsequent timer back-offs. The solution is to either cancel all pending RTT timings upon entering the recovery phase (which is what e.g. BSD TCP does), or to cancel timings for packets with TSNs higher than the retransmitted one. (note that this issue is not a problem for TCP stacks using timestamps) We propose to include the following clarification in the imp-guide: Karn's algorithm: RTT measurements MUST only be made using a packet with TSN r if no packet with TSN less than or equal to r is retransmitted since r was first sent. BR, Stephan. Randall Stewart wrote: > All: > > A point and a question.. > > We probably need to think about last calling this and closing > up the document. I think, based on the last inter-op, we have > things pretty well complete as far as clearifications go.. > > > The question.. > > One thing that has off and on nagged at me is the > following wording from RFC2960 ... > > From 8.4: > > The receiver of an OOTB packet MUST do the following: > > 1) If the OOTB packet is to or from a non-unicast address, silently > discard the packet. Otherwise, > ******************************************************************* > and From 11.2.4.1 Flooding > > - not responding to unexpected packets sent to non-unicast > addresses. > > ******************************************************************* > > Now I realize that these strictures were put there to keep us > from setting up an association with a smurf like attack > i.e. src from X (the victim) and send an INIT > broadcast 255.255.255.255... or even multi-cast... > > But I wonder, is the wording too strict here?? > > In the future if you are dealing with "Anycast" .. this is > NON-Unicast... and so you have to discard it.. but I could > see sometime down the road when we would WANT to respond > when sent to an ANYCAST address.... right now V6 limits that to > routers... some day anycast may go beyond routers... > And SCTP won't be able to use it due to the above > wording... > > > I could see... > > From:IP-A ---INIT(IP-A) -->To:Anycast Address > > <----To:IP-A ---INIT-ACK(IP-Z,AnyCast)from IP-Z > --From:IP-A-COOKIE-ECHO------->To IP-Z > From:IP-A<------COOKIE-ACK+ASCONF(Delete Anycast)----From:IP-Z > > Working just great...and making it so you could > establish an SCTP association with an ANYCAST address.... neat > idea.. but right now NOT allowed... > > Soo.. should we just cross that bridge when we come > to it... or should we attempt to loosen up the wording > for anycast?? > > R > > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Transport Area Working Group Working Group of the IETF. >> >> Title : Stream Control Transmission Protocol (SCTP) Implementer's Guide >> Author(s) : R. Stewart, et al. >> Filename : draft-ietf-tsvwg-sctpimpguide-12.txt >> Pages : 96 >> Date : 2004-10-18 >> >> This document contains a compilation of all defects found up until >> the publishing of this document for the Stream Control Transmission >> Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or >> technical nature. This document may be thought of as a companion >> document to be used in the implementation of SCTP to clarify errors >> in the original SCTP document. >> >> This document updates RFC2960 [6] and text within this document >> supersedes the text found in RFC2960 [6]. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-tsvwg-sctpimpguide-12.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-12.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 06:09:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09350; Mon, 25 Oct 2004 06:09:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM20T-0002dN-AT; Mon, 25 Oct 2004 06:23:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM1iD-0004tq-Bs; Mon, 25 Oct 2004 06:04:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM1ee-0004gw-JM for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 06:00:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08135 for ; Mon, 25 Oct 2004 06:00:41 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[K7YVxgFJoa8wQxDWnr1Uak4bsu63S2Gb]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM1ru-0002LA-LA for tsvwg@ietf.org; Mon, 25 Oct 2004 06:14:37 -0400 Received: from ns.pigworks.openss7.net (IDENT:uiDq4GuNphOAJnqC1i0zXK8huWLP2J0u@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9PA0SJ02993; Mon, 25 Oct 2004 04:00:28 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9PA0R816773; Mon, 25 Oct 2004 04:00:27 -0600 Date: Mon, 25 Oct 2004 04:00:27 -0600 From: "Brian F. G. Bidulock" To: Stephan Baucke Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt Message-ID: <20041025040027.A16702@openss7.org> References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <417CBF66.2030603@ericsson.com>; from stephan.baucke@ericsson.com on Mon, Oct 25, 2004 at 10:55:02AM +0200 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 i9PA0SJ02993 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Stephan, What damage might occur to the network otherwise that justifies using MUST here? What interoperability problems would occur? Too high an RTT estimate doesn't look like a problem to anybody but the sender, and appears to be more of a local performance consideration to me... It might warrant an implementation note, but a "MUST" level requirement would need to be justified. --brian On Mon, 25 Oct 2004, Stephan Baucke wrote: > Hi all, >=20 > I'd like to bring up another clarification which didn't make it into th= e > imp-guide in time (although I understand that the authors in principle > agree to include it). It is a clarification of Karn's algorithm which > sometimes results in wrong RTT samples being taken if not properly > implemented. AFAIK this problem is not clearly spelled out in RFC 2918 > or other related IETF docs (please correct me if I'm wrong). I know of > at least one SCTP stack (and a certain simulator :) where this is > currently not correctly implemented. In essence, a cumulative ACK > resulting from a retransmission of an earlier packet can be mistaken fo= r > an ACK for a timed packet. For illustration, consider the following exa= mple: >=20 > - Host A sends packets 1, 2 and 3 to host B, and choses packet 3 for an > RTT measurement > - Host B receives all packets correctly and sends ACK1, ACK2, and ACK3 > - ACK2 and ACK3 are lost on the return path > - Eventually a timeout fires for packet 2, and A retransmits 2 > - Upon receipt of 2, B sends a cumulative ACK3 (since it has received 2 > and 3 before) > - Since packet 3 has never been retransmitted, even an SCTP > implementation strictly following 2960 could actually accept the ACK fo= r > an RTT measurement, although it was sent in reply to the retransmission > of 2, resulting in a much too high RTT estimate. Since this tends to > happen in case of longer link interruptions, the error is often > amplified by subsequent timer back-offs. >=20 > The solution is to either cancel all pending RTT timings upon entering > the recovery phase (which is what e.g. BSD TCP does), or to cancel > timings for packets with TSNs higher than the retransmitted one. (note > that this issue is not a problem for TCP stacks using timestamps) >=20 > We propose to include the following clarification in the imp-guide: >=20 > Karn's algorithm: RTT measurements MUST only be made using a packet > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. >=20 > BR, > Stephan. >=20 >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 07:14:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14200; Mon, 25 Oct 2004 07:14:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM31O-0003tm-9C; Mon, 25 Oct 2004 07:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2lJ-0002hu-HR; Mon, 25 Oct 2004 07:11:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM2hO-0002Th-Iz for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 07:07:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13583 for ; Mon, 25 Oct 2004 07:07:35 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM2uf-0003mB-CR for tsvwg@ietf.org; Mon, 25 Oct 2004 07:21:32 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9PB7QfM029585 for ; Mon, 25 Oct 2004 13:07:26 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 13:07:26 +0200 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VSV5WL7P; Mon, 25 Oct 2004 13:07:16 +0200 Received: from [164.48.140.123] (dhcp4-123.eed.ericsson.se [164.48.140.123]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id NAA16541 for ; Mon, 25 Oct 2004 13:07:16 +0200 (MET DST) Message-ID: <417CDE64.8050700@ericsson.com> Date: Mon, 25 Oct 2004 13:07:16 +0200 X-Sybari-Trust: abd618a8 bfd556f1 62836ef0 00000139 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> In-Reply-To: <20041025040027.A16702@openss7.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2004 11:07:26.0726 (UTC) FILETIME=[CFC0F260:01C4BA82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Brian, after taking a peek into RFC 2119, I agree that the use of "MUST" seems inappropriate, since there appears to be no danger of harming the network or limiting interoperability. The clarification is meant to point out a potential pitfall to implementers which can lead to incorrect RTO calculations and bad performance. BR, Stephan. Brian F. G. Bidulock wrote: > Stephan, > > What damage might occur to the network otherwise that justifies using > MUST here? What interoperability problems would occur? > > Too high an RTT estimate doesn't look like a problem to anybody but > the sender, and appears to be more of a local performance consideration > to me... > > It might warrant an implementation note, but a "MUST" level requirement > would need to be justified. > > --brian > > On Mon, 25 Oct 2004, Stephan Baucke wrote: > >> Hi all, >> >> I'd like to bring up another clarification which didn't make it into the >> imp-guide in time (although I understand that the authors in principle >> agree to include it). It is a clarification of Karn's algorithm which >> sometimes results in wrong RTT samples being taken if not properly >> implemented. AFAIK this problem is not clearly spelled out in RFC 2918 >> or other related IETF docs (please correct me if I'm wrong). I know of >> at least one SCTP stack (and a certain simulator :) where this is >> currently not correctly implemented. In essence, a cumulative ACK >> resulting from a retransmission of an earlier packet can be mistaken for >> an ACK for a timed packet. For illustration, consider the following example: >> >> - Host A sends packets 1, 2 and 3 to host B, and choses packet 3 for an >> RTT measurement >> - Host B receives all packets correctly and sends ACK1, ACK2, and ACK3 >> - ACK2 and ACK3 are lost on the return path >> - Eventually a timeout fires for packet 2, and A retransmits 2 >> - Upon receipt of 2, B sends a cumulative ACK3 (since it has received 2 >> and 3 before) >> - Since packet 3 has never been retransmitted, even an SCTP >> implementation strictly following 2960 could actually accept the ACK for >> an RTT measurement, although it was sent in reply to the retransmission >> of 2, resulting in a much too high RTT estimate. Since this tends to >> happen in case of longer link interruptions, the error is often >> amplified by subsequent timer back-offs. >> >> The solution is to either cancel all pending RTT timings upon entering >> the recovery phase (which is what e.g. BSD TCP does), or to cancel >> timings for packets with TSNs higher than the retransmitted one. (note >> that this issue is not a problem for TCP stacks using timestamps) >> >> We propose to include the following clarification in the imp-guide: >> >> Karn's algorithm: RTT measurements MUST only be made using a packet >> with TSN r if no packet with TSN less than or equal to r is >> retransmitted since r was first sent. >> >> BR, >> Stephan. >> >> > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 12:23:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11359; Mon, 25 Oct 2004 12:23:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7q4-00029H-TG; Mon, 25 Oct 2004 12:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7P7-000219-Dr; Mon, 25 Oct 2004 12:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7Mo-00017x-E0 for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 12:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09434 for ; Mon, 25 Oct 2004 12:06:38 -0400 (EDT) Received: from mail.cyut.edu.tw ([163.17.1.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7aG-0001fq-NI for tsvwg@ietf.org; Mon, 25 Oct 2004 12:20:37 -0400 Received: from cyut.edu.tw (localhost [127.0.0.1]) by mail.cyut.edu.tw (8.12.11/8.12.11) with ESMTP id i9PG5qpf009155 for ; Tue, 26 Oct 2004 00:05:52 +0800 (CST) X-Authentication-Warning: mail.cyut.edu.tw: iscan owned process doing -bs From: "Luo(2) Jui(4) Jen(2)" To: tsvwg@ietf.org Date: Tue, 26 Oct 2004 00:05:51 +0800 Message-Id: <20041025155400.M15181@cyut.edu.tw> X-Mailer: Open WebMail 2.32 20040525 X-OriginatingIP: 203.67.214.156 (s9230605) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.9 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Tsvwg] why does SCTP only support non-unicast address? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi all: In the RFC 2960, page 95, section 8.4 Handle "out of the blue" packets, ... 1) If the OOBT packet is to or from a non-unicast address, silently discard the packet. Question: Why does the SCTP only support non-unicast address? -- Chaoyang University of Technology WebMail http://webmail.cyut.edu.tw _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 15:47:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27835; Mon, 25 Oct 2004 15:47:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMB2B-00067v-Iw; Mon, 25 Oct 2004 16:01:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAmh-0006z4-It; Mon, 25 Oct 2004 15:45:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAmU-0006uG-Rs for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 15:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27720 for ; Mon, 25 Oct 2004 15:45:24 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAzq-0005wi-Dq for tsvwg@ietf.org; Mon, 25 Oct 2004 15:59:24 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B0F0832A1E; Mon, 25 Oct 2004 15:45:15 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 7B5C932D3E; Mon, 25 Oct 2004 15:45:14 -0400 (EDT) Date: Mon, 25 Oct 2004 15:45:14 -0400 (EDT) From: "Armando L. Caro, Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt In-Reply-To: <417CBF66.2030603@ericsson.com> Message-ID: References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Randall Stewart -- Randall Stewart \(cisco\)" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Mon, 25 Oct 2004, Stephan Baucke wrote: > I'd like to bring up another clarification which didn't make it into the > imp-guide in time (although I understand that the authors in principle > agree to include it). It is a clarification of Karn's algorithm which > sometimes results in wrong RTT samples being taken if not properly > implemented. > We propose to include the following clarification in the imp-guide: > > Karn's algorithm: RTT measurements MUST only be made using a packet > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. Yes, that's my fault. I was supposed to put that change in. Randall: Since I currently can't log into your machine, can you make the change? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 15:53:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28300; Mon, 25 Oct 2004 15:53:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMB7y-0006DR-RA; Mon, 25 Oct 2004 16:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAqZ-0008Tt-Gh; Mon, 25 Oct 2004 15:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAnz-0007Pq-2H for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 15:46:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27792 for ; Mon, 25 Oct 2004 15:46:56 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMB1U-0005ye-RV for tsvwg@ietf.org; Mon, 25 Oct 2004 16:00:57 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 471B832ECE; Mon, 25 Oct 2004 15:46:58 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 6CF6F32E3F; Mon, 25 Oct 2004 15:46:47 -0400 (EDT) Date: Mon, 25 Oct 2004 15:46:47 -0400 (EDT) From: "Armando L. Caro, Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: "Brian F. G. Bidulock" Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt In-Reply-To: <20041025040027.A16702@openss7.org> Message-ID: References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Stephan Baucke , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Mon, 25 Oct 2004, Brian F. G. Bidulock wrote: > What damage might occur to the network otherwise that justifies using > MUST here? What interoperability problems would occur? > > Too high an RTT estimate doesn't look like a problem to anybody but > the sender, and appears to be more of a local performance consideration > to me... > > It might warrant an implementation note, but a "MUST" level requirement > would need to be justified. Well the wording that Stephan provided is just a modification of the current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST" level requirement. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 19:10:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10910; Mon, 25 Oct 2004 19:10:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMECD-0001oJ-Qi; Mon, 25 Oct 2004 19:24:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBUj-0004wC-0T; Mon, 25 Oct 2004 16:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB7X-0007jm-6Q for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 16:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00055 for ; Mon, 25 Oct 2004 16:07:08 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[aRM98ARgPAtl1V+T7JPC+xAYBm0y11Jm]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBKs-0006Xt-Nr for tsvwg@ietf.org; Mon, 25 Oct 2004 16:21:09 -0400 Received: from ns.pigworks.openss7.net (IDENT:D49Gp4A1KvVZ4IxqT33RNQJeWq1ssPTj@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9PK6wJ13059; Mon, 25 Oct 2004 14:06:58 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9PK6wL23546; Mon, 25 Oct 2004 14:06:58 -0600 Date: Mon, 25 Oct 2004 14:06:58 -0600 From: "Brian F. G. Bidulock" To: "Armando L. Caro, Jr." Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt Message-ID: <20041025140658.A22711@openss7.org> References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> 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 me@armandocaro.net on Mon, Oct 25, 2004 at 03:46:47PM -0400 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 i9PK6wJ13059 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: Stephan Baucke , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Armando, On Mon, 25 Oct 2004, Armando L. Caro, Jr. wrote: > On Mon, 25 Oct 2004, Brian F. G. Bidulock wrote: >=20 > > What damage might occur to the network otherwise that justifies using > > MUST here? What interoperability problems would occur? > > > > Too high an RTT estimate doesn't look like a problem to anybody but > > the sender, and appears to be more of a local performance considerati= on > > to me... > > > > It might warrant an implementation note, but a "MUST" level requireme= nt > > would need to be justified. >=20 > Well the wording that Stephan provided is just a modification of the > current wording in RFC2960's Section 6.3.1.C5, which already uses a "MU= ST" > level requirement. Yes, not calculating the RTT correctly can damage the network. (Just not in the way Stephan details.) --brian >=20 > ~armando >=20 > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 19:31:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15606; Mon, 25 Oct 2004 19:31:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEWX-0003Oa-Dq; Mon, 25 Oct 2004 19:45:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBVB-0005bY-KU; Mon, 25 Oct 2004 16:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB9S-0000O7-IA for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 16:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00723 for ; Mon, 25 Oct 2004 16:09:08 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBMx-0006gj-DD for tsvwg@ietf.org; Mon, 25 Oct 2004 16:23:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2004 13:20:14 -0700 X-BrightmailFiltered: true 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.10/8.12.6) with ESMTP id i9PK956s008908; Mon, 25 Oct 2004 13:09:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BAJ34771; Mon, 25 Oct 2004 13:08:04 -0700 (PDT) Message-ID: <417D5CB1.30607@cisco.com> Date: Mon, 25 Oct 2004 16:06:09 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Armando@mail.eecis.udel.edu Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Armando@mail.eecis.udel.edu wrote: > On Mon, 25 Oct 2004, Stephan Baucke wrote: > > >>I'd like to bring up another clarification which didn't make it into the >>imp-guide in time (although I understand that the authors in principle >>agree to include it). It is a clarification of Karn's algorithm which >>sometimes results in wrong RTT samples being taken if not properly >>implemented. > > > > >>We propose to include the following clarification in the imp-guide: >> >>Karn's algorithm: RTT measurements MUST only be made using a packet >>with TSN r if no packet with TSN less than or equal to r is >>retransmitted since r was first sent. > > > Yes, that's my fault. I was supposed to put that change in. > > Randall: Since I currently can't log into your machine, can you make the > change? > Yep... I will do so.. but I will change the MUST to a SHOULD per the comments on the list so far.. R > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 > -- Randall Stewart ITD 803-345-0369 815-342-5222 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Mon Oct 25 20:00:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20917; Mon, 25 Oct 2004 20:00:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEyn-0004xW-DD; Mon, 25 Oct 2004 20:14:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMETt-000110-CQ; Mon, 25 Oct 2004 19:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDGd-0001xS-SO for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 18:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00262 for ; Mon, 25 Oct 2004 18:24:40 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDU5-0006v1-Fr for tsvwg@ietf.org; Mon, 25 Oct 2004 18:38:42 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9PMKhT8005795; Mon, 25 Oct 2004 18:21:28 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417D7BE3.3080104@stewart.chicago.il.us> Date: Mon, 25 Oct 2004 18:19:15 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luo(2) Jui(4) Jen(2)" Subject: Re: [Tsvwg] why does SCTP only support non-unicast address? References: <20041025155400.M15181@cyut.edu.tw> In-Reply-To: <20041025155400.M15181@cyut.edu.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Because in the normal case you cannot have an association with a non-unicast address. If I send you a broadcast (DATA), how can you know its me? Also it presents a DOS attack if you accept non-unicast addresses. The exception to this might be any-cast.. where one and only one machine is contacted... one could envision (as my previous post said) using anycast and SCTP in combination with the ASCONF() to delete the anycast address. R Luo(2) Jui(4) Jen(2) wrote: > Hi all: > In the RFC 2960, page 95, section 8.4 Handle "out of the blue" packets, ... > > 1) If the OOBT packet is to or from a non-unicast address, silently discard > the packet. > > Question: > Why does the SCTP only support non-unicast address? > > -- > Chaoyang University of Technology > WebMail http://webmail.cyut.edu.tw > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 26 05:17:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15665; Tue, 26 Oct 2004 05:17:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNg2-0006p4-5n; Tue, 26 Oct 2004 05:31:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNMY-0003E7-9Y; Tue, 26 Oct 2004 05:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMNLb-0002xO-1e for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 05:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14403 for ; Tue, 26 Oct 2004 05:10:28 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMNZ2-0006e9-U4 for tsvwg@ietf.org; Tue, 26 Oct 2004 05:24:36 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9Q9AIfM003854 for ; Tue, 26 Oct 2004 11:10:18 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 11:10:18 +0200 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJRSTD15; Tue, 26 Oct 2004 11:10:17 +0200 Received: from [164.48.140.123] (dhcp4-123.eed.ericsson.se [164.48.140.123]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id LAA00828 for ; Tue, 26 Oct 2004 11:10:16 +0200 (MET DST) Message-ID: <417E1478.8060609@ericsson.com> Date: Tue, 26 Oct 2004 11:10:16 +0200 X-Sybari-Trust: 2ac71539 8cefd49f 56865142 00000138 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 09:10:18.0435 (UTC) FILETIME=[9CFA9930:01C4BB3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Armando L. Caro, Jr. wrote: >> What damage might occur to the network otherwise that justifies using >> MUST here? What interoperability problems would occur? >> >> Too high an RTT estimate doesn't look like a problem to anybody but >> the sender, and appears to be more of a local performance consideration >> to me... >> >> It might warrant an implementation note, but a "MUST" level requirement >> would need to be justified. > > Well the wording that Stephan provided is just a modification of the > current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST" > level requirement. I'd say it depends on whether the new text will be put into the imp-guide as a _replacement_ for the 2960 text, or as an addendum. In the first case we will have to keep the MUST, since failure to comply with the part of the rule already in 2960 may (as Brian correctly pointed out) harm the network. If it is meant as an addendum containing just the clarification about retransmitted packets with a smaller TSNs, I guess a SHOULD would be appropriate. BR, Stephan. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 26 07:18:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24352; Tue, 26 Oct 2004 07:18:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPZ0-0000d5-7u; Tue, 26 Oct 2004 07:32:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPEd-0004oW-6G; Tue, 26 Oct 2004 07:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPDd-0004cy-Nh for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 07:10:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23973 for ; Tue, 26 Oct 2004 07:10:22 -0400 (EDT) Received: from dpc674425142.direcpc.com ([67.44.25.142] helo=stewart.chicago.il.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPRF-0000VL-JD for tsvwg@ietf.org; Tue, 26 Oct 2004 07:24:32 -0400 Received: from stewart.chicago.il.us (localhost [127.0.0.1]) by stewart.chicago.il.us (8.12.9p2/8.12.8) with ESMTP id i9QB9pT8007326; Tue, 26 Oct 2004 07:09:55 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417E3024.2090603@stewart.chicago.il.us> Date: Tue, 26 Oct 2004 07:08:20 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Baucke Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> <417E1478.8060609@ericsson.com> In-Reply-To: <417E1478.8060609@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Stephan: IMO this is something that should be ADDED to the text as an implementation note: aka: IMPLEMENTATION NOTE: RTT measurements should only be made using a packet with TSN r if no packet with TSN less than or equal to r is retransmitted since r was first sent. Does that sound agreeable to everyone... note the original text in the MUST clause will remain.. R Stephan Baucke wrote: > Armando L. Caro, Jr. wrote: > > >>>What damage might occur to the network otherwise that justifies using >>>MUST here? What interoperability problems would occur? >>> >>>Too high an RTT estimate doesn't look like a problem to anybody but >>>the sender, and appears to be more of a local performance consideration >>>to me... >>> >>>It might warrant an implementation note, but a "MUST" level requirement >>>would need to be justified. >> >>Well the wording that Stephan provided is just a modification of the >>current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST" >>level requirement. > > > I'd say it depends on whether the new text will be put into the > imp-guide as a _replacement_ for the 2960 text, or as an addendum. In > the first case we will have to keep the MUST, since failure to comply > with the part of the rule already in 2960 may (as Brian correctly > pointed out) harm the network. If it is meant as an addendum containing > just the clarification about retransmitted packets with a smaller TSNs, > I guess a SHOULD would be appropriate. > > BR, > Stephan. > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 26 07:45:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27959; Tue, 26 Oct 2004 07:45:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPyx-0001CJ-72; Tue, 26 Oct 2004 07:59:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPcL-0001gB-Fd; Tue, 26 Oct 2004 07:35:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPbO-0001Ww-4m for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 07:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25824 for ; Tue, 26 Oct 2004 07:34:56 -0400 (EDT) Received: from gw.openss7.com ([142.179.199.224] ident=[j9yrLwAZbPCdoTwFXlT5hqIKVuXUhPuD]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPor-0000y9-Rk for tsvwg@ietf.org; Tue, 26 Oct 2004 07:49:04 -0400 Received: from ns.pigworks.openss7.net (IDENT:og3qutBYZUxKtMomQXWkYcUv+wjPdz5h@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id i9QBYVJ28313; Tue, 26 Oct 2004 05:34:31 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id i9QBYVG31529; Tue, 26 Oct 2004 05:34:31 -0600 Date: Tue, 26 Oct 2004 05:34:30 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt Message-ID: <20041026053430.A31489@openss7.org> References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> <417E1478.8060609@ericsson.com> <417E3024.2090603@stewart.chicago.il.us> 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: <417E3024.2090603@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, Oct 26, 2004 at 07:08:20AM -0400 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 i9QBYVJ28313 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Stephan Baucke , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Randall, I agree that it is best as a supplemental implementation note as worded. --brian On Tue, 26 Oct 2004, Randall Stewart wrote: > Stephan: >=20 > IMO this is something that should be ADDED to the > text as an implementation note: >=20 > aka: >=20 > IMPLEMENTATION NOTE: RTT measurements should only be made using a packe= t > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. >=20 >=20 > Does that sound agreeable to everyone... note the original > text in the MUST clause will remain.. >=20 > R >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 26 09:20:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04535; Tue, 26 Oct 2004 09:20:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMRT8-00033Q-4I; Tue, 26 Oct 2004 09:34:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMREc-00039I-Rd; Tue, 26 Oct 2004 09:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMRCd-0002ew-H3 for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 09:17:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04272 for ; Tue, 26 Oct 2004 09:17:29 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMRQI-0002ya-Gw for tsvwg@ietf.org; Tue, 26 Oct 2004 09:31:38 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9QDGjs23055; Tue, 26 Oct 2004 09:16:46 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 09:16:44 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646501D54702@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: tsvwg@ietf.org Date: Tue, 26 Oct 2004 09:16:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4BB5E.0697962D" X-Spam-Score: 0.8 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: Jozef Babiarz , Kwok-Ho Chan , fred@cisco.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [Tsvwg] New version of draft-baker-diffserv-basic-classes-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C4BB5E.0697962D Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB5E.0697962D" ------_=_NextPart_001_01C4BB5E.0697962D Content-Type: text/plain The 04 version of the draft has all the reviewers comments addressed. Regards, Joe. Jozef Babiarz email: babiarz@nortelnetworks.com ************************************* A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Configuration Guidelines for DiffServ Service Classes Author(s) : F. Baker, et al. Filename : draft-baker-diffserv-basic-classes-04.txt Pages : 56 Date : 2004-10-25 This paper summarizes the recommended correlation between service classes and their usage, with references to their corresponding recommended Differentiated Service Code Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB) and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioner PHBs and AQM be used for a certain service class, but as a policy it is useful that they be applied consistently across the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.tx t To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-diffserv-basic-classes-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-baker-diffserv-basic-classes-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C4BB5E.0697962D Content-Type: text/html Content-Transfer-Encoding: quoted-printable New version of draft-baker-diffserv-basic-classes-04.txt

The 04 version of the draft has all the reviewers = comments addressed.

Regards, Joe.
Jozef Babiarz
email: babiarz@nortelnetworks.com
*************************************
A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Configuration Guidelines for DiffServ Service Classes
        Author(s)       : F. Baker, et = al.
        Filename        : = draft-baker-diffserv-basic-classes-04.txt
        Pages           : = 56
        Date    =         : 2004-10-25
       =20
This paper summarizes the recommended correlation = between service
   classes and their usage, with = references to their corresponding
   recommended Differentiated Service Code = Points (DSCP), traffic
   conditioners, Per-Hop Behaviors (PHB) = and Active Queue Management
   (AQM) mechanisms. There is no intrinsic = requirement that particular
   DSCPs, traffic conditioner PHBs and AQM = be used for a certain service
   class, but as a policy it is useful = that they be applied consistently
   across the network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baker-diffse= rv-basic-classes-04.txt

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


Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-baker-diffserv-basic-classes-04.txt".

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


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

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

  ------_=_NextPart_001_01C4BB5E.0697962D-- ------_=_NextPart_000_01C4BB5E.0697962D Content-Type: application/octet-stream; name="ATT1468871.TXT" Content-Disposition: attachment; filename="ATT1468871.TXT" Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25161820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-baker-diffserv-basic-classes-04.txt ------_=_NextPart_000_01C4BB5E.0697962D Content-Type: message/external-body; site="internet-drafts"; dir="draft-baker-diffserv-basic-classes-04.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_000_01C4BB5E.0697962D Content-Type: text/plain; name="ATT1468872.txt" Content-Disposition: attachment; filename="ATT1468872.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C4BB5E.0697962D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------_=_NextPart_000_01C4BB5E.0697962D-- From tsvwg-bounces@ietf.org Tue Oct 26 10:34:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09883; Tue, 26 Oct 2004 10:34:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMScp-0004Ec-Fe; Tue, 26 Oct 2004 10:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSNQ-0001Rl-FB; Tue, 26 Oct 2004 10:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSME-00014u-Q6 for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 10:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09681 for ; Tue, 26 Oct 2004 10:31:28 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSZi-0004AS-76 for tsvwg@ietf.org; Tue, 26 Oct 2004 10:45:39 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9QEVFR2029782 for ; Tue, 26 Oct 2004 16:31:15 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 16:31:15 +0200 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQ1WB7T; Tue, 26 Oct 2004 16:31:15 +0200 Received: from [164.48.140.123] (dhcp4-123.eed.ericsson.se [164.48.140.123]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id QAA06525 for ; Tue, 26 Oct 2004 16:31:14 +0200 (MET DST) Message-ID: <417E5FB3.8040905@ericsson.com> Date: Tue, 26 Oct 2004 16:31:15 +0200 X-Sybari-Trust: d69e070b ad48f3dd 35d21225 00000179 From: Stephan Baucke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> <417E1478.8060609@ericsson.com> <417E3024.2090603@stewart.chicago.il.us> In-Reply-To: <417E3024.2090603@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2004 14:31:15.0938 (UTC) FILETIME=[73585C20:01C4BB68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Randall, this is fine with me. As the problem description, I propose something like the following: The description of Karn's algorithm in RFC 2960 only states that retransmitted packets must not be used for RTT measurements. But an RTT measurement should also not be made if other packets with lower TSNs are retransmitted while a packet is being timed. Otherwise an acknowledgement resulting from such a retransmission can be mistaken for the acknowledgement of the packet being timed (if it advances the cumulative ACK point to the TSN of that packet). This results in an incorrect RTT measurement. Stephan. Randall Stewart wrote: > Stephan: > > IMO this is something that should be ADDED to the > text as an implementation note: > > aka: > > IMPLEMENTATION NOTE: RTT measurements should only be made using a packet > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. > > > Does that sound agreeable to everyone... note the original > text in the MUST clause will remain.. > > R > > > > > > > Stephan Baucke wrote: >> Armando L. Caro, Jr. wrote: >> >> >>>>What damage might occur to the network otherwise that justifies using >>>>MUST here? What interoperability problems would occur? >>>> >>>>Too high an RTT estimate doesn't look like a problem to anybody but >>>>the sender, and appears to be more of a local performance consideration >>>>to me... >>>> >>>>It might warrant an implementation note, but a "MUST" level requirement >>>>would need to be justified. >>> >>>Well the wording that Stephan provided is just a modification of the >>>current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST" >>>level requirement. >> >> >> I'd say it depends on whether the new text will be put into the >> imp-guide as a _replacement_ for the 2960 text, or as an addendum. In >> the first case we will have to keep the MUST, since failure to comply >> with the part of the rule already in 2960 may (as Brian correctly >> pointed out) harm the network. If it is meant as an addendum containing >> just the clarification about retransmitted packets with a smaller TSNs, >> I guess a SHOULD would be appropriate. >> >> BR, >> Stephan. >> >> _______________________________________________ >> tsvwg mailing list >> tsvwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/tsvwg >> >> > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Tue Oct 26 13:15:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24914; Tue, 26 Oct 2004 13:15:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMV8g-0008AS-6O; Tue, 26 Oct 2004 13:29:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUqB-0003T5-Kz; Tue, 26 Oct 2004 13:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUbv-0007Tb-MC for tsvwg@megatron.ietf.org; Tue, 26 Oct 2004 12:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22306 for ; Tue, 26 Oct 2004 12:55:48 -0400 (EDT) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUpT-0007NV-4o for tsvwg@ietf.org; Tue, 26 Oct 2004 13:10:01 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3B60E32DA4; Tue, 26 Oct 2004 12:48:03 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 2771A32DA1; Tue, 26 Oct 2004 12:48:01 -0400 (EDT) Date: Tue, 26 Oct 2004 12:48:01 -0400 (EDT) From: "Armando L. Caro, Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: Randall Stewart Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt In-Reply-To: <417E3024.2090603@stewart.chicago.il.us> Message-ID: References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> <20041025040027.A16702@openss7.org> <417E1478.8060609@ericsson.com> <417E3024.2090603@stewart.chicago.il.us> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.5 required=4.1 tests=BAYES_00 autolearn=ham version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Yes, it looks good to me. ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 On Tue, 26 Oct 2004, Randall Stewart wrote: > Stephan: > > IMO this is something that should be ADDED to the > text as an implementation note: > > aka: > > IMPLEMENTATION NOTE: RTT measurements should only be made using a packet > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. > > > Does that sound agreeable to everyone... note the original > text in the MUST clause will remain.. > > R > > > > > > > Stephan Baucke wrote: > > Armando L. Caro, Jr. wrote: > > > > > >>>What damage might occur to the network otherwise that justifies using > >>>MUST here? What interoperability problems would occur? > >>> > >>>Too high an RTT estimate doesn't look like a problem to anybody but > >>>the sender, and appears to be more of a local performance consideration > >>>to me... > >>> > >>>It might warrant an implementation note, but a "MUST" level requirement > >>>would need to be justified. > >> > >>Well the wording that Stephan provided is just a modification of the > >>current wording in RFC2960's Section 6.3.1.C5, which already uses a "MUST" > >>level requirement. > > > > > > I'd say it depends on whether the new text will be put into the > > imp-guide as a _replacement_ for the 2960 text, or as an addendum. In > > the first case we will have to keep the MUST, since failure to comply > > with the part of the rule already in 2960 may (as Brian correctly > > pointed out) harm the network. If it is meant as an addendum containing > > just the clarification about retransmitted packets with a smaller TSNs, > > I guess a SHOULD would be appropriate. > > > > BR, > > Stephan. > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall Stewart > 803-345-0369 815-342-5222(cell) > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 28 10:36:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18275; Thu, 28 Oct 2004 10:36:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBcW-0002eD-B7; Thu, 28 Oct 2004 10:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBHj-0004uV-0F; Thu, 28 Oct 2004 10:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBGq-0004cL-Ci for tsvwg@megatron.ietf.org; Thu, 28 Oct 2004 10:28:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17278 for ; Thu, 28 Oct 2004 10:28:54 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBUu-0002Sh-0T for tsvwg@ietf.org; Thu, 28 Oct 2004 10:43:29 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9SESFo08090; Thu, 28 Oct 2004 10:28:15 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Oct 2004 10:28:15 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646501DE0828@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: tsvwg@ietf.org, black_david@emc.com Subject: RE: [Tsvwg] Answers to Review of Diffserv Basic Classes Draft Date: Thu, 28 Oct 2004 10:28:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 813368b10167e7c87c318e91999bcea9 Cc: "Jozef Babiarz \(babiarz@nortelnetworks.com\)" , Kwok-Ho Chan , fred@cisco.com, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749975075==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bf50494b99065e6ffd61702a66bcf2c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0749975075== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BCFA.57E03B68" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BCFA.57E03B68 Content-Type: text/plain I'm resending this email as not everyone has received it when I sent it out on Oct. 24. Sorry if you get it twice. Regards, Joe. ************************************************************** Please see below answers to David L. Black review comments. Also, please see Section 7 "Summary of Changes from Previous Drat" for an outline of all the changes made to draft-baker-diffserv-basic-classes-04.txt. (04 version should be available from the on-line Internet-Drafts directory soon). ********************************************************** Review of draft-baker-diffserv-basic-classes-03.txt Reviewer: David L. Black, EMC Corporation For the IETF Transport Area Working Group (tsvwg) August 5, 2004 ------------------------------------------------- -- Overall comment I had skimmed an earlier version of this draft and liked it. Having read this one in detail, I like it a *lot*. Diffserv has been described as a toolkit for constructing QoS services. This draft is like a set of project plans (or a do-it-yourself book on plumbing, wiring, etc.) that explains how to use the tools to build useful things in a fashion accessible to non-experts. This draft is a long-overdue addition to the set of diffserv documents, and does a nice job of weaving together the important elements of diffserv to show how they can be used together in useful ways. I'd like to be able say that those of us working on diffserv had such a coherent vision in mind from the beginning ... ;-). Most of these comments are details of various sorts. The important comments that affect content are: - Add top down traffic and application classification (Section 2.1). [Joe]Added Section 2.2 "Categorization of User Service Classes" and reworked part of section 2.1 to become Section 2.3 "Service Class Characteristics". - Examples 2 and 3 need work (Section 2.2). [Joe]Expanded old Section 2.2, now became Section 2.4. Section 2.4.1 is Example 1. Section 2.4.2 is detailed Example 2 and Section 2.4.3 is detailed Example 3. - AF usage discussion cleanup [(a), (b), and (c) comments on Sections 4.3, 4.5, 4.7 and 4.8]. [Joe] Implemented changes as discussed. See item 9 in Section 7 "Summary of Changes from Previous Draft" of version 0.4 of draft for details of changes. - Remove implied cap on Best Effort traffic (Section 4.9 - probably a typo/thinko, but an important one). [Joe] Modified sentence so that no cap is implied on bandwidth. - Enrich mapping discussion (Section 5 to the extent not covered by top down classification added to Section 2.1). [Joe]Section 5 was extended and restructured into 4 subsections, 5.1 Mapping for Signaling, 5.2 Mapping for NTP, 5.3 Explanation of Ring Clipping, and 5.4 VPN Service Mapping. -- Section 1.4.1 "with no further guarantees" is at odds with the recommendation in Section 4.9 that some minimum amount of bandwidth be guaranteed to best effort. Some sort of expectation that the network will be usable for best effort traffic (in some sense) is needed here. [Joe] Changed wording to be compatible with section 4.9 "Best Effort needs to provide some minimum bandwidth guarantee ..." -- Section 2.1 Expand OAM acronym on first use. [Joe] Done. OAM "Operations, Administration and Management". Mention of "(traditional telephony)" in description of signaling class is potentially confusing. Need to say that this signaling and control traffic *before* using the T-word. [Joe] Implemented the change. See section 2.2, etc. The network control traffic classes look good. For the user/subscriber classes, more in the way of top-down rough criteria for sorting traffic into classes would be a good addition. Figure 1 is a start, but aspects such as elasticity, burstiness, and whether the traffic is signaled seem to be collapsed into the description. I'm not sure whether another figure with lots of columns would be better. [Joe] Added new section and an additional figure. A couple of things should be added. First of all, a top-down description of how the traffic space is divided up that focuses on the traffic characteristics - in essence more structure in the center column in Figure 1. What I have in mind is almost there, but breaking out things like but elasticity, burstiness, and whether the traffic is signaled would probably help, although a 6+ column table is probably not what's needed. Second, a top down grouping the user/data classes into a smaller number of groups by application protocol type would help - to a first approximation, there are: - 5 media-oriented classes, split into Interactive (Telephony, Multimedia conferencing, RT Interactive) and Streaming (Multimedia, Broadcast Video) subgroups. - Signaling - 3 data classes (Low Latency, High Throughput, Low Priority), with Low Latency being Interactive, High Throughput being close to streaming (but more jitter-tolerant than media, plus TCP-like drop response), and Low Priority being Don't Care to some degree. - Standard (Best Effort) Signaling needs to be distinguished from Low Latency Data, as Signaling traffic *is* low latency data. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the (usually media) streams/sessions they signal and control. [Joe] The above issues/suggestion are addressed in new section 2.2 "Categorization of User Service Classes" and section 2.3 "Service Class Characteristics". In Figure 3, add RFC references for the two 3-color markers. [Joe] Done. Last bullet in Section 2.1 needs to say "one of" the two services can be supported. If Low Priority data is mapped to 000xxx, recommend that xxx not be 000 to allow this to be distinguished from Standard. [Joe] Made the above change and recommend that 000xx1. -- Section 2.2 Editing needed: A network administrator determined that they need There are a number of editing problems elsewhere - I didn't flag all of them. [Joe] Reworked section 2.2 "Figure 4, provides a popular industry view" - What's a "popular industry view"? A different phrase should be used. [Joe] Removed that phrase and replaced it with " Service Provider Network Configuration Example 1". Examples 2 & 3 - where did the numbers "five" and "eight" come from? Describing these networks in terms of traffic carried/services provided and the resulting differentiation goals would be better than picking numbers out of thin air. In general, these examples are short on detail/explanation. [Joe] These two examples have been expanded with service descriptions, etc. in section 2.4.2 Example 2 and 2.4.3 Example 3. -- Section 3.2 In the past, I think routing has divided interior vs. exterior routing protocol traffic into CS7 vs. CS6. One of the implications of this draft appears to be that this approach is no longer recommended, [ ... snipped due to UPDATE ...] UPDATE: I'm informed by people who know better than I that routing does not use CS7, so it suffices to add routing to the list of traffic that is not appropriate for the Administrative Service class. [Joe] Left it as was. Say how to distinguish Network Control signaling flows from user/subscriber signaling (this is not as easy as it looks, as it may depend on who owns the softswitch). [Joe] Addressed in Section 2.2, and 5.1. -- Section 4.1 IP Telephony "MUST" use Telephony service class is at odds with the "SHOULD" for the list of protocols - either explain that the listed protocols can be used for services other than IP Telephony, or downgrade the "MUST" to a "SHOULD". [Joe] Change it to SHOULD. o Packet flows from trusted sources (media gateways inside administered network) MAY not require policing. Can't say "MAY not", and that's also not quite right. Try "Policing is OPTIONAL for traffic from trusted sources whose behavior is assured via other means (e.g., administrative controls on those systems)." The text in the immediately following bullet has a better structure. [Joe] Changed it to state that policing is OPTIONAL. -- Section 4.2 Explain "clipping". In essence, if the signaling protocol that sets up the connection fails to complete in the expected time, the result is audio loss/degradation at the start of the session, which is particularly noticeable when dealing with unforgiving POTS systems. [Joe] Added Section 5.3 "Explanation of Ring Clipping". How is "peer to peer real time control function" distinguished from low latency data? Data vs. control is fuzzy at best, so some discussion of what is controlled and/or the importance of the control function would help. [Joe] Addressed in several sections 2.2, 2.3 and 5.1. -- Section 4.3 In first paragraph, expand "Video conferencing" example to "Audio and video conferencing". [Joe] Done. (a) If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point MUST perform Multifield (MF) Classification as defined in [RFC2475] and mark all packets as AF41. That's peculiar - it looks like it assumes the end-point stays inside the rate "A" profile/envelope, unless I missed something. Was AF4x intended instead of AF41? [Joe] Changed it to AF4x. (b) Just to complicate things - running trTCM in Color-Aware mode assumes that "A" and "B" don't change across domain boundaries. If they do, Color-Blind may be necessary if the trTCM rates or burst sizes increase significantly in the direction of flow (else get too much red & yellow traffic, by comparison to traffic coming in on interfaces with trTCM running Color-Blind). [Joe] Made changes to Conditioning Performed at DiffServ Network Edge sections to: o If packets are marked by a trusted sources or previous trusted DiffServ domain, and the color marking is to be preserved, then the two rate three color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two rate three color marker SHOULD be configured to operate in Color-Blind mode. (c) Should say something about use or non-use of marking to distinguish application-defined content layers in a single [media] stream (e.g., complete frames vs. delta frames, additional data for higher resolution). IMHO, history reveals this example to be an attractive nuisance (intellectually appealing, but unworkable in practice due to dynamic variation in codec output rates) and hence ought to carry a "SHOULD NOT" recommendation to disfavor it by comparison to the straight application-level-unaware rate-metering described here. [Joe] Deleted statement (last sentence in the first paragraph of section 4.3) that: "In the future, it is expected that these services will generate continuously variable rate traffic with packet marking indicating flow importance." No discussion was added to draft on "complete frames vs. delta frames", etc. metering/conditioning scenarios as this draft only addresses application-level-unaware rate metering. -- Section 4.5 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF3* for any AF4* occurrences in those comments). [Joe] (a) and (b) changed to as above for AF3*. (c) only stated rate-metering. -- Section 4.7 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF2* for any AF4* occurrences in those comments and likewise substitute srTCM for trTCM). [Joe] (a) and (b) changed to as above for AF2*. (c) only stated rate-metering. -- Section 4.8 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF1* for any AF4* occurrences in those comments). [Joe] (a) and (b) changed to as above for AF1*. (c) only stated rate-metering. -- Section 4.9 SHOULD be configured to receive a small percentage of forwarding resources (at least 5%). That can't what was intended, as it places a cap on best effort bandwidth. Remove the cap by doing something like inserting "at least" before "a small percentage" and adding "as a guaranteed minimum" at the end. I suspect this is a typo/thinko/oversight. [Joe] Modified sentence so that no cap is implied on bandwidth. -- Section 5 In general, this section should be enriched/extended, and in particular: - Please add a VPN service mapping discussion. [Joe] Added Section 5.4 on support of service classes in VPNs. - A discussion of mapping media flows (audio and/or video) should go here, unless it's covered by the discussion requested in Section 2.1 [Joe] Addressed in Section 2.2 - Please add a summary of the UMTS traffic class mappings. [Joe] After a closer analysis, we determined that further work is needed in this area. We believe that the interworking between DiffServ service classes and UMTS Traffic Classes should be addressed in a separate document. Therefore, we removed from this draft any suggested mapping of DSCP values and DiffServ service classes into UMTS Traffic Classes. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg Regards, Joe. Jozef Babiarz email: babiarz@nortelnetworks.com ------_=_NextPart_001_01C4BCFA.57E03B68 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Tsvwg] Answers to Review of Diffserv Basic Classes = Draft

I'm resending this email as not everyone has received = it when I sent it out on Oct. 24. Sorry if you get it twice.
Regards, Joe.
************************************************************** =
Please see below answers to David L. Black review = comments.
Also, please see Section 7 "Summary of Changes from = Previous Drat" for an outline of all the changes made to = draft-baker-diffserv-basic-classes-04.txt. (04 version should be = available from the on-line Internet-Drafts directory soon).

**********************************************************
Review of = draft-baker-diffserv-basic-classes-03.txt
Reviewer: David L. Black, EMC Corporation
For the IETF Transport Area Working Group = (tsvwg)
August 5, 2004
-------------------------------------------------

-- Overall comment

I had skimmed an earlier version of this draft and = liked it.  Having read this one in detail, I like it a = *lot*.  Diffserv has been described as a toolkit for constructing = QoS services.  This draft is like a set of project plans (or a = do-it-yourself book on plumbing, wiring,

etc.) that explains how to use the tools to build = useful things in a fashion accessible to non-experts.  This draft = is a long-overdue addition to the set of diffserv documents, and does a = nice job of weaving together the important elements of diffserv to show = how they can be used together in useful ways.  I'd like to be able = say that those of us working on diffserv had such a coherent vision in = mind from the beginning ... ;-).

Most of these comments are details of various = sorts.  The important comments that affect content are:

- Add top down traffic and application classification = (Section 2.1).
[Joe]Added Section 2.2 "Categorization of User = Service Classes" and reworked part of section 2.1 to become Section 2.3 = "Service Class Characteristics".

- Examples 2 and 3 need work (Section 2.2).
[Joe]Expanded old Section 2.2, now became Section = 2.4. Section 2.4.1 is Example 1. Section 2.4.2 is detailed Example 2 = and Section 2.4.3 is detailed Example 3.

- AF usage discussion cleanup [(a), (b), and (c) = comments on Sections
        4.3, 4.5, = 4.7 and 4.8].
[Joe] Implemented changes as discussed. See item 9 = in Section 7 "Summary of Changes from Previous Draft" of version 0.4 of = draft for details of changes.

- Remove implied cap on Best Effort traffic (Section = 4.9 - probably
        a = typo/thinko, but an important one).
[Joe] Modified sentence so that no cap is implied on = bandwidth.

- Enrich mapping discussion (Section 5 to the extent = not covered
        by top = down classification added to Section 2.1).
[Joe]Section 5 was extended and restructured into 4 = subsections, 5.1 Mapping for Signaling, 5.2 Mapping for NTP, 5.3 = Explanation of Ring Clipping, and 5.4 VPN Service Mapping.

-- Section 1.4.1

"with no further guarantees" is at odds = with the recommendation in Section 4.9 that some minimum amount of = bandwidth be guaranteed to best effort.  Some sort of expectation = that the network will be usable for best effort traffic (in some sense) = is needed here.

[Joe] Changed wording to be compatible with section = 4.9 "Best Effort needs to provide some minimum bandwidth guarantee = ..."

--  Section 2.1

Expand OAM acronym on first use.
[Joe] Done. OAM "Operations, Administration and = Management".

Mention of "(traditional telephony)" in = description of signaling class is potentially confusing.  Need to = say that this signaling and control traffic *before* using the = T-word.

[Joe] Implemented the change. See section 2.2, = etc.

The network control traffic classes look good.  = For the user/subscriber classes, more in the way of top-down rough = criteria for sorting traffic into classes would be a good = addition.  Figure 1 is a start, but aspects such as elasticity, = burstiness, and whether the traffic is signaled seem to be collapsed = into the description.  I'm not sure whether another figure with = lots of columns would be better.

[Joe] Added new section and an additional = figure.

A couple of things should be added.  First of = all, a top-down description of how the traffic space is divided up that = focuses on the traffic characteristics - in essence more structure in = the center column in Figure 1.  What I have in mind is almost = there, but breaking out things like but elasticity, burstiness, and = whether the traffic is signaled would probably help, although a 6+ = column table is probably not what's needed.

Second, a top down grouping the user/data classes = into a smaller number of groups by application protocol type would help = - to a first approximation, there are:

- 5 media-oriented classes, split into Interactive = (Telephony, Multimedia
        conferencing, RT Interactive) and Streaming (Multimedia, = Broadcast
        Video) = subgroups.      
- Signaling
- 3 data classes (Low Latency, High Throughput, Low = Priority), with
        Low = Latency being Interactive, High Throughput being close to
        streaming = (but more jitter-tolerant than media, plus TCP-like
        drop = response), and Low Priority being Don't Care to some degree.
- Standard (Best Effort)

Signaling needs to be distinguished from Low Latency = Data, as Signaling traffic *is* low latency data.  The essential = distinction is something like "administrative control and = management" of the traffic affected as the protocols in this class = tend to be tied to the (usually media) streams/sessions they signal and = control.

[Joe] The above issues/suggestion are addressed in = new section 2.2 "Categorization of User Service Classes" and section = 2.3 "Service Class Characteristics".

In Figure 3, add RFC references for the two 3-color = markers.
[Joe] Done.

Last bullet in Section 2.1 needs to say "one = of" the two services can be supported.  If Low Priority data = is mapped to 000xxx, recommend that xxx not be 000 to allow this to be = distinguished from Standard.

[Joe] Made the above change and recommend that = 000xx1.

-- Section 2.2

Editing needed: A network administrator determined = that they need
        There are = a number of editing problems elsewhere - I didn't
        flag all = of them.
[Joe] Reworked section 2.2

"Figure 4, provides a popular industry = view" - What's a "popular
        industry = view"?  A different phrase should be used.
[Joe] Removed that phrase and replaced it with " = Service Provider Network Configuration Example 1".


Examples 2 & 3 - where did the numbers = "five" and "eight" come from?
        Describing these networks in terms of traffic = carried/services
        provided = and the resulting differentiation goals would be
        better = than picking numbers out of thin air.  In general,
        these = examples are short on detail/explanation.
[Joe] These two examples have been expanded with = service descriptions, etc. in section 2.4.2 Example 2 and 2.4.3 Example = 3.

-- Section 3.2

In the past, I think routing has divided interior vs. = exterior routing protocol traffic into CS7 vs. CS6.  One of the = implications of this draft appears to be that this approach is no = longer recommended,

        [ ... = snipped due to UPDATE ...]
UPDATE: I'm informed by people who know better than = I that routing does not use CS7, so it suffices to add routing to the = list of traffic that is not appropriate for the Administrative Service = class.

[Joe] Left it as was.

Say how to distinguish Network Control signaling = flows from user/subscriber signaling (this is not as easy as it looks, = as it may depend on who owns the softswitch).

[Joe] Addressed in Section 2.2, and 5.1.

-- Section 4.1

IP Telephony "MUST" use Telephony service = class is at odds with the "SHOULD" for the list of protocols = - either explain that the listed protocols can be used for services = other than IP Telephony, or downgrade the "MUST" to a = "SHOULD".

[Joe] Change it to SHOULD.

   o  Packet flows from trusted = sources (media gateways inside
      administered network) = MAY not require policing.

Can't say "MAY not", and that's also not = quite right.  Try "Policing is OPTIONAL for traffic from = trusted sources whose behavior is assured via other means (e.g., = administrative controls on those systems)." The text in the = immediately following bullet has a better structure.

[Joe] Changed it to state that policing is = OPTIONAL.

-- Section 4.2

Explain "clipping".  In essence, if = the signaling protocol that sets up the connection fails to complete in = the expected time, the result is audio loss/degradation at the start of = the session, which is particularly noticeable when dealing with = unforgiving POTS systems.

[Joe] Added Section 5.3 "Explanation of Ring = Clipping".


How is "peer to peer real time control = function" distinguished from low latency data?  Data vs. = control is fuzzy at best, so some discussion of what is controlled = and/or the importance of the control function would help.

[Joe] Addressed in several sections 2.2, 2.3 and = 5.1.

-- Section 4.3

In first paragraph, expand "Video = conferencing" example to "Audio and video = conferencing".
[Joe] Done.

(a) If the end point is not capable of setting
   the DSCP value, then the router = topologically closest to the end
   point MUST perform Multifield (MF) = Classification as defined in
   [RFC2475] and mark all packets as = AF41.

That's peculiar - it looks like it assumes the = end-point stays inside the rate "A" profile/envelope, unless = I missed something.  Was AF4x intended instead of AF41?

[Joe] Changed it to AF4x.

(b) Just to complicate things - running trTCM in = Color-Aware mode assumes that "A" and "B" don't = change across domain boundaries.  If they do, Color-Blind may be = necessary if the trTCM rates or burst sizes increase significantly in = the direction of flow (else get too much red & yellow traffic, by = comparison to traffic coming in on interfaces with trTCM running = Color-Blind).

[Joe] Made changes to Conditioning Performed at = DiffServ Network Edge sections to:
o  If packets are marked by a trusted sources = or previous trusted DiffServ domain, and the color marking is to be = preserved, then the two rate three color marker SHOULD be configured to = operate in Color-Aware mode.

o  If the packet marking is not trusted or the = color marking is not to be preserved, then the two rate three color = marker SHOULD be configured to operate in Color-Blind mode.

(c) Should say something about use or non-use of = marking to distinguish application-defined content layers in a single = [media] stream (e.g., complete frames vs. delta frames, additional data = for higher resolution). IMHO, history reveals this example to be an = attractive nuisance

(intellectually appealing, but unworkable in practice = due to dynamic variation in codec output rates) and hence ought to = carry a "SHOULD NOT" recommendation to disfavor it by = comparison to the straight application-level-unaware rate-metering = described here.

[Joe] Deleted statement (last sentence in the first = paragraph of section 4.3) that: "In the future, it is expected = that these services will generate continuously variable rate traffic = with packet marking indicating flow importance." No discussion was = added to draft on "complete frames vs. delta frames", etc. = metering/conditioning scenarios as this draft only addresses = application-level-unaware rate metering.


-- Section 4.5

Section 4.3 comments (a), (b), and (c) apply here = (but substitute AF3* for any AF4* occurrences in those = comments).
[Joe] (a) and (b) changed to as above for AF3*. (c) = only stated rate-metering.

-- Section 4.7

Section 4.3 comments (a), (b), and (c) apply here = (but substitute AF2* for any AF4* occurrences in those comments and = likewise substitute srTCM for trTCM).

[Joe] (a) and (b) changed to as above for AF2*. (c) = only stated rate-metering.

-- Section 4.8

Section 4.3 comments (a), (b), and (c) apply here = (but substitute AF1* for any AF4* occurrences in those = comments).
[Joe] (a) and (b) changed to as above for AF1*. (c) = only stated rate-metering.

-- Section 4.9

   SHOULD be configured to receive a = small
   percentage of forwarding resources (at = least 5%).

That can't what was intended, as it places a cap on = best effort bandwidth.  Remove the cap by doing something like = inserting "at least" before "a small percentage" = and adding "as a guaranteed minimum" at the end.  I = suspect this is a typo/thinko/oversight.

[Joe] Modified sentence so that no cap is implied on = bandwidth.

-- Section 5

In general, this section should be enriched/extended, = and in particular:
- Please add a VPN service mapping = discussion.
[Joe] Added Section 5.4 on support of service = classes in VPNs.

- A discussion of mapping media flows (audio and/or = video) should go
    here, unless it's covered by the = discussion requested in Section 2.1
[Joe] Addressed in Section 2.2
- Please add a summary of the UMTS traffic class = mappings.
[Joe] After a closer analysis, we determined that = further work is needed in this area. We believe that the interworking = between DiffServ service classes and UMTS Traffic Classes should be = addressed in a separate document. Therefore, we removed from this draft = any suggested mapping of DSCP values and DiffServ service classes into = UMTS Traffic Classes.


----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748
+1 (508) = 293-7953          &nbs= p;  FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1 (978) 394-7754
----------------------------------------------------

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


Regards, Joe.
Jozef Babiarz
email: babiarz@nortelnetworks.com

------_=_NextPart_001_01C4BCFA.57E03B68-- --===============0749975075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0749975075==-- From tsvwg-bounces@ietf.org Thu Oct 28 23:15:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01824; Thu, 28 Oct 2004 23:15:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNSc-0002PY-OX; Thu, 28 Oct 2004 23:29:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMnP-0004bx-VJ; Thu, 28 Oct 2004 22:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLs9j-00046v-W6 for tsvwg@megatron.ietf.org; Sun, 24 Oct 2004 19:52:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11174 for ; Sun, 24 Oct 2004 19:52:08 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLsN4-00084v-2e for tsvwg@ietf.org; Sun, 24 Oct 2004 20:05:59 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9ONpYF29192; Sun, 24 Oct 2004 19:51:34 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Oct 2004 19:51:34 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646501CC02D3@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: tsvwg@ietf.org, black_david@emc.com Subject: RE: [Tsvwg] Answers to Review of Diffserv Basic Classes Draft Date: Sun, 24 Oct 2004 19:51:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.9 (/) X-Scan-Signature: f1e116c42859d8542c08251690b5b182 X-Mailman-Approved-At: Thu, 28 Oct 2004 22:47:16 -0400 Cc: "Jozef Babiarz \(babiarz@nortelnetworks.com\)" , Kwok-Ho Chan , fred@cisco.com, jon.peterson@neustar.biz, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565726411==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 88e8087d1b20b7fe0211e68acd23c714 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0565726411== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA24.600D271A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BA24.600D271A Content-Type: text/plain Please see below answers to David L. Black review comments. Also, please see Section 7 "Summary of Changes from Previous Drat" for an outline of all the changes made to draft-baker-diffserv-basic-classes-04.txt. (04 version should be available from the on-line Internet-Drafts directory soon). ********************************************************** Review of draft-baker-diffserv-basic-classes-03.txt Reviewer: David L. Black, EMC Corporation For the IETF Transport Area Working Group (tsvwg) August 5, 2004 ------------------------------------------------- -- Overall comment I had skimmed an earlier version of this draft and liked it. Having read this one in detail, I like it a *lot*. Diffserv has been described as a toolkit for constructing QoS services. This draft is like a set of project plans (or a do-it-yourself book on plumbing, wiring, etc.) that explains how to use the tools to build useful things in a fashion accessible to non-experts. This draft is a long-overdue addition to the set of diffserv documents, and does a nice job of weaving together the important elements of diffserv to show how they can be used together in useful ways. I'd like to be able say that those of us working on diffserv had such a coherent vision in mind from the beginning ... ;-). Most of these comments are details of various sorts. The important comments that affect content are: - Add top down traffic and application classification (Section 2.1). [Joe]Added Section 2.2 "Categorization of User Service Classes" and reworked part of section 2.1 to become Section 2.3 "Service Class Characteristics". - Examples 2 and 3 need work (Section 2.2). [Joe]Expanded old Section 2.2, now became Section 2.4. Section 2.4.1 is Example 1. Section 2.4.2 is detailed Example 2 and Section 2.4.3 is detailed Example 3. - AF usage discussion cleanup [(a), (b), and (c) comments on Sections 4.3, 4.5, 4.7 and 4.8]. [Joe] Implemented changes as discussed. See item 9 in Section 7 "Summary of Changes from Previous Draft" of version 0.4 of draft for details of changes. - Remove implied cap on Best Effort traffic (Section 4.9 - probably a typo/thinko, but an important one). [Joe] Modified sentence so that no cap is implied on bandwidth. - Enrich mapping discussion (Section 5 to the extent not covered by top down classification added to Section 2.1). [Joe]Section 5 was extended and restructured into 4 subsections, 5.1 Mapping for Signaling, 5.2 Mapping for NTP, 5.3 Explanation of Ring Clipping, and 5.4 VPN Service Mapping. -- Section 1.4.1 "with no further guarantees" is at odds with the recommendation in Section 4.9 that some minimum amount of bandwidth be guaranteed to best effort. Some sort of expectation that the network will be usable for best effort traffic (in some sense) is needed here. [Joe] Changed wording to be compatible with section 4.9 "Best Effort needs to provide some minimum bandwidth guarantee ..." -- Section 2.1 Expand OAM acronym on first use. [Joe] Done. OAM "Operations, Administration and Management". Mention of "(traditional telephony)" in description of signaling class is potentially confusing. Need to say that this signaling and control traffic *before* using the T-word. [Joe] Implemented the change. See section 2.2, etc. The network control traffic classes look good. For the user/subscriber classes, more in the way of top-down rough criteria for sorting traffic into classes would be a good addition. Figure 1 is a start, but aspects such as elasticity, burstiness, and whether the traffic is signaled seem to be collapsed into the description. I'm not sure whether another figure with lots of columns would be better. [Joe] Added new section and an additional figure. A couple of things should be added. First of all, a top-down description of how the traffic space is divided up that focuses on the traffic characteristics - in essence more structure in the center column in Figure 1. What I have in mind is almost there, but breaking out things like but elasticity, burstiness, and whether the traffic is signaled would probably help, although a 6+ column table is probably not what's needed. Second, a top down grouping the user/data classes into a smaller number of groups by application protocol type would help - to a first approximation, there are: - 5 media-oriented classes, split into Interactive (Telephony, Multimedia conferencing, RT Interactive) and Streaming (Multimedia, Broadcast Video) subgroups. - Signaling - 3 data classes (Low Latency, High Throughput, Low Priority), with Low Latency being Interactive, High Throughput being close to streaming (but more jitter-tolerant than media, plus TCP-like drop response), and Low Priority being Don't Care to some degree. - Standard (Best Effort) Signaling needs to be distinguished from Low Latency Data, as Signaling traffic *is* low latency data. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the (usually media) streams/sessions they signal and control. [Joe] The above issues/suggestion are addressed in new section 2.2 "Categorization of User Service Classes" and section 2.3 "Service Class Characteristics". In Figure 3, add RFC references for the two 3-color markers. [Joe] Done. Last bullet in Section 2.1 needs to say "one of" the two services can be supported. If Low Priority data is mapped to 000xxx, recommend that xxx not be 000 to allow this to be distinguished from Standard. [Joe] Made the above change and recommend that 000xx1. -- Section 2.2 Editing needed: A network administrator determined that they need There are a number of editing problems elsewhere - I didn't flag all of them. [Joe] Reworked section 2.2 "Figure 4, provides a popular industry view" - What's a "popular industry view"? A different phrase should be used. [Joe] Removed that phrase and replaced it with " Service Provider Network Configuration Example 1". Examples 2 & 3 - where did the numbers "five" and "eight" come from? Describing these networks in terms of traffic carried/services provided and the resulting differentiation goals would be better than picking numbers out of thin air. In general, these examples are short on detail/explanation. [Joe] These two examples have been expanded with service descriptions, etc. in section 2.4.2 Example 2 and 2.4.3 Example 3. -- Section 3.2 In the past, I think routing has divided interior vs. exterior routing protocol traffic into CS7 vs. CS6. One of the implications of this draft appears to be that this approach is no longer recommended, [ ... snipped due to UPDATE ...] UPDATE: I'm informed by people who know better than I that routing does not use CS7, so it suffices to add routing to the list of traffic that is not appropriate for the Administrative Service class. [Joe] Left it as was. Say how to distinguish Network Control signaling flows from user/subscriber signaling (this is not as easy as it looks, as it may depend on who owns the softswitch). [Joe] Addressed in Section 2.2, and 5.1. -- Section 4.1 IP Telephony "MUST" use Telephony service class is at odds with the "SHOULD" for the list of protocols - either explain that the listed protocols can be used for services other than IP Telephony, or downgrade the "MUST" to a "SHOULD". [Joe] Change it to SHOULD. o Packet flows from trusted sources (media gateways inside administered network) MAY not require policing. Can't say "MAY not", and that's also not quite right. Try "Policing is OPTIONAL for traffic from trusted sources whose behavior is assured via other means (e.g., administrative controls on those systems)." The text in the immediately following bullet has a better structure. [Joe] Changed it to state that policing is OPTIONAL. -- Section 4.2 Explain "clipping". In essence, if the signaling protocol that sets up the connection fails to complete in the expected time, the result is audio loss/degradation at the start of the session, which is particularly noticeable when dealing with unforgiving POTS systems. [Joe] Added Section 5.3 "Explanation of Ring Clipping". How is "peer to peer real time control function" distinguished from low latency data? Data vs. control is fuzzy at best, so some discussion of what is controlled and/or the importance of the control function would help. [Joe] Addressed in several sections 2.2, 2.3 and 5.1. -- Section 4.3 In first paragraph, expand "Video conferencing" example to "Audio and video conferencing". [Joe] Done. (a) If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point MUST perform Multifield (MF) Classification as defined in [RFC2475] and mark all packets as AF41. That's peculiar - it looks like it assumes the end-point stays inside the rate "A" profile/envelope, unless I missed something. Was AF4x intended instead of AF41? [Joe] Changed it to AF4x. (b) Just to complicate things - running trTCM in Color-Aware mode assumes that "A" and "B" don't change across domain boundaries. If they do, Color-Blind may be necessary if the trTCM rates or burst sizes increase significantly in the direction of flow (else get too much red & yellow traffic, by comparison to traffic coming in on interfaces with trTCM running Color-Blind). [Joe] Made changes to Conditioning Performed at DiffServ Network Edge sections to: o If packets are marked by a trusted sources or previous trusted DiffServ domain, and the color marking is to be preserved, then the two rate three color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two rate three color marker SHOULD be configured to operate in Color-Blind mode. (c) Should say something about use or non-use of marking to distinguish application-defined content layers in a single [media] stream (e.g., complete frames vs. delta frames, additional data for higher resolution). IMHO, history reveals this example to be an attractive nuisance (intellectually appealing, but unworkable in practice due to dynamic variation in codec output rates) and hence ought to carry a "SHOULD NOT" recommendation to disfavor it by comparison to the straight application-level-unaware rate-metering described here. [Joe] Deleted statement (last sentence in the first paragraph of section 4.3) that: "In the future, it is expected that these services will generate continuously variable rate traffic with packet marking indicating flow importance." No discussion was added to draft on "complete frames vs. delta frames", etc. metering/conditioning scenarios as this draft only addresses application-level-unaware rate metering. -- Section 4.5 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF3* for any AF4* occurrences in those comments). [Joe] (a) and (b) changed to as above for AF3*. (c) only stated rate-metering. -- Section 4.7 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF2* for any AF4* occurrences in those comments and likewise substitute srTCM for trTCM). [Joe] (a) and (b) changed to as above for AF2*. (c) only stated rate-metering. -- Section 4.8 Section 4.3 comments (a), (b), and (c) apply here (but substitute AF1* for any AF4* occurrences in those comments). [Joe] (a) and (b) changed to as above for AF1*. (c) only stated rate-metering. -- Section 4.9 SHOULD be configured to receive a small percentage of forwarding resources (at least 5%). That can't what was intended, as it places a cap on best effort bandwidth. Remove the cap by doing something like inserting "at least" before "a small percentage" and adding "as a guaranteed minimum" at the end. I suspect this is a typo/thinko/oversight. [Joe] Modified sentence so that no cap is implied on bandwidth. -- Section 5 In general, this section should be enriched/extended, and in particular: - Please add a VPN service mapping discussion. [Joe] Added Section 5.4 on support of service classes in VPNs. - A discussion of mapping media flows (audio and/or video) should go here, unless it's covered by the discussion requested in Section 2.1 [Joe] Addressed in Section 2.2 - Please add a summary of the UMTS traffic class mappings. [Joe] After a closer analysis, we determined that further work is needed in this area. We believe that the interworking between DiffServ service classes and UMTS Traffic Classes should be addressed in a separate document. Therefore, we removed from this draft any suggested mapping of DSCP values and DiffServ service classes into UMTS Traffic Classes. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg Regards, Joe. Jozef Babiarz email: babiarz@nortelnetworks.com ------_=_NextPart_001_01C4BA24.600D271A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Tsvwg] Answers to Review of Diffserv Basic Classes = Draft

      Please see below = answers to David L. Black review comments.

      Also, please see = Section 7 "Summary of Changes from Previous Drat" for an outline of all = the changes made to draft-baker-diffserv-basic-classes-04.txt. (04 = version should be available = from the on-line Internet-Drafts directory soon).

      **********************************************************

      Review of = draft-baker-diffserv-basic-classes-03.txt

      Reviewer: David L. = Black, EMC Corporation

      For the IETF = Transport Area Working Group (tsvwg)

      August 5, 2004

      -------------------------------------------------

      -- Overall = comment

      I had skimmed an = earlier version of this draft and liked it.  Having read this one = in detail, I like it a *lot*.  Diffserv has been described as a = toolkit for constructing QoS = services.  This draft is like a set of project plans (or a = do-it-yourself book on plumbing, wiring,

      etc.) that explains = how to use the tools to build useful things in a fashion accessible to = non-experts.  This draft is a long-overdue addition to the = set of diffserv documents, = and does a nice job of weaving together the important elements of = diffserv to show how they can be used together in useful ways.  = I'd like to be able say that those of us working on diffserv had such a = coherent vision in mind from the beginning ... = ;-).

      Most of these = comments are details of various sorts.  The important comments = that affect content are:

      - Add top down = traffic and application classification (Section 2.1).

      [Joe]Added Section = 2.2 "Categorization of User = Service Classes" and = reworked part of section 2.1 to become Section 2.3 "Service Class = Characteristics".

      - Examples 2 and 3 = need work (Section 2.2).

      [Joe]Expanded old = Section 2.2, now became Section 2.4. Section 2.4.1 is Example = 1. Section 2.4.2 is detailed = Example 2 and Section 2.4.3 is detailed Example 3.

      - AF usage = discussion cleanup [(a), (b), and (c) comments on Sections

              4.3, 4.5, 4.7 and 4.8].

      [Joe] Implemented = changes as discussed. See item 9 in Section 7 "Summary of Changes from Previous Draft" of version = 0.4 of draft for details of changes.

      - Remove implied = cap on Best Effort traffic (Section 4.9 - probably

              a typo/thinko, but an important = one).

      [Joe] Modified sentence so that no cap is implied on bandwidth.

      - Enrich = mapping discussion (Section = 5 to the extent not covered

              by top down classification added to = Section 2.1).

      [Joe]Section 5 was = extended and restructured into 4 subsections, 5.1 Mapping for Signaling, 5.2 Mapping for NTP, = 5.3 Explanation of Ring = Clipping, and 5.4 = VPN Service Mapping.

      -- Section = 1.4.1

      "with no = further guarantees" is at odds with the recommendation in Section = 4.9 that some minimum amount of bandwidth be guaranteed to best = effort.  Some sort of expectation that the network will be usable = for best effort traffic (in = some sense) is needed here.

      [Joe] Changed wording to be compatible with = section 4.9 "Best Effort needs to provide some = minimum bandwidth guarantee ..."

      --  Section = 2.1

      Expand OAM acronym = on first use.

      [Joe] Done. OAM = "Operations, Administration = and Management".

      Mention of = "(traditional telephony)" in description of signaling class = is potentially confusing.  Need to say that this signaling and = control traffic *before* using the T-word.

      [Joe] Implemented = the change. See section 2.2, etc.

      The network control = traffic classes look good.  For the user/subscriber classes, more = in the way of top-down rough criteria for sorting traffic into classes = would be a good addition.  Figure 1 is a start, but aspects such as elasticity, = burstiness, and whether the traffic is signaled seem to be collapsed = into the description.  I'm not sure whether another figure with = lots of columns would be better.

      [Joe] Added new = section and an additional figure.

      A couple of things should be added.  = First of all, a top-down description of how the traffic space is = divided up that focuses on the traffic characteristics - in essence = more structure in the center column in Figure 1.  What I have in = mind is almost there, but breaking out things = like but elasticity, burstiness, and whether the traffic is signaled = would probably help, although a 6+ column table is probably not what's = needed.

      Second, a top down = grouping the user/data classes into a smaller number of groups by = application protocol type = would help - to a first approximation, there are:

      - 5 media-oriented = classes, split into Interactive (Telephony, Multimedia

              conferencing, RT Interactive) and = Streaming (Multimedia, Broadcast

              Video) = subgroups.      

      - = Signaling

      - 3 = data classes (Low Latency, = High Throughput, Low Priority), with

              Low Latency being Interactive, High = Throughput being close to

              streaming (but more jitter-tolerant than = media, plus TCP-like

              drop response), and Low Priority being = Don't Care to some degree.

      - Standard (Best Effort)

      Signaling needs to = be distinguished from Low Latency Data, as Signaling traffic *is* low = latency data.  The essential distinction is something like = "administrative control and management" of the traffic = affected as the protocols in this class tend to be tied to the (usually media) streams/sessions = they signal and control.

      [Joe] The above = issues/suggestion are addressed in new section 2.2 "Categorization of User Service = Classes" and section 2.3 = "Service Class = Characteristics".

      In Figure 3, add RFC references for the two = 3-color markers.

      [Joe] = Done.

      Last bullet in = Section 2.1 needs to say "one of" the two services can be = supported.  If Low Priority data is mapped to 000xxx, recommend = that xxx not be 000 to allow this to be distinguished from Standard.

      [Joe] Made the = above change and recommend that 000xx1.

      -- Section = 2.2

      Editing needed: A = network administrator determined that they need

              There are a number of editing problems = elsewhere - I didn't

              flag all of them.

      [Joe] Reworked = section 2.2

      "Figure 4, = provides a popular industry view" - What's a = "popular

              industry view"?  A different = phrase should be used.

      [Joe] Removed that = phrase and replaced it with " Service Provider = Network Configuration Example 1".


      Examples 2 & 3 - = where did the numbers "five" and "eight" come = from?

              Describing these networks in terms of = traffic carried/services

              provided and the resulting = differentiation goals would be

              better than picking numbers out of thin = air.  In general,

              these examples are short on detail/explanation.

      [Joe] These two = examples have been expanded with service descriptions, etc. in section = 2.4.2 Example 2 and 2.4.3 Example 3.

      -- Section = 3.2

      In the past, I = think routing has divided interior vs. exterior routing = protocol traffic into CS7 = vs. CS6.  One of the implications of this draft appears to be that = this approach is no longer recommended,

              [ ... snipped due to UPDATE = ...]

      UPDATE: I'm = informed by people who know better than I that routing does not use = CS7, so it suffices to add = routing to the list of traffic that is not appropriate for the = Administrative Service class.

      [Joe] Left it as = was.

      Say how to = distinguish Network Control signaling flows from user/subscriber = signaling (this is not as easy as it looks, as it may depend on who owns the = softswitch).

      [Joe] Addressed in = Section 2.2, and 5.1.

      -- Section = 4.1

      IP Telephony = "MUST" use Telephony service class is at odds with the = "SHOULD" for the list of protocols - either explain that the = listed protocols can be used for services other than IP Telephony, or = downgrade the "MUST" to a "SHOULD".

      [Joe] Change it to = SHOULD.

         = o  Packet flows from trusted sources (media gateways = inside

            administered network) MAY not = require policing.

      Can't say "MAY = not", and that's also not quite right.  Try "Policing is = OPTIONAL for traffic from trusted sources whose behavior is assured via other means (e.g., = administrative controls on those systems)." The text in the = immediately following bullet has a better structure.

      [Joe] Changed it to = state that policing is OPTIONAL.

      -- Section = 4.2

      Explain = "clipping".  In essence, if the signaling protocol that sets up the connection = fails to complete in the expected time, the result is audio = loss/degradation at the start of the session, which is particularly = noticeable when dealing with unforgiving POTS systems.

      [Joe] Added Section = 5.3 "Explanation of Ring Clipping".


      How is "peer = to peer real time control function" distinguished from low latency = data?  Data vs. control is fuzzy at best, so some discussion of = what is controlled and/or the importance of the control function would = help.

      [Joe] Addressed in several sections 2.2, 2.3 = and 5.1.

      -- Section = 4.3

      In first paragraph, = expand "Video conferencing" example to "Audio and video = conferencing".

      [Joe] = Done.

      (a) If the end = point is not capable of setting

         the = DSCP value, then the router topologically closest to the end

         point = MUST perform Multifield (MF) Classification as defined in

         = [RFC2475] and mark all packets as AF41.

      That's peculiar - = it looks like it assumes the end-point stays inside the rate = "A" profile/envelope, unless I missed something.  Was = AF4x intended instead of AF41?

      [Joe] Changed it to = AF4x.

      (b) Just to = complicate things - running trTCM in Color-Aware mode assumes that "A" and = "B" don't change across domain boundaries.  If they do, = Color-Blind may be necessary if the trTCM rates or burst sizes increase = significantly in the direction of flow (else get too much red & = yellow traffic, by comparison to traffic coming = in on interfaces with trTCM running Color-Blind).

      [Joe] Made changes = to Conditioning Performed at DiffServ Network Edge sections = to:

      o  If packets = are marked by a trusted sources or previous trusted DiffServ domain, and the color marking is to be preserved, then the = two rate three color marker SHOULD be configured to operate = in Color-Aware mode.

      o  If the = packet marking is not trusted or the color marking is not to be preserved, then the two rate three color marker SHOULD = be configured to operate in Color-Blind mode.

      (c) Should say = something about use or non-use of marking to distinguish = application-defined content layers in a single [media] stream (e.g., = complete frames vs. delta frames, additional data for higher = resolution). IMHO, history reveals this example to be an attractive nuisance =

      (intellectually = appealing, but unworkable in practice due to dynamic variation in codec = output rates) and hence ought to carry a "SHOULD NOT" = recommendation to disfavor it by comparison to the straight = application-level-unaware = rate-metering described here.

      [Joe] Deleted statement (last sentence in = the first paragraph of section 4.3) that: "In the = future, it is expected that these services will = generate continuously variable rate traffic with = packet marking indicating = flow importance." No = discussion was added to draft on "complete frames vs. delta frames", = etc. metering/conditioning scenarios as this draft only addresses = application-level-unaware rate metering.


      -- Section = 4.5

      Section 4.3 = comments (a), (b), and (c) = apply here (but substitute AF3* for any AF4* occurrences in those = comments).

      [Joe] (a) and (b) = changed to as above for AF3*. (c) only stated rate-metering.

      -- Section = 4.7

      Section 4.3 = comments (a), (b), and (c) apply here (but substitute AF2* for any = AF4* occurrences in those = comments and likewise substitute srTCM for trTCM).

      [Joe] (a) and (b) = changed to as above for AF2*. (c) only stated rate-metering.

      -- Section = 4.8

      Section 4.3 = comments (a), (b), and (c) apply here (but substitute AF1* for any AF4* occurrences in those = comments).

      [Joe] (a) and (b) = changed to as above for AF1*. (c) only stated rate-metering.

      -- Section = 4.9

         SHOULD = be configured to receive a small

         = percentage of forwarding resources (at least 5%).

      That = can't what was intended, as = it places a cap on best effort bandwidth.  Remove the cap by doing = something like inserting "at least" before "a small = percentage" and adding "as a guaranteed minimum" at the = end.  I suspect this is a typo/thinko/oversight.

      [Joe] Modified sentence so that no cap is implied on bandwidth.

      -- Section = 5

      In general, this = section should be enriched/extended, and in particular:

      - Please add a VPN = service mapping discussion.

      [Joe] Added Section 5.4 on support of service = classes in VPNs.

      - A discussion of mapping media flows = (audio and/or video) should go

          = here, unless it's covered by the discussion requested in Section = 2.1

      [Joe] Addressed in = Section 2.2

-       Please add a summary of the UMTS traffic class = mappings.

      [Joe] After a = closer analysis, we = determined that further work is needed in this area. We believe that = the interworking between DiffServ service classes and UMTS Traffic = Classes should be addressed in a separate document. Therefore, we = removed from this draft any suggested mapping of DSCP values and DiffServ service classes into = UMTS Traffic Classes.


      ----------------------------------------------------

      David L. Black, = Senior Technologist

      EMC Corporation, = 176 South St., Hopkinton, MA  01748

      +1 (508) = 293-7953          &nbs= p;  FAX: +1 (508) = 293-7786

      black_david@emc.com        = Mobile: +1 (978) 394-7754

      ----------------------------------------------------

      _______________________________________________

      tsvwg mailing = list

      tsvwg@ietf.org

      https://www1.ietf.org/mailman/listinfo/tsvwg


      Regards, Joe.

      Jozef = Babiarz

      email: = babiarz@nortelnetworks.com

------_=_NextPart_001_01C4BA24.600D271A-- --===============0565726411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0565726411==-- From tsvwg-bounces@ietf.org Thu Oct 28 23:15:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01857; Thu, 28 Oct 2004 23:15:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNSw-0002Q1-7Y; Thu, 28 Oct 2004 23:30:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMnR-0004eb-DY; Thu, 28 Oct 2004 22:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM39J-0005W1-GC for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 07:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16853 for ; Mon, 25 Oct 2004 07:36:28 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3Mj-0004R6-JE for tsvwg@ietf.org; Mon, 25 Oct 2004 07:50:23 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PBZsBF381230; Mon, 25 Oct 2004 07:35:54 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PBZrIA110822; Mon, 25 Oct 2004 07:35:53 -0400 Received: from zurich.ibm.com (sig-9-146-221-79.de.ibm.com [9.146.221.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA62078; Mon, 25 Oct 2004 13:35:52 +0200 Message-ID: <417CE51D.5050208@zurich.ibm.com> Date: Mon, 25 Oct 2004 13:35:57 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jozef Babiarz References: <9671A92C3C8B5744BC97F855F7CB646501CC02D2@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646501CC02D2@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Oct 2004 22:47:16 -0400 Cc: Kwok-Ho Chan , Fred Baker , tsvwg@ietf.org Subject: [Tsvwg] Re: Review comments diffserv-basic-classes-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Thanks. I guess Kathie will still have some objections, but this seems to take care of my comments. Brian Jozef Babiarz wrote: > Thanks Brian for the review and comments. Your list of changes has been > incorporated into version 04. See below for details. > > Fred Baker wrote: > >>At 01:41 PM 08/25/04 +0200, Brian E Carpenter wrote: >> >> >>>A couple more thoughts, after a side conversation with Kathie. >>> >>>As I said, my comfort level is higher, but this doesn't remove some >>>older basic concerns... maybe I should have mentioned these in the >>>tsvwg meeting, but I was rushing between sessions. >>> >>>1. Thirteen classes is about eight too many for real deployments. It >>>will be far too easy for readers to miss the essential comment hidden >>>in the middle of section 2.1: >>> >>> >>>>It is expected that network administrators will choose the service >>>>classes that they will support based on their need, starting off with >>>>three or four service classes for user traffic and add others as the >>>>need arises. >>> >>> >>>This really needs to be mentioned earlier and more prominently, with >>>some emphasis that all classes are OPTIONAL except that the default >>>class is REQUIRED. >> >> >>OK. Specifically where would you like this? > > > How about the end of section 1.2? I think it needs to be in the reader's > mind before hitting the details. > > [Joe] Added below paragraph to section 1.2: > The Default Forwarding "Standard" service class is REQUIRED, all other > service classes are OPTIONAL. It is expected that network administrators > will choose the level of service differentiation that they will support > based on their need, starting off with three or four service classes for > user traffic and add others as the need arises. > > > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Friday, July 16, 2004 10:45 AM > To: Fred Baker; Babiarz, Jozef [CAR:0S03:EXCH]; Chan, Kwok-Ho > [BL60:470:EXCH] > Subject: Re: I-D ACTION:draft-baker-diffserv-basic-classes-03.txt > > Hi, > > My comfort level with this is much higher than with the > earlier versions. I still have a couple of substantive > comments, however. > > 1. I think you need to add a clear statement somewhere in > section 1 like: The facts that four code points are recommended > for AF, and that one code point is recommended for EF, are > arbitrary choices, and the architecture allows any reasonable > number of AF and EF classes simultaneously. The choice of > four AF classes and one EF class in the current document is > also arbitrary, and operators MAY choose to operate more or > fewer of either. > > [Joe] Added the above statement to Section 1.4 Key Service Concepts, at the > end of the first paragraph. > > 2. Going further in the same direction, since all choices > of code points and service classes are arbitrary in the diffserv > architecture, I think that almost all the MUSTs in the document > should be SHOULDs. There are just a few that could reasonably > be left as MUST, namely > > >>The service MUST be engineered so that EF marked packet flows >> have sufficient bandwidth in the network to provide guaranteed >> delivery. > > > (which really just repeating part of the definition of EF) > > and > > >> The probability of loss of AF41 traffic MUST NOT >> exceed the probability of loss of AF42 traffic, which in turn MUST >> NOT exceed the probability of loss of AF43 traffic. > > > (ditto for AF) > > and > > >> The Standard service class MUST use the Default Forwarding (DF) PHB >> defined in [RFC2474] > > > [Joe] Changed all MUST to SHOULD except as noted above. > (ditto for DF) > > You certainly can't have constructs like > > >> RECOMMENDED Network Edge Conditioning: >> o At peering points (between two DiffServ networks) where SLAs are >> in place, CS6 marked packets MUST be policed, e.g. using a single >> rate with burst size (sr+bs) token bucket policer to keep the CS6 >> marked packet flows to within the traffic rate specified in the >> SLA. > > > with a MUST governed by a RECOMMENDED. > [Joe] Changed the MUST to SHOULD throughout the draft. > > Regards > Brian > > Regards, Joe. > email: babiarz@nortelnetworks.com > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Thu Oct 28 23:16:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01933; Thu, 28 Oct 2004 23:16:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNUG-0002Rw-Ma; Thu, 28 Oct 2004 23:31:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMnT-0004hV-3e; Thu, 28 Oct 2004 22:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAio-0005Xx-AN for tsvwg@megatron.ietf.org; Mon, 25 Oct 2004 15:41:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27418 for ; Mon, 25 Oct 2004 15:41:36 -0400 (EDT) From: Armando@mail.eecis.udel.edu Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAwI-0005tN-TV for tsvwg@ietf.org; Mon, 25 Oct 2004 15:55:36 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 07C5232E6A; Mon, 25 Oct 2004 15:41:34 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 0CDFB32E4D; Mon, 25 Oct 2004 15:41:33 -0400 (EDT) Date: Mon, 25 Oct 2004 15:41:33 -0400 (EDT) X-X-Sender: acaro@stimpy.eecis.udel.edu To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-12.txt In-Reply-To: <417CBF66.2030603@ericsson.com> Message-ID: References: <200410191150.HAA14673@ietf.org> <41795007.1020500@stewart.chicago.il.us> <417CBF66.2030603@ericsson.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on louie.udel.edu X-Spam-Status: No, hits=-0.3 required=4.1 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Thu, 28 Oct 2004 22:47:16 -0400 Cc: "Randall Stewart -- Randall Stewart \(cisco\)" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Mon, 25 Oct 2004, Stephan Baucke wrote: > I'd like to bring up another clarification which didn't make it into the > imp-guide in time (although I understand that the authors in principle > agree to include it). It is a clarification of Karn's algorithm which > sometimes results in wrong RTT samples being taken if not properly > implemented. > We propose to include the following clarification in the imp-guide: > > Karn's algorithm: RTT measurements MUST only be made using a packet > with TSN r if no packet with TSN less than or equal to r is > retransmitted since r was first sent. Yes, that's my fault. I was supposed to put that change in. Randall: Since I currently can't log into your machine, can you make the change? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Fri Oct 29 12:32:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13225; Fri, 29 Oct 2004 12:32:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZuD-0002kr-OG; Fri, 29 Oct 2004 12:47:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZF6-0000kB-Cv; Fri, 29 Oct 2004 12:04:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZ9F-0005jC-0Y for tsvwg@megatron.ietf.org; Fri, 29 Oct 2004 11:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10939 for ; Fri, 29 Oct 2004 11:58:38 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZNX-00024Q-2n for tsvwg@ietf.org; Fri, 29 Oct 2004 12:13:28 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id i9TG0EUH020913; Fri, 29 Oct 2004 09:00:14 -0700 (MST) Received: from motorola.com (dw41-0a1171f5.cig.mot.com [10.17.113.245]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i9TFoUUE020419; Fri, 29 Oct 2004 10:50:31 -0500 Message-ID: <41826928.4020703@motorola.com> Date: Fri, 29 Oct 2004 11:00:40 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@psg.com, Jon Peterson Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org Subject: [Tsvwg] request for agenda item for tsvwg in DC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi, I'd like to request a short time slot to present our "SCTP NAT Transverse Considerations" draft at tsvwg in DC. The draft is at by Q. Xie, R. Stewart, and M. Holdrege. We'd also like to ask if it can be made a tsvwg work item for an informational RFC. regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg