From mailnull@www1.ietf.org Thu Jan 2 15:48:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13807 for ; Thu, 2 Jan 2003 15:48:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02KvLx20763 for tsvwg-archive@odin.ietf.org; Thu, 2 Jan 2003 15:57:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KuXJ20716; Thu, 2 Jan 2003 15:56:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02KtnJ20656 for ; Thu, 2 Jan 2003 15:55:49 -0500 Received: from web8206.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13729 for ; Thu, 2 Jan 2003 15:46:49 -0500 (EST) Message-ID: <20030102205000.54893.qmail@web8206.mail.in.yahoo.com> Received: from [61.1.106.48] by web8206.mail.in.yahoo.com via HTTP; Thu, 02 Jan 2003 20:50:00 GMT Date: Thu, 2 Jan 2003 20:50:00 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] a query Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello everyone, We are a group of 3 students, Anup Deshpande, Prasad Edlabadkar and Amit Somanai, from Pune Institute of Computer Technology ,Pune , India. We are studying in the 4th year(i.e. final year) of Electronics & Telecommunication Engineering. We have a thrust for cutting edge technology and love working on challenging projects. We also like working on innovative ideas. Right now we are working on our final year project. The basic Project idea was to transport SS7 signals using TCP. But then we came across the disadvantages of TCP. So we have three options with us : 1. Using SCTP instead of TCP at the transport level 2. Using Sigtran stack 3. Using UDP and develop some application level on it The problem is we don`t know which one is actually feasible. We are implementing the project in Linux. Is there any Linux Kernel that is supporting SCTP. Can you suggest any small module that is still to implemented? Plz do reply ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 2 16:38:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15037 for ; Thu, 2 Jan 2003 16:38:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02Lkll24688 for tsvwg-archive@odin.ietf.org; Thu, 2 Jan 2003 16:46:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LjHJ24596; Thu, 2 Jan 2003 16:45:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02LiVJ24557 for ; Thu, 2 Jan 2003 16:44:31 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14938 for ; Thu, 2 Jan 2003 16:35:29 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h02Lc7Nn001647; Thu, 2 Jan 2003 15:38:13 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E14B13E.4090003@stewart.chicago.il.us> Date: Thu, 02 Jan 2003 15:38:07 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: amit somani CC: tsvwg@ietf.org Subject: Re: [Tsvwg] a query References: <20030102205000.54893.qmail@web8206.mail.in.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Amit: A couple of suggestions for you: 1) Yes you can get a SCTP stack for linux (sourceforge I think) lk-sctp is the project name I think. 2) I do think this question is best addressed to the sigtran mailing list... (I think sigtran@ietf.org .. but please check on this). They specialize in SS7/IP ... tsvwg usually does not discuss SS7 but end to end transport issues.. R amit somani wrote: > Hello everyone, > > We are a group of 3 students, Anup Deshpande, Prasad > Edlabadkar and Amit Somanai, from Pune Institute of > Computer Technology ,Pune , India. We are studying in > the 4th year(i.e. final year) of Electronics & > Telecommunication Engineering. We have a thrust for > cutting edge technology and love working on > challenging projects. We also like working on > innovative ideas. Right now we are working on our > final year project. The basic Project idea was to > transport SS7 signals using TCP. But then we came > across the disadvantages of TCP. > So we have three options with us : > 1. Using SCTP instead of TCP at the transport level > 2. Using Sigtran stack > 3. Using UDP and develop some application level on it > > The problem is we don`t know which one is actually > feasible. We are implementing the project in Linux. Is > there any Linux Kernel that is supporting SCTP. Can > you suggest any small module that is still to > implemented? > > Plz do reply > > > ________________________________________________________________________ > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 2 16:54:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15442 for ; Thu, 2 Jan 2003 16:54:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02M35725923 for tsvwg-archive@odin.ietf.org; Thu, 2 Jan 2003 17:03:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02M1XJ25871; Thu, 2 Jan 2003 17:01:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02M0WJ25634 for ; Thu, 2 Jan 2003 17:00:32 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15413 for ; Thu, 2 Jan 2003 16:51:34 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02LshSK017696; Thu, 2 Jan 2003 16:54:44 -0500 Received: from dyn9-47-18-98.beaverton.ibm.com (dyn9-47-18-98.beaverton.ibm.com [9.47.18.98]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02Lsgwn043854; Thu, 2 Jan 2003 14:54:43 -0700 Date: Thu, 2 Jan 2003 13:56:32 -0800 (PST) From: Sridhar Samudrala X-X-Sender: To: =?iso-8859-1?q?amit=20somani?= cc: Subject: Re: [Tsvwg] a query In-Reply-To: <20030102205000.54893.qmail@web8206.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 2 Jan 2003, amit somani wrote: > Hello everyone, > > We are a group of 3 students, Anup Deshpande, Prasad > Edlabadkar and Amit Somanai, from Pune Institute of > Computer Technology ,Pune , India. We are studying in > the 4th year(i.e. final year) of Electronics & > Telecommunication Engineering. We have a thrust for > cutting edge technology and love working on > challenging projects. We also like working on > innovative ideas. Right now we are working on our > final year project. The basic Project idea was to > transport SS7 signals using TCP. But then we came > across the disadvantages of TCP. > So we have three options with us : > 1. Using SCTP instead of TCP at the transport level > 2. Using Sigtran stack > 3. Using UDP and develop some application level on it > > The problem is we don`t know which one is actually > feasible. We are implementing the project in Linux. Is > there any Linux Kernel that is supporting SCTP. Can > you suggest any small module that is still to > implemented? Yes. The 2.5 beta version of the linux kernel includes SCTP support. You can download it from www.kernel.org. The latest release is 2.5.54. The SCTP implementation is currently under development but is in a usable state. It supports the UDP-style SCTP sockets interface as defined in the the following internet draft http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-05.txt and will be compliant to RFC2960 when complete. You can find more information about the linux kernel SCTP project at http://sourceforge.net/projects/lksctp Thanks Sridhar _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 6 10:23:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05363 for ; Mon, 6 Jan 2003 10:23:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06FXK223952 for tsvwg-archive@odin.ietf.org; Mon, 6 Jan 2003 10:33:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FVwJ23891; Mon, 6 Jan 2003 10:31:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06FUVJ23830 for ; Mon, 6 Jan 2003 10:30:31 -0500 Received: from smtp0.libero.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05294 for ; Mon, 6 Jan 2003 10:19:44 -0500 (EST) Received: from libero.it (193.70.192.64) by smtp0.libero.it (6.7.015) id 3E0D85050004F978 for tsvwg@ietf.org; Mon, 6 Jan 2003 16:22:57 +0100 Date: Mon, 6 Jan 2003 16:22:57 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?pierluigi=5Fmarra@libero.it?=" To: "=?iso-8859-1?Q?tsvwg?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 62.11.54.62 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06FUVJ23835 Subject: [Tsvwg] =?iso-8859-1?Q?snd=5Fmax_reset_in_TCP=3F?= Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In a article I read : "...many existing TCP implementations reset snd_max (the highest byte sent) to snd_una (the highest byte acknowledged) when they exit persist state........." I recall that TCP enters persist state whenever a zero advertised window has been received and exit persist state when a successive non-zero advertised window has been received. Please, could someone tell me which existing TCP implementations follow the behaviour described upon? (reset snd_max to snd_una ) Thanks in advance, Pierluigi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jan 7 18:08:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02385 for ; Tue, 7 Jan 2003 18:08:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07NJXN26466 for tsvwg-archive@odin.ietf.org; Tue, 7 Jan 2003 18:19:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NIgJ26444; Tue, 7 Jan 2003 18:18:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NHHJ26391 for ; Tue, 7 Jan 2003 18:17:17 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02327; Tue, 7 Jan 2003 18:05:50 -0500 (EST) From: Yogesh.Swami@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h07N8wE27546; Tue, 7 Jan 2003 17:08:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 Jan 2003 17:08:53 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 15:08:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Date: Tue, 7 Jan 2003 17:08:51 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01697822@daebe004.americas.nokia.com> Thread-Topic: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Thread-Index: AcKoeCqsYTZdtXF+TTCoJEx51N9OVgOE9i8wAAPhmmA= To: Cc: , , , , , , X-OriginalArrivalTime: 07 Jan 2003 23:08:52.0889 (UTC) FILETIME=[BEEB8090:01C2B6A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07NHHJ26393 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello, [Sorry about the delay in responding] > The security concerns you mention are cetainly valid. But, one does > not need the nonce to exploit things if some man-in-the-middle is > willing to simply generate ACKs indicating "congestion experienced" > for the end receiver. Yes, I agree there are other ways to do DoS attacks (none of the attacks in my previous e-mail was Man in the Middle attack though; they are active/passive eavesdroppers). When people are trying to orchestrate a DoS attack, they need as many DoS vulnerabilities as possible so that they can generate an innocent looking DoS attack-traffic that will be harder even for a human observer to distinguish from a non-attack traffic. For example, if a web site sees 1000 SYN packets per seconds, it can easily figure out that the server is under attack (unless it's CNN or New York Times's web site). On the other hand, however, if the same web server sees 100 false nounce, 100 ECN-experienced, 100 run-away SYN messages, etcetera, it cannot immediately conclude if it is under attack or if the receivers just happen to be on a bad network path... (ECN nounce + ECN) is therefore worse than ECN alone. That's the point I was trying to make. [I guess I was not very clear] BTW, IPSec is not an option here. The present key exchange protocol (IKE) takes 3-5 round-trips to just establish a shared secret (newer protocols like JFK are better--2 round trips--but they are still heavyweight). On top of that, the users will have to wait for at least another 3/2 round trip before they can see the first byte of "data." This is just not a viable option for many servers (it would require 3 IPSec enabled servers where one tradition TCP server would have done--by Little's theorem assuming short lived connections). In addition, IPSec does a whole lot of "other things" (identity protection, non-repudiation ...) which are not needed in most of the cases. If we are serious about security, we should stop solving the problem in an ad hoc manner and make TCP self-secure once and for all. Or we can wait until there is a spectacular attack (after which every web server will have a hack to prevent such attacks. Then we can design protocols to make these hacks work together...). > > And, if the penalty imposed by the sender is worse for blowing the > nonce than for receiving "congestion experienced" then I might agree > that the nonce allows for a bigger and better attack than without As I said in the last paragraph, the penalty is higher because any non-trivial policy will open *one more* door for DOS attack. <...> > The nonce prevents receivers from lying and protects the network <...> I don't buy this: If users want to lie, they don't need to first send a ECN-setup SYN and then later start cheating. They have a simpler option: Not to send ECN-setup at all. Every operating system provides a way to do this. Every OS *has to* provide this because there are some ultra smart firewalls which drop all packets with CWR bit set and never bother to even information the receiver with a reset. Besides, to cheat this way, one will need the source code of the operating system. (If operating system vendors want to cheat, they will just not implement ECN, and probably even save a few pennies too) I am of course assuming here that packets with ECT code points share the same network queues as traditional TCP packets (if they don't, then there are other related problems which need to be solved by DiffServ framework. I don't know all the details :-( ). So, I don't see how ECN nounces are helping. The only place where it might help is with crazy middle boxes. But that problem is again a generic problem that DiffServ should solve (at IP layer)--not TCP. > there are bugs in boxen in the network. The nonce does not protect > against malicious third-parties, I agree -- it was not intended to. > But, I don't think it hurts that case either. > A cheating TCP receiver is a malicious user (if not a third party), and 1 bit nounce can only protect in 50% of the cases. That's why I said the security is weak--it's weak even for the problem it's trying to solve--not because it cannot protect TCP from all possible attacks. I know people have difficulty getting good security with even 2048 bits or more... If people are happy with the nounce placebo, that's fine with me. My only suggestion is that we should not waste (I'm sorry, I could not come with a better word) the bit in the TCP header. Tomorrow if we need those bits for some functionality (instead of for protection), the only option would be to have a new transport layer protocol. In addition, putting the nounce in a TCP option is better since one can use more bits and detect cheating receivers with a higher confidence level than 50%. I bit entropy is too little. --yogesh BTW, just curious to know if someone's designing a protocol police to ensure that TCP senders halve their data rate after packet loss. To the best of my knowledge, TCP receivers are not the only ones who are capable of cheating; even TCP senders can cheat. Just curious know. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jan 7 20:33:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07621 for ; Tue, 7 Jan 2003 20:33:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081ib203436 for tsvwg-archive@odin.ietf.org; Tue, 7 Jan 2003 20:44:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081hUJ03384; Tue, 7 Jan 2003 20:43:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h081gvJ03351 for ; Tue, 7 Jan 2003 20:42:57 -0500 Received: from pop-1.dnv.wideopenwest.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07576; Tue, 7 Jan 2003 20:31:26 -0500 (EST) Received: from thoth.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h081ZU423333; Tue, 7 Jan 2003 19:35:30 -0600 Received: from thoth.ir.bbn.com (localhost [127.0.0.1]) by thoth.ir.bbn.com (8.12.6/8.12.6) with ESMTP id h081YAR2006143; Tue, 7 Jan 2003 20:34:11 -0500 (EST) (envelope-from mallman@thoth.ir.bbn.com) Message-Id: <200301080134.h081YAR2006143@thoth.ir.bbn.com> To: Yogesh.Swami@nokia.com From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: iesg@ietf.org, tsvwg@ietf.org, nspring@cs.washington.edu, djw@cs.washington.edu, ely@cs.washington.edu, mankin@psg.com, sob@harvard.edu Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE01697822@daebe004.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Fly By Night Date: Tue, 07 Jan 2003 20:34:10 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Yogesh- > > The nonce prevents receivers from lying and protects the network > > I don't buy this: > > If users want to lie, they don't need to first send a ECN-setup > SYN and then later start cheating. They have a simpler option: Not > to send ECN-setup at all. This case is not "cheating". Everything is still congestion responsive in this case. The cheating that the nonce prevents is when the receiver can conceal a congestion indication from the network. If you don't setup ECN then your packets will not be marked, but rather dropped -- which means either you have to tell the truth about congestion or you don't get all your data (if you ACK something that has not arrived). I don't think the incentive for covering up congestion is there in the non-ECN case. > A cheating TCP receiver is a malicious user (if not a third > party), and 1 bit nounce can only protect in 50% of the cases. > That's why I said the security is weak--it's weak even for the > problem it's trying to solve--not because it cannot protect TCP > from all possible attacks. I know people have difficulty getting > good security with even 2048 bits or more... This is FUD. The nonce is *much* better than 50%. You have a 50% shot at guessing the nonce right on every ACK. But, if you guess wrong once then the sender is on to you -- so, the probability of guessing right is 0.5^N (where N is the number of ACKs transmitted). So, clearly as the connection progresses and N grows large the probability of keeping your game going gets pretty small pretty quickly. > Tomorrow if we need those bits for some functionality (instead of > for protection), the only option would be to have a new > transport layer protocol. (Actually, when we run out I am sure that the first thing that will happen will be someone generating an RFC defining a TCP "more bits" option.) > BTW, just curious to know if someone's designing a protocol > police=20 to ensure that TCP senders halve their data rate after > packet loss. To the best of my knowledge, TCP receivers are not > the only ones who are capable of cheating; even TCP senders can > cheat. Just curious know. TCP senders could be an even bigger problem -- because they Just Control the sending rate (i.e., they don't need manipulative tricks like the reciever does). See some of the ICIR/AT&T work on pushback. Or, Sally Floyd and Kevin Fall's notion of a penalty box. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 8 12:47:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28378 for ; Wed, 8 Jan 2003 12:47:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08Hwpe08559 for tsvwg-archive@odin.ietf.org; Wed, 8 Jan 2003 12:58:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08HqOJ07445; Wed, 8 Jan 2003 12:52:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Hp8J07391 for ; Wed, 8 Jan 2003 12:51:08 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27547; Wed, 8 Jan 2003 12:39:18 -0500 (EST) From: Yogesh.Swami@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08HgcE15763; Wed, 8 Jan 2003 11:42:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 11:42:32 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 11:42:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Date: Wed, 8 Jan 2003 11:42:18 -0600 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE016B21AA@daebe004.americas.nokia.com> Thread-Topic: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Thread-Index: AcK3PUpAOvorxm6SQnaVoWCy9/vRoQ== To: Cc: , , , , , , X-OriginalArrivalTime: 08 Jan 2003 17:42:19.0942 (UTC) FILETIME=[4B06CC60:01C2B73D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08Hp8J07394 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mark, all, > This case is not "cheating". Everything is still congestion > responsive in this case. The cheating that the nonce prevents is > when the receiver can conceal a congestion indication from the > network. You are right. I don't know what I was thinking while making that argument. Apologies. > This is FUD. The nonce is *much* better than 50%. You have a 50% > shot at guessing the nonce right on every ACK. But, if you guess > wrong once then the sender is on to you -- so, the probability of > guessing right is 0.5^N (where N is the number of ACKs > transmitted). So, clearly as the connection progresses and N > grows large the probability of keeping your game going gets pretty > small pretty quickly. This is just half of the story. The other half is that the probability of an attacker being successful in perpetrating a DoS attack is (1-0.5^n). But an attacker does not have to send N ACKs, total of four ACKs messages for 2 different TCP segments will suffice (the sequence of messages (time=0, ACK-1, Nounce=0) (time=0, ACK-1, Nounce=1) (time=1, ACK-2, Nounce=1) (time=1, ACK-2, Nounce=0), is all that an attacker has to send to trigger the sender's policy--assuming FIFO queues.) > (Actually, when we run out I am sure that the first thing that > will happen will be someone generating an RFC defining a TCP "more > bits" option.) Sure. The other option is to let the 4 bits in the TCP be the MSbs of DOFF, and let the Nounce be an option. The reason we differ on nounces is probably because I am too pessimistic about DoS attacks, and the draft is too pessimistic about cheating receivers and middle boxes. To cheat an attacker needs the source code of the OS, technical expertise of the internal working of the OS etc. On the other hand, to do a DoS attack, all one needs is a script that can snoop and construct TCP ACKs. I don't know which of the two is more dangerous in a realistic scenario. --yogesh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 8 12:55:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29275 for ; Wed, 8 Jan 2003 12:55:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08I6rt09209 for tsvwg-archive@odin.ietf.org; Wed, 8 Jan 2003 13:06:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08I3CJ08995; Wed, 8 Jan 2003 13:03:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08I24J08924 for ; Wed, 8 Jan 2003 13:02:04 -0500 Received: from seraph2.grc.nasa.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28641; Wed, 8 Jan 2003 12:50:15 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1355A689D2; Wed, 8 Jan 2003 12:53:31 -0500 (EST) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id h08HrT48022706; Wed, 8 Jan 2003 12:53:29 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA89217; Wed, 8 Jan 2003 12:53:29 -0500 (EST) Message-Id: <200301081753.MAA89217@guns.lerc.nasa.gov> To: Yogesh.Swami@nokia.com From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: iesg@ietf.org, tsvwg@ietf.org, nspring@cs.washington.edu, djw@cs.washington.edu, ely@cs.washington.edu, mankin@psg.com, sob@harvard.edu Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental In-Reply-To: <025E7DD4182874489CC2F61EE0FA19CE016B21AA@daebe004.americas.nokia.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Thunderstruck Date: Wed, 08 Jan 2003 12:53:29 -0500 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > > A cheating TCP receiver is a malicious user (if not a third > > > party), and 1 bit nounce can only protect in 50% of the cases. > > > That's why I said the security is weak--it's weak even for the > > > problem it's trying to solve--not because it cannot protect > > > TCP from all possible attacks. I know people have difficulty > > > getting good security with even 2048 bits or more... > > > > This is FUD. The nonce is *much* better than 50%. You have a 50% > > shot at guessing the nonce right on every ACK. But, if you guess > > wrong once then the sender is on to you -- so, the probability of > > guessing right is 0.5^N (where N is the number of ACKs > > transmitted). So, clearly as the connection progresses and N > > grows large the probability of keeping your game going gets pretty > > small pretty quickly. > > This is just half of the story. I have requoted the statement you made (at the top) that I responded to. I was considering only the case when we were considering *receivers* (not third parties) lying. I stick by the above argument. The case of someone snooping traffic and hosing the data rate by lying is as you outlined (not quoted). But, that was not the comment I responded to. We agree that eavesdroppers can exploit ECN and the ECN nonce as a mechanism for DoS. I simply wanted to apply pushback to your statement that the nonce does not offer good protection for the problem it purports to solve. In my opinion, it offers good protection for its intent. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 8 14:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03158 for ; Wed, 8 Jan 2003 14:18:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08JToV15285 for tsvwg-archive@odin.ietf.org; Wed, 8 Jan 2003 14:29:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JSFJ15217; Wed, 8 Jan 2003 14:28:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JR6J15156 for ; Wed, 8 Jan 2003 14:27:06 -0500 Received: from poplar.cs.washington.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02918; Wed, 8 Jan 2003 14:15:14 -0500 (EST) Received: from nspring by poplar.cs.washington.edu with local (Exim 3.35 #1 (Debian)) id 18WLig-0002KU-00; Wed, 08 Jan 2003 11:18:30 -0800 Date: Wed, 8 Jan 2003 11:18:30 -0800 From: Neil Spring To: tsvwg@ietf.org Cc: Yogesh.Swami@nokia.com, iesg@ietf.org, djw@cs.washington.edu, ely@cs.washington.edu, mankin@psg.com, sob@harvard.edu Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Message-ID: <20030108191829.GA8895@cs.washington.edu> References: <025E7DD4182874489CC2F61EE0FA19CE016B21AA@daebe004.americas.nokia.com> <200301081753.MAA89217@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301081753.MAA89217@guns.lerc.nasa.gov> User-Agent: Mutt/1.4i Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Wed, Jan 08, 2003 at 12:53:29PM -0500, Mark Allman wrote: > We agree that eavesdroppers can exploit ECN and the ECN > nonce as a mechanism for DoS. Can either of you explain this statement a little bit more? If an evesdropper is able to spoof an acknowledgement with a faulty nonce, as described in Yogesh's prior mail, it would seem just as capable of spoofing a RST to tear down the connection in one packet (not probabilistically four). While the nonce doesn't solve the problem of spoofing evesdroppers, I don't yet see how the nonce increases the potential for misbehavior in the network. -neil _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 8 15:30:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06283 for ; Wed, 8 Jan 2003 15:30:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08KgHJ20178 for tsvwg-archive@odin.ietf.org; Wed, 8 Jan 2003 15:42:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KduJ20058; Wed, 8 Jan 2003 15:39:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08KcKJ20004 for ; Wed, 8 Jan 2003 15:38:20 -0500 Received: from MAIL.cynetanetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06101 for ; Wed, 8 Jan 2003 15:26:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Date: Wed, 8 Jan 2003 14:29:43 -0600 Message-ID: <9255B6CD76A88943A3062F7D4E6432F543BA35@mail.cynetanetworks.com> Thread-Topic: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental Thread-Index: AcK3U2IhiogHmwl4R+qJql0niFyv1AAAFQdA From: "Spencer Dawkins" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08KcLJ20005 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Yeah, what Neil said. In addition, I Would Have Thought that an attacker who couldn't spoof an ACK (or RST) would just be SYN-flooding anyway. I'm not sure why we're not holding ECN Nonces to this standard. Do we think third-party attackers would rather twiddle with TCP sending rates than (1) overwhelm a network segment entirely via flooding, or (2) RST TCP connections? Sounds like an awfully polite attacker to me - or is that the answer (twiddling with TCP sending rates would be less likely to set off intrusion detection systems)? Spencer > -----Original Message----- > From: Neil Spring [mailto:nspring@cs.washington.edu] > Sent: Wednesday, January 08, 2003 1:19 PM > To: tsvwg@ietf.org > Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with > Nonces to > Experimental > > > On Wed, Jan 08, 2003 at 12:53:29PM -0500, Mark Allman wrote: > > We agree that eavesdroppers can exploit ECN and the ECN > > nonce as a mechanism for DoS. > > Can either of you explain this statement a little bit more? > > If an evesdropper is able to spoof an acknowledgement with a > faulty nonce, as described in Yogesh's prior mail, it would > seem just as capable of spoofing a RST to tear down the > connection in one packet (not probabilistically four). > While the nonce doesn't solve the problem of spoofing > evesdroppers, I don't yet see how the nonce increases the > potential for misbehavior in the network. > > -neil> _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 9 11:57:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17608 for ; Thu, 9 Jan 2003 11:57:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09H8mb07113 for tsvwg-archive@odin.ietf.org; Thu, 9 Jan 2003 12:08:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09H6gJ06344; Thu, 9 Jan 2003 12:06:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09H1JJ05658 for ; Thu, 9 Jan 2003 12:01:19 -0500 Received: from emulex.emulex.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17375 for ; Thu, 9 Jan 2003 11:49:02 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA12703; Thu, 9 Jan 2003 08:52:10 -0800 (PST) Received: by xbl.ma.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 11:52:10 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF289B8FA8@xbl.ma.emulex.com> From: "Williams, Jim" To: "'Randall Stewart'" Cc: "'tsvwg@ietf.org'" Subject: RE: [Tsvwg] Concerns about SCTP Date: Thu, 9 Jan 2003 11:52:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > > Some comments for you to think upon... :> > > Williams, Jim wrote: > > [...] > > > > I regard the following as two basic > > rules of protocol design. > > > > Rule 1: Two implementations that are fully > > compliant with the protocol definition > > must interoperate. If they don't, > > then that is a defect in the protocol > > definition. > > > > Rule 2: One end of an association should not > > be able to consume an unbounded amount > > of resources on the other end without > > negotiation and agreement from the other > > end. > > > > I believe in this respect, the multi-homing feature > > of SCTP comes up short. Each remote address that > > is supported consumes resources on the local end. > > SCTP places no limit and requires no negotiation > > as to the number addresses that can be included > > in an INIT. The receiver must either allocate > > the resources needed to support this number of > > addresses (violating rule 2), or must abort > > the association if too many are requested > > (violating rule 1). > > > > I don't see how this violates rule 1. SCTP provides a > basic "I can't do that .. not enough resources" in response > to something that can't be done. Yes the association will > not come up until the peer reduces the resources request... If one views it from a system perspective, a user may be running a file system over RDDP over SCTP. If the file system fails to mount, the user would regard this a failure to interoperate. However this failure can be prevented in multiple ways. 1. At the RDDP over SCTP adaption layer, specify that if an endpoint specifies multiple IP addresses and the association setup is aborted with a resource error, the endpoint MUST retry the association with fewer IP addresses. (The draft could also remain silent on this and trust the good sense of the upper layers to do this anyway, but that seems like asking for interoperability woes unnecessarily.) Although this works, I regard it as more of a work around than a well designed negotiation. An example of a well designed negotiation is the mechanism use by SCTP to determine the number of streams per association. 2. Treat this as a flaw in SCTP and fix it. Set aside practical and political considerations for the moment. I regard this a flaw (perhaps minor but real) that affects not only RDDP, but all low end, high speed, embedded implementations of SCTP. If the goal of SCTP is to become a universal transport, not just a high end transport, then this may make sense. I acknowledge that responders to my original post do not agree that there is any flaw. But my own opinion is not yet changed by reading the responses. 3. Acknowledge that SCTP is not an optimum transport for RDDP, and use a different transport. If one were to design a transport optimized for high speed hardware accelerated applications, it would look quite different from SCTP. The counter arguments here, though, are that there is advantage to standardizing on a transport across many applications even if not optimum for each application. And also that transports should be designed to optimize data flow through the network, not to optimize end point implementation, (at least that seems to be the IETF philosophy). Anyway, this is the direction I was hoping to steer the discussion. For now, #1 seems like the preferred direction. But I though #2 and #3 were worth at least brief discussion. > I know, for me, I truly have > a hard time understanding how ECN would work better for > flow control than the rwnd. aka > > ------DATA-----> (rcver realizes its is running low > on resources (chunks/structures/?) > <------SACK(rwnd=0) I agree with this. But I was unaware that this is allowed. TCP specifically forbids retracting a previously advertised window. I am not clear on where SCTP stands on this. It appears that in RFC2960 there is no prohibition on this, but it does seem contrary to a few SHOULDs regarding rwnd calculation. Anyway, this may be the right answer unless the SHOULDs evolve into de facto MUSTs. Interestingly, though, RDDP has the property that all received data can be immediately processed. There is never any need to stop the remote sender. The only problem occurs when data comes in faster than it can be processed. In this case the desired behavior is to slow down the sender a bit, not stop it. Therefore ECN might be a better functional fit for this requirement than rwnd. If the receiver knew how much data the sender currently had outstanding (usually equal to its cwnd) then it could set rwnd to a half (or some other fraction) of that and accomplish the same thing, but the receiver does not have this knowledge. This creates a problem using rwnd to throttle the sender's rate. But this problem doesn't appear insurmountable. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 9 13:18:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19714 for ; Thu, 9 Jan 2003 13:18:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IU5c11962 for tsvwg-archive@odin.ietf.org; Thu, 9 Jan 2003 13:30:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09ISvJ11869; Thu, 9 Jan 2003 13:28:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IMPJ11499 for ; Thu, 9 Jan 2003 13:22:25 -0500 Received: from thebe.your-site.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19489; Thu, 9 Jan 2003 13:10:06 -0500 (EST) Received: from 192.168.0.2 (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5024024534D; Thu, 9 Jan 2003 13:13:21 -0500 (EST) Date: Thu, 9 Jan 2003 12:13:47 -0600 From: Caitlin Bestler Subject: RE: [Tsvwg] Concerns about SCTP To: "'tsvwg@ietf.org'" Cc: "'Randall Stewart'" , "Williams, Jim" , rddp@ietf.org X-Priority: 3 In-Reply-To: <3356669BBE90C448AD4645C843E2BF289B8FA8@xbl.ma.emulex.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 1/9/03, Williams, Jim wrote: > >Interestingly, though, RDDP has the property that all >received data can be immediately processed. There is >never any need to stop the remote sender. The only >problem occurs when data comes in faster than it >can be processed. In this case the desired behavior >is to slow down the sender a bit, not stop it. >Therefore ECN might be a better functional fit >for this requirement than rwnd. > That property is intrinsic to RDDP no matter what transport it runs over. The ULP is responsible for pacing untagged messages, but only the LLP paces tagged messages. RDDP releases all LLP buffers "immediately", meaning as quickly as the placement of the tagged/untagged data can be completed. Given that characteristic it is highly unlikely that there would be buffering resources dedicated to specific assocation or connection. Therefore the challenge, whether over MPA/TCP and/or SCTP, is to ensure that the internal bandwidth required to support DDP placement will not be swamped by all incoming data. Specifically the windows SHOULD be set so that the risk of exhausting the placement bandwith is as low as possible. However those windoes CANNOT beset so that said risk is non-existent. LLP Credits are delivered asynchronously, uncertainty on placemnt speed because of potential host bus contention or retries, and more importantly in integral amounts. Those integral amounts, spread over hundreds of thousands of connections, either force a severe under-allocation or an over-allocation. And certainly the available to-host bandwidth over a conventional host bus is statistically reliable but defintely not guaranteed. Limiting your RNIC to the host bus *guaranteed* rates would be a severe limitation. I believe most implementers will properly choose to take a slight risk of over-allocation, knowing that in the worst case the result is that a packet is dropped. A properly credited LLP packet arrives and there is no available buffer for it. No LLP ack is generated, and it is eventually retransmitted. The same thing can happen at any number of routers and switches along the route for the very same reason. Also consider that in some cases the host memory placement capacity may actually exceed the capacity of the external link layer. In that case LLP flow control deals only with network congestion, RNIC and host buffering is irrelevant. Caitlin Bestler http://asomi.com/CaitlinBestler/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 10 07:12:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25974 for ; Fri, 10 Jan 2003 07:12:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ACOSW26126 for tsvwg-archive@odin.ietf.org; Fri, 10 Jan 2003 07:24:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ACNiJ26087; Fri, 10 Jan 2003 07:23:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0A9v9J15852 for ; Fri, 10 Jan 2003 04:57:09 -0500 Received: from smtp.dave.sonera.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22480 for ; Fri, 10 Jan 2003 04:44:29 -0500 (EST) Received: from gurtoan1-nb2.etela.sonera.fi ([131.177.37.47]:1212 "HELO gurtoannb2") by inside.dave.sonera.fi with SMTP id ; Fri, 10 Jan 2003 11:47:34 +0200 Message-ID: <005d01c2b88d$5471f850$2f25b183@gurtoannb2> From: "Andrei Gurtov" To: Cc: "Sally Floyd" Date: Fri, 10 Jan 2003 11:47:46 +0200 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Is a TFRC sender allowed to increase the send rate more than twice? Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, In draft-ietf-tsvwg-tfrc-05.txt on p. 11 a TFRC sender computes its send rate as If (p > 0) Calculate X_calc using the TCP throughput equation. X = max(min(X_calc, 2*X_recv), s/t_mbi); when there are some losses detected. A question is, when X_recv and X_calc suddenly increase, is the sender allowed to increase its transmission rate X more than twice? Such situation could appear when a number of delayed or reordered packets show up at the receiver causing the loss rate become low and the receive rate higher than the current transmit rate. Alternatively, the receiver or PEP having good knowledge of the bottleneck link could adjust the loss rate and X_recv in feedback packets to make the sender adapt faster to significant changes in available bandwidth. Yet another possibility is a spoofing attack doing the same. According to the equation above more than twofold increase of the send rate is ok, but the NS implementation clamps the send rate increase at twice the current in all cases. Off topic: Given the recent discussion on TFRC response to application-limited connections, I would be cautious to say that TFRC is suitable for telephony applications. A typo in p. 21 pervious -> previous? Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 10 07:50:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26651 for ; Fri, 10 Jan 2003 07:50:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AD2ht28667 for tsvwg-archive@odin.ietf.org; Fri, 10 Jan 2003 08:02:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AD28J28646; Fri, 10 Jan 2003 08:02:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AD1kJ28624 for ; Fri, 10 Jan 2003 08:01:46 -0500 Received: from stewart.chicago.il.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26636 for ; Fri, 10 Jan 2003 07:49:04 -0500 (EST) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id h0ACqJB3002187; Fri, 10 Jan 2003 06:52:19 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3E1EC203.6090405@stewart.chicago.il.us> Date: Fri, 10 Jan 2003 06:52:19 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Williams, Jim" CC: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] Concerns about SCTP References: <3356669BBE90C448AD4645C843E2BF289B8FA8@xbl.ma.emulex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comments in-line Williams, Jim wrote: > >>-----Original Message----- >>From: Randall Stewart [mailto:randall@stewart.chicago.il.us] >> >>Some comments for you to think upon... :> >> >>Williams, Jim wrote: >> >>>[...] >>> >>>I regard the following as two basic >>>rules of protocol design. >>> >>>Rule 1: Two implementations that are fully >>> compliant with the protocol definition >>> must interoperate. If they don't, >>> then that is a defect in the protocol >>> definition. >>> >>>Rule 2: One end of an association should not >>> be able to consume an unbounded amount >>> of resources on the other end without >>> negotiation and agreement from the other >>> end. >>> >>>I believe in this respect, the multi-homing feature >>>of SCTP comes up short. Each remote address that >>>is supported consumes resources on the local end. >>>SCTP places no limit and requires no negotiation >>>as to the number addresses that can be included >>>in an INIT. The receiver must either allocate >>>the resources needed to support this number of >>>addresses (violating rule 2), or must abort >>>the association if too many are requested >>>(violating rule 1). >>> >> >>I don't see how this violates rule 1. SCTP provides a >>basic "I can't do that .. not enough resources" in response >>to something that can't be done. Yes the association will >>not come up until the peer reduces the resources request... > > > If one views it from a system perspective, a user may > be running a file system over RDDP over SCTP. If the > file system fails to mount, the user would regard this > a failure to interoperate. However this failure can > be prevented in multiple ways. > > 1. At the RDDP over SCTP adaption layer, specify that > if an endpoint specifies multiple IP addresses and > the association setup is aborted with a resource error, > the endpoint MUST retry the association with fewer > IP addresses. (The draft could also remain silent > on this and trust the good sense of the upper layers > to do this anyway, but that seems like asking > for interoperability woes unnecessarily.) > > Although this works, I regard it as more of a > work around than a well designed negotiation. > An example of a well designed negotiation is > the mechanism use by SCTP to determine the number > of streams per association. > > 2. Treat this as a flaw in SCTP and fix it. Set > aside practical and political considerations for > the moment. I regard this a flaw (perhaps minor > but real) that affects not only RDDP, but all > low end, high speed, embedded implementations of > SCTP. If the goal of SCTP is to become a > universal transport, not just a high end > transport, then this may make sense. > > I acknowledge that responders to my original > post do not agree that there is any flaw. But > my own opinion is not yet changed by reading > the responses. > > 3. Acknowledge that SCTP is not an optimum transport > for RDDP, and use a different transport. If one > were to design a transport optimized for high > speed hardware accelerated applications, it would > look quite different from SCTP. > > The counter arguments here, though, are that there > is advantage to standardizing on a transport across > many applications even if not optimum for each > application. And also that transports should > be designed to optimize data flow through the > network, not to optimize end point implementation, > (at least that seems to be the IETF philosophy). > > > Anyway, this is the direction I was hoping to steer > the discussion. For now, #1 seems like the preferred > direction. But I though #2 and #3 were worth at least > brief discussion. > As you may have guessed I to am in camp 1 :> I don't beleive it is a flaw... and even if we did (which I know I don't) the solution would require multiple message round trips to setup the addresses... this is quite a bit unlike the streams issue. I just don't see this as a problem.. the DDP adaption is very unlikely to allow multiple IP addresses... if so the NIC's will need to all be related and cross-configured together... DDP clients will just have to be aware of this issue... On top of that I also think multi-homing is not as numerous as you think for clients... two maybe three addresses is what most clients will have.. not the 100's you seem to invision.. in fact we could even add to the SCTP-DDP adaption something like "A user of SCTP MUST NOT bind more than N addresses"... and then put in verbage to say how the receiver an association with more than N addresses aborts it... very simple.. and I believe there is a user defined reason for abort that I know the socket API supports... so we define a SCTP-DDP adatption ABORT reason that comes in with the abort.. and your problem is solved...maybe not what you want but I don't see anything wrong with this.. > >>I know, for me, I truly have >>a hard time understanding how ECN would work better for >>flow control than the rwnd. aka >> >>------DATA-----> (rcver realizes its is running low >> on resources (chunks/structures/?) >> <------SACK(rwnd=0) > > > I agree with this. But I was unaware that this is allowed. > TCP specifically forbids retracting a previously advertised > window. > I suggest you take a close look at the code snippet below: " #define sbspace(sb) \ ((long) imin((int)((sb)->sb_hiwat - (sb)->sb_cc), \ (int)((sb)->sb_mbmax - (sb)->sb_mbcnt))) " This is one of the key macro's used out of sys/socketvar.h which is used to caclulate space and the windows.. notice the use of sb_mbmax and sb_mbcnt... these track the amount of mbuf useage... The reason I know this is I have been bitten by the above when we were doing our SCTP implementation... Since the mbcnt also comes in to play I was seeing the rwnd drop sharply at the end unexpectedly.. this is because the mbuf limits were being hit before the sb_cc limits... I won't go in to the details of how I worked around this ... my point is that TCP has factored into its rwnd (at least in bsd) the amount of mbuf's (structures to track things) used for years... R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 10 13:41:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10682 for ; Fri, 10 Jan 2003 13:41:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AIrX321251 for tsvwg-archive@odin.ietf.org; Fri, 10 Jan 2003 13:53:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIqcJ21191; Fri, 10 Jan 2003 13:52:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIoOJ21110 for ; Fri, 10 Jan 2003 13:50:24 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10413 for ; Fri, 10 Jan 2003 13:37:36 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h0AIexfm014604; Fri, 10 Jan 2003 10:40:59 -0800 (PST) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADA89780; Fri, 10 Jan 2003 10:37:46 -0800 (PST) Message-ID: <3E1F13B3.FE3FE749@cisco.com> Date: Fri, 10 Jan 2003 10:40:51 -0800 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Out of order TCP traffic on the Internet Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Are there any studies that have measured or attempted to measure the percentage of out-of-order TCP traffic on the Internet? Similar to the studies that folks have done on fragmented IP traffic in the Internet, admittedly it is much more difficult to measure the former. Thanks, Murali _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 10 18:01:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19298 for ; Fri, 10 Jan 2003 18:01:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ANE3405101 for tsvwg-archive@odin.ietf.org; Fri, 10 Jan 2003 18:14:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ANDLJ05084; Fri, 10 Jan 2003 18:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJnxJ24753 for ; Fri, 10 Jan 2003 14:49:59 -0500 Received: from zcamail04.zca.compaq.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13675 for ; Fri, 10 Jan 2003 14:37:09 -0500 (EST) Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.105.250.119]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id C394A271C; Fri, 10 Jan 2003 11:40:26 -0800 (PST) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.244]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 10 Jan 2003 11:40:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Out of order TCP traffic on the Internet Date: Fri, 10 Jan 2003 13:40:25 -0600 Message-ID: <717252EC3E37AE4392E2614EA24E9F2B03EF3FEB@txnexc01.americas.cpqcorp.net> Thread-Topic: [Tsvwg] Out of order TCP traffic on the Internet Thread-Index: AcK43p8RfksitYUpTJWyEB0JMVDCzQAAIlNg From: "Teisberg, Robert" To: "Murali Bashyam" , X-OriginalArrivalTime: 10 Jan 2003 19:40:26.0555 (UTC) FILETIME=[1FCDA0B0:01C2B8E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0AJnxJ24754 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here's one (from the abstract: "We have found, however, that parallelism in Internet components and links is causing packet reordering under normal operation and that the incidence of packet reordering appears to be substantially higher than previously reported"): IEEE/ACM Transactions on Networking (TON) Volume 7, Issue 6 (December 1999) Packet reordering is not pathological network behavior Authors Jon C. R. Bennett Harvard Univ., Cambridge, MA Craig Partridge BBN Technologies, Cambridge, MA Nicholas Shectman BBN Technologies, Cambridge, MA Publisher ACM Press New York, NY, USA Pages: 789 - 798 Periodical-Issue-Article Year of Publication: 1999 ISSN:1063-6692 > -----Original Message----- > From: Murali Bashyam [mailto:mbashyam@cisco.com] > Sent: Friday, January 10, 2003 12:41 PM > To: tsvwg@ietf.org > Subject: [Tsvwg] Out of order TCP traffic on the Internet > > > Hi > > Are there any studies that have measured or attempted to measure the > percentage of out-of-order TCP traffic on the Internet? > Similar to the > studies that folks have done on fragmented IP traffic in the Internet, > admittedly it is much more difficult to measure the former. > > Thanks, > Murali > > _______________________________________________ > 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 mailnull@www1.ietf.org Sat Jan 11 15:53:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17991 for ; Sat, 11 Jan 2003 15:53:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BL6GD10922 for tsvwg-archive@odin.ietf.org; Sat, 11 Jan 2003 16:06:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BL5CJ10865; Sat, 11 Jan 2003 16:05:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BKw0J10704 for ; Sat, 11 Jan 2003 15:58:00 -0500 Received: from vulture.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17873 for ; Sat, 11 Jan 2003 15:44:39 -0500 (EST) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.12.3/8.12.3) with ESMTP id h0BKlqU2065116; Sat, 11 Jan 2003 12:47:53 -0800 (PST) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ICIR To: "Andrei Gurtov" cc: tsvwg@ietf.org, "Sally Floyd" Subject: Re: [Tsvwg] Is a TFRC sender allowed to increase the send rate more than twice? In-reply-to: Your message of "Fri, 10 Jan 2003 11:47:46 +0200." <005d01c2b88d$5471f850$2f25b183@gurtoannb2> Date: Sat, 11 Jan 2003 12:47:52 -0800 Message-ID: <65115.1042318072@vulture.icir.org> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Hi, > >In draft-ietf-tsvwg-tfrc-05.txt on p. 11 a TFRC sender computes its send >rate as > >If (p > 0) > Calculate X_calc using the TCP throughput equation. > X = max(min(X_calc, 2*X_recv), s/t_mbi); > >when there are some losses detected. A question is, when X_recv and X_calc >suddenly increase, is the sender allowed to increase its transmission rate X >more than twice? Such situation could appear when a number of delayed or >reordered packets show up at the receiver causing the loss rate become low >and the receive rate higher than the current transmit rate. Alternatively, >the receiver or PEP having good knowledge of the bottleneck link could >adjust the loss rate and X_recv in feedback packets to make the sender adapt >faster to significant changes in available bandwidth. Yet another >possibility is a spoofing attack doing the same. > >According to the equation above more than twofold increase of the send rate >is ok, but the NS implementation clamps the send rate increase at twice the >current in all cases. In practice, I believe the difference has no effect on behaviour. - During slowstart, the send rate increase is capped to twice the send rate explicitly. - During normal operation, the normal increase rate due to the expiry of old higher-loss history is (from memory) about 0.12 packets per RTT. Thus to double the sending rate would take about 6 RTTs. It seems rate unlikely that any bunching would cause more than 6 RTTs of packets to arrive at once without having previously causing the receiver to signal the sender to reduce rate because the receive rate was so low while the packets were being delayed. - If history discounting has cut in, the 6 RTTs above would be 3 RTTs, but delaying of 3 RTTs of traffic would still likely trigger the receiver to clamp the senders rate to twice the (very low) receive rate before the delayed traffic arrives. Limiting the send rate to twice the receive rate is a safety measure that prevents serious overshoot on links with low levels of statistical multiplexing. In the case where you can delay several RTTs worth of packets without losing any, and then deliver them all in a high-rate burst, it seems rather likely that the level of statistical multiplexing isn't all that low, so this additional safety mechanism isn't required. In the worst and very unlikely case, you take some losses in the next RTT and slow down again pretty quickly. So, to summarise, restricting the increase to twice the send rate (as ns does) is a reasonable thing to do, but not doing it is very unlikely to have any significant effect, and even less likely to have any significant adverse effect. Does this answer your question? Cheers, Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 13 07:01:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09014 for ; Mon, 13 Jan 2003 07:01:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DCFBT19416 for tsvwg-archive@odin.ietf.org; Mon, 13 Jan 2003 07:15:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DCEDJ19371; Mon, 13 Jan 2003 07:14:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DCCvJ19313 for ; Mon, 13 Jan 2003 07:12:57 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08944 for ; Mon, 13 Jan 2003 06:58:49 -0500 (EST) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa07170; 13 Jan 2003 07:01 EST Date: Mon, 13 Jan 2003 07:01:13 -0500 (EST) From: Sourabh Ladha To: tsvwg@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu In-Reply-To: <3E1F13B3.FE3FE749@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] TCP-sack implementations Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, I have been searching for freebsd- tcp-sack implementations. Could anyone please direct me to some of the implementations other than Luigi Rizzo's . Thanks Sourabh _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 13 07:37:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09530 for ; Mon, 13 Jan 2003 07:37:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DCpOE21552 for tsvwg-archive@odin.ietf.org; Mon, 13 Jan 2003 07:51:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DCoEJ21498; Mon, 13 Jan 2003 07:50:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DCnvJ21468 for ; Mon, 13 Jan 2003 07:49:57 -0500 Received: from mail.tlc.polito.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09516 for ; Mon, 13 Jan 2003 07:35:46 -0500 (EST) Received: from tstat.tlc.polito.it (IDENT:AgbkhtgqgWjQszcwCaF34WG6W2GMFOL4@verza.polito.it [130.192.9.150]) by mail.tlc.polito.it (8.11.6/8.11.6) with ESMTP id h0DCctf07539; Mon, 13 Jan 2003 13:38:56 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Marco Mellia Reply-To: mellia@prezzemolo.polito.it Organization: Politecnico di Torino To: Murali Bashyam , tsvwg@ietf.org Subject: Re: [Tsvwg] Out of order TCP traffic on the Internet Date: Mon, 13 Jan 2003 13:38:55 +0100 User-Agent: KMail/1.4.3 References: <3E1F13B3.FE3FE749@cisco.com> In-Reply-To: <3E1F13B3.FE3FE749@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200301131338.55636.mellia@mail.tlc.polito.it> X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.7, required 5.5, AWL, IN_REP_TO, NOSPAM_INC, ORDER_STATUS, QUOTED_EMAIL_TEXT, REFERENCES, SIGNATURE_LONG_SPARSE, SPAM_PHRASE_01_02, USER_AGENT, USER_AGENT_KMAIL) Content-Transfer-Encoding: 8bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We have done some measurement, and about 3/4% of TCP connections seems to suffer from packet reordering. For more details, M. Mellia, A. Carpani, R. Lo Cigno Measuring IP and TCP behavior on Edge Nodes IEEE Globecom 2002 Taipei, TW, November 17-21 > Are there any studies that have measured or attempted to measure the > percentage of out-of-order TCP traffic on the Internet? Similar to the > studies that folks have done on fragmented IP traffic in the Internet, > admittedly it is much more difficult to measure the former. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Tel: 39-011-5644173 | | Cel: 39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www1.tlc.polito.it/mellia | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 13 19:18:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29224 for ; Mon, 13 Jan 2003 19:18:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E0W3l02488 for tsvwg-archive@odin.ietf.org; Mon, 13 Jan 2003 19:32:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E0RbJ02347; Mon, 13 Jan 2003 19:27:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E0QnJ02306 for ; Mon, 13 Jan 2003 19:26:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29129; Mon, 13 Jan 2003 19:12:26 -0500 (EST) Message-Id: <200301140012.TAA29129@ietf.org> To: IETF-Announce: ; Cc: tsvwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 13 Jan 2003 19:12:26 -0500 Subject: [Tsvwg] Last Call: A Conservative SACK-based Loss Recovery Algorithm for TCP to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Transport Area Working Group to consider 'A Conservative SACK-based Loss Recovery Algorithm for TCP' as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-13. Files can be obtained via http://www.ietf.org/internet-drafts/draft-allman-tcp-sack-13.txt _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 13 20:00:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00255 for ; Mon, 13 Jan 2003 20:00:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E1EJl05343 for tsvwg-archive@odin.ietf.org; Mon, 13 Jan 2003 20:14:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E1DsJ05329; Mon, 13 Jan 2003 20:13:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0D95KJ05686 for ; Mon, 13 Jan 2003 04:05:20 -0500 Received: from smtp.dave.sonera.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04700 for ; Mon, 13 Jan 2003 03:51:15 -0500 (EST) Received: from gurtoan1-nb2.etela.sonera.fi ([131.177.37.47]:1273 "HELO gurtoannb2") by inside.dave.sonera.fi with SMTP id ; Mon, 13 Jan 2003 10:54:31 +0200 Message-ID: <007b01c2bae1$6a406c10$2f25b183@gurtoannb2> From: "Andrei Gurtov" To: "Mark Handley" Cc: , "Sally Floyd" References: <65115.1042318072@vulture.icir.org> Subject: Re: [Tsvwg] Is a TFRC sender allowed to increase the send rate more than twice? Date: Mon, 13 Jan 2003 10:54:42 +0200 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > >Hi, > > > >In draft-ietf-tsvwg-tfrc-05.txt on p. 11 a TFRC sender computes its send > >rate as > > > >If (p > 0) > > Calculate X_calc using the TCP throughput equation. > > X = max(min(X_calc, 2*X_recv), s/t_mbi); > > > >when there are some losses detected. A question is, when X_recv and X_calc > >suddenly increase, is the sender allowed to increase its transmission rate X > >more than twice? Such situation could appear when a number of delayed or > >reordered packets show up at the receiver causing the loss rate become low > >and the receive rate higher than the current transmit rate. Alternatively, > >the receiver or PEP having good knowledge of the bottleneck link could > >adjust the loss rate and X_recv in feedback packets to make the sender adapt > >faster to significant changes in available bandwidth. Yet another > >possibility is a spoofing attack doing the same. > > > >According to the equation above more than twofold increase of the send rate > >is ok, but the NS implementation clamps the send rate increase at twice the > >current in all cases. > > In practice, I believe the difference has no effect on behaviour. > > - During slowstart, the send rate increase is capped to twice the > send rate explicitly. > > - During normal operation, the normal increase rate due to the expiry > of old higher-loss history is (from memory) about 0.12 packets per > RTT. Thus to double the sending rate would take about 6 RTTs. It > seems rate unlikely that any bunching would cause more than 6 > RTTs of packets to arrive at once without having previously causing > the receiver to signal the sender to reduce rate because the > receive rate was so low while the packets were being delayed. > > - If history discounting has cut in, the 6 RTTs above would be 3 > RTTs, but delaying of 3 RTTs of traffic would still likely trigger > the receiver to clamp the senders rate to twice the (very low) receive > rate before the delayed traffic arrives. > > Limiting the send rate to twice the receive rate is a safety measure > that prevents serious overshoot on links with low levels of > statistical multiplexing. In the case where you can delay several > RTTs worth of packets without losing any, and then deliver them all in > a high-rate burst, it seems rather likely that the level of > statistical multiplexing isn't all that low, so this additional safety > mechanism isn't required. In the worst and very unlikely case, you > take some losses in the next RTT and slow down again pretty quickly. > > So, to summarise, restricting the increase to twice the send rate (as > ns does) is a reasonable thing to do, but not doing it is very > unlikely to have any significant effect, and even less likely to have > any significant adverse effect. > > Does this answer your question? Thank you, this answers the first part of the question. I do think that links with delays and with low level of statistical multiplexing exist. For example GPRS has a dedicated buffer per user and has delay spikes of x10 RTT due to handovers. My own interest in asking this question is a possibility to explicitly control the rate of the TFRC sender from the receiver or from the network. Currently it takes more than 1 min for TFRC to reach the full rate after a handover from GPRS to UMTS. It seems that some push to the TFRC sender is needed to make it transmit at the full rate faster. My guess is that one leap change in transmission rate is preferrable by applications than many small incremental changes. After a handover the receiver can set X_rcv to the new link's rate and p to some small none-zero value which will cause the TFRC sender to send at the higher rate immediately. Of couse this shouldn't be used to the sender over the shared Internet, but for servers connected by LAN it seems quite appropriate. Now that I'm certain that this is supported by specs, I can go on with experiments. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 15 13:25:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05907 for ; Wed, 15 Jan 2003 13:25:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FIe6q00307 for tsvwg-archive@odin.ietf.org; Wed, 15 Jan 2003 13:40:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIdnJ32697; Wed, 15 Jan 2003 13:39:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIb3J31959 for ; Wed, 15 Jan 2003 13:37:03 -0500 Received: from web8205.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05715 for ; Wed, 15 Jan 2003 13:21:48 -0500 (EST) Message-ID: <20030115182508.553.qmail@web8205.mail.in.yahoo.com> Received: from [61.1.106.78] by web8205.mail.in.yahoo.com via HTTP; Wed, 15 Jan 2003 18:25:08 GMT Date: Wed, 15 Jan 2003 18:25:08 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: lksctp developers , Sigtran , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] SS7 signal Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hello everyone, we are a group of 3 students from pune institute of computer technology,pune ,india. we are doing a project on SS7. for that we want to know how the SS7 signals look? Though we`ve read many tutorials from net and also read a book on SS7 by travis russel but still could not get the exact details of the SS7 signals ( especially Message Signal Units). My exact doubt is how does SS7 signals look exactly on a SS7 link? Can someone send us the message which are practically extracted from SS7 link as we do not have access to SS7 link and give us the details of the message? or else can someone give the signals which might be used for demo purpose like some signal xxxxxxxxxxx for call establishment , xxxxxx..xx for canceling a call and so on. plz do reply. thank you. amit. ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 15 14:04:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06747 for ; Wed, 15 Jan 2003 14:04:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FJJWv02515 for tsvwg-archive@odin.ietf.org; Wed, 15 Jan 2003 14:19:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJIAJ02485; Wed, 15 Jan 2003 14:18:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFo7J19277 for ; Wed, 15 Jan 2003 10:50:07 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00170; Wed, 15 Jan 2003 10:34:52 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0FFcCKV029914; Wed, 15 Jan 2003 16:38:12 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 15 Jan 2003 16:38:12 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Cc: "'sigtran@ietf.org'" , "'tsvwg@ietf.org'" , "Allison Mankin (E-mail)" Date: Wed, 15 Jan 2003 16:38:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] Removing SCTP header compression from the ROHC charter Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , ROHCers (cc sigtran & tsvwg), The current ROHC WG charter has SCTP header compression listed as one of our work items. When this item was added, activity within the ROHC WG was high, and the addition was made as a prediction of future expectations rather than an outcome of well justified immediate requirements. Trying to fulfill this work item during the last year, we have repeatedly asked for contributions to SCTP header compression, but we have not received a single response. Given that this work item was originally added without immediate market pull, and considering the lack of current interest in doing the work (or even having it done at all), we intend to remove SCTP header compression from the ROHC WG charter. To keep it in the charter, justifications for developing SCTP header compression now would have to be presented, as well as industry support and commitments for doing the actual work. Barring further input, we will send a request to the ADs by Jan 24, so please reply before this date if you believe SCTP header compression should be on the agenda now. /Lars-Erik & Carsten _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 16 08:03:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08673 for ; Thu, 16 Jan 2003 08:03:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GDIsJ19709 for tsvwg-archive@odin.ietf.org; Thu, 16 Jan 2003 08:18:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDHgJ19555; Thu, 16 Jan 2003 08:17:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3w5J05633 for ; Wed, 15 Jan 2003 22:58:05 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19945; Wed, 15 Jan 2003 22:42:35 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h0G3jtv29572; Thu, 16 Jan 2003 09:15:55 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:15:49 +0530 Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-k1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 Jan 2003 09:15:49 +0530 Received: from wslexch.nortel-k1.wipro.com ([192.219.223.59]) by blr-k1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 Jan 2003 09:15:49 +0530 Received: by wslexch.nortel-k1.wipro.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 09:29:54 +0530 Message-ID: <96EEAF0DC507D6118AB60000E2293D1F01A69CF4@wslexch.nortel-k1.wipro.com> From: Anil Kumar To: amit somani , lksctp developers , Sigtran , tsvwg@ietf.org Date: Thu, 16 Jan 2003 09:29:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2BD13.B9B30260" X-OriginalArrivalTime: 16 Jan 2003 03:45:49.0632 (UTC) FILETIME=[C2934400:01C2BD11] Subject: [Tsvwg] RE: [Sigtran] SS7 signal Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , 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_01C2BD13.B9B30260 Content-Type: text/plain I hope this will help, if not, please let me know ... - Anil.V <> > -----Original Message----- > From: amit somani [SMTP:amitksomani@yahoo.co.in] > Sent: Wednesday, January 15, 2003 11:55 PM > To: lksctp developers; Sigtran; tsvwg@ietf.org > Subject: [Sigtran] SS7 signal > > hello everyone, > we are a group of 3 students from pune institute of > computer technology,pune ,india. we are doing a > project on SS7. for that we want to know how the SS7 > signals look? Though we`ve read many tutorials from > net and also read a book on SS7 by travis russel but > still could not get the exact details of the SS7 > signals ( especially Message Signal Units). My exact > doubt is how does SS7 signals look exactly on a SS7 > link? > Can someone send us the message which are practically > extracted from SS7 link as we do not have access to > SS7 link and give us the details of the message? or > else can someone give the signals which might be used > for demo purpose like some signal xxxxxxxxxxx for call > establishment , xxxxxx..xx for canceling a call and so > on. > > plz do reply. > > thank you. > amit. > > ________________________________________________________________________ > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran ------_=_NextPart_000_01C2BD13.B9B30260 Content-Type: application/msword; name="ISUP_MSGS.doc" Content-Disposition: attachment; filename="ISUP_MSGS.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA EAAAKAAAAAEAAAD+////AAAAACUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWQAJBAAAABK/AAAAAAAAEAAAAAAABAAACAwAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA AAAJBBYALRgAAJE9AQCRPQEACAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAPYAAAAAAAAA9gAAAPYA AAAAAAAA9gAAAAAAAAD2AAAAAAAAAPYAAAAAAAAA9gAAABQAAAAAAAAAAAAAAAoBAAAAAAAACgEA AAAAAAAKAQAAAAAAAAoBAAAAAAAACgEAAAwAAAAWAQAAFAAAAAoBAAAAAAAAqwIAAC4BAAA2AQAA AAAAADYBAAAAAAAANgEAAAAAAAA2AQAAAAAAADYBAAAAAAAANgEAAAAAAAA2AQAAAAAAADYBAAAA AAAAcAIAAAIAAAByAgAAAAAAAHICAAAAAAAAcgIAAAAAAAByAgAAAAAAAHICAAAAAAAAcgIAACQA AADZAwAA9AEAAM0FAACsAAAAlgIAABUAAAAAAAAAAAAAAAAAAAAAAAAA9gAAAAAAAAA2AQAAAAAA AAAAAAAAAAAAAAAAAAAAAAA2AQAAAAAAADYBAAAAAAAANgEAAAAAAAA2AQAAAAAAAJYCAAAAAAAA uAEAAAAAAAD2AAAAAAAAAPYAAAAAAAAANgEAAAAAAAAAAAAAAAAAADYBAAAAAAAANgEAAAAAAAC4 AQAAAAAAALgBAAAAAAAAuAEAAAAAAAA2AQAAAAAAAPYAAAAAAAAANgEAAAAAAAD2AAAAAAAAADYB AAAAAAAAcAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgEAAAAAAAAKAQAAAAAAAPYAAAAAAAAA9gAA AAAAAAD2AAAAAAAAAPYAAAAAAAAANgEAAAAAAABwAgAAAAAAALgBAAC4AAAAuAEAAAAAAAAAAAAA AAAAAHACAAAAAAAA9gAAAAAAAAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAIAAAAAAAA2AQAAAAAAACoBAAAMAAAAAEYH0Ei8 wgEKAQAAAAAAAAoBAAAAAAAANgEAAIIAAABwAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASVNV UCBNZXNzYWdlIHN0cnVjdHVyZSBjYXB0dXJlZCBvbiBTUzcgbGluay4NDQ1KVU4xOSAxNTo0Mjo1 NCAwNDAxIElORk8gSU5DT01JTkcgTElOSyBNU0cNQzcgSEVBREVSOiBMRU49NDcgTVNHPSMwMSBM SU5LPTIgU0xDPTAgQ0xMST1DN0xLU0VUMA1DNyBTSU86ICAgIE5FVFdPUks9IDAgICBQUklPUklU WT0gMCAgIFNFUlYgSU5EPSA1DUM3IExBQkVMOiBEUEMgPSBBTlNJNyAwMDAgMDAwIDAwMSAgT1BD ID0gQU5TSTcgMDAwIDAwMCAwMTggIFNMUyA9IDANUzcgREFUQSBGT0xMT1dJTkcgUk9VVElORyBM QUJFTDoNQ0EgMDAgMDEgMDAgNDggMDAgMDAgMDMgMDYgMEQgMDMgODAgOTAgQTIgMDcgMDMNMTAg MDUgODEgMzQgMzQgMTIgMEEgMDcgMDMgMTAgMDIgNTEgNTUgMjEgMjEgRUENMDEgMDAgRkUgMDIg MDAgMDAgMDANDUpVTjE5IDE1OjQyOjU1IDA1MDIgSU5GTyBPVVRHT0lORyBMSU5LIE1TRw1DNyBI RUFERVI6IExFTj0xOSBNU0c9IzA2IExJTks9MiBTTEM9MCBDTExJPUM3TEtTRVQwDUM3IFNJTzog ICAgTkVUV09SSz0gMCAgIFBSSU9SSVRZPSAyICAgU0VSViBJTkQ9IDUNQzcgTEFCRUw6ICBEUEMg PSBBTlNJNyAwMDAgMDAwIDAxOCAgT1BDID0gQU5TSTcgMDAwIDAwMCAwMDEgIFNMUyA9IDE4DVM3 IERBVEEgRk9MTE9XSU5HIFJPVVRJTkcgTEFCRUw6DUNBIDAwIDA2IDE0IEQxIDAxIEZEIDAyIDg0 IDAwIDAwDQ1KVU4xOSAxNTo0Mjo1NyAwNjAzIElORk8gT1VUR09JTkcgTElOSyBNU0cNQzcgSEVB REVSOiBMRU49MTIgTVNHPSMwOSBMSU5LPTIgU0xDPTAgQ0xMST1DN0xLU0VUMA1DNyBTSU86ICAg IE5FVFdPUks9IDAgICBQUklPUklUWT0gMiAgIFNFUlYgSU5EPSA1DUM3IExBQkVMOiAgRFBDID0g QU5TSTcgMDAwIDAwMCAwMTggIE9QQyA9IEFOU0k3IDAwMCAwMDAgMDAxICBTTFMgPSAxOA1TNyBE QVRBIEZPTExPV0lORyBST1VUSU5HIExBQkVMOg1DQSAwMCAwOSAwMA0NSlVOMTkgMTU6NDM6MjMg MTYwNCBJTkZPIE9VVEdPSU5HIExJTksgTVNHDUM3IEhFQURFUjogTEVOPTI2IE1TRz0jMEMgTElO Sz0yIFNMQz0wIENMTEk9QzdMS1NFVDANQzcgU0lPOiAgICBORVRXT1JLPSAwICAgUFJJT1JJVFk9 IDIgICBTRVJWIElORD0gNQ1DNyBMQUJFTDogIERQQyA9IEFOU0k3IDAwMCAwMDAgMDE4ICBPUEMg PSBBTlNJNyAwMDAgMDAwIDAwMSAgU0xTID0gMTgNUzcgREFUQSBGT0xMT1dJTkcgUk9VVElORyBM QUJFTDoNQ0EgMDAgMEMgMDIgMDQgMDIgODMgOUYgMUUgMDMgMDEgMDAgMDAgRkQgMDIgMDQNMDAg MDANDUpVTjE5IDE1OjQzOjI1IDE5MDYgSU5GTyBPVVRHT0lORyBMSU5LIE1TRw1DNyBIRUFERVI6 IExFTj0xMSBNU0c9IzEwIExJTks9MiBTTEM9MCBDTExJPUM3TEtTRVQwDUM3IFNJTzogICAgTkVU V09SSz0gMCAgIFBSSU9SSVRZPSAyICAgU0VSViBJTkQ9IDUNQzcgTEFCRUw6ICBEUEMgPSBBTlNJ NyAwMDAgMDAwIDAxOCAgT1BDID0gQU5TSTcgMDAwIDAwMCAwMDEgIFNMUyA9IDE4DVM3IERBVEEg Rk9MTE9XSU5HIFJPVVRJTkcgTEFCRUw6DUNBIDAwIDEwDQkNVGhlIG1lc3NhZ2Ugc3RhcnRzIHdp dGggdGhlIENJQyAoQ0EgMDAgPSAyMDIge3R3byBieXRlcyBhcmUgYmFja3dhcmRzfSkuIFRoZSBu ZXh0IGJ5dGUgaXMgdGhlIG1lc3NhZ2UgdHlwZTogMDEgPSBJbml0aWFsIEFkZHJlc3MgTWVzc2Fn ZSAoSUFNKSwgMDYgPSBBZGRyZXNzIENvbXBsZXRlIE1lc3NhZ2UgKEFDTSksIDA5ID0gQW5zd2Vy IE1lc3NhZ2UgKEFOTSksIDBDID0gUmVsZWFzZSBNZXNzYWdlIChSRUwpLCAxMCA9IFJlbGVhc2Ug Q29tcGxldGUgTWVzc2FnZSAoUkxDKS4gDU5leHQgd2Ugd2lsbCBpbnRlcmNlcHQgYSBtZXNzYWdl IHNvIHRoYXQgd2UgY2FuIGJ1aWxkIG9uZSBvZiBvdXIgb3duLiBMZXQncyBzYXkgd2Ugd2FudCB0 byBpbnRlcmNlcHQgdGhlIEFDTSBtZXNzYWdlLiANDQ0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAC0EAADx CQAAeAsAAAgMAAD3APAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADENKFgBPSgMAUUoDAAAPNQiBQ0oWAE9KAwBRSgMAAAQABAAALQQAAC4E AAAvBAAAWgQAAI8EAADBBAAABQUAACYFAABWBQAAhgUAAJsFAACcBQAAxwUAAPwFAAAuBgAAdAYA AJUGAAC2BgAAtwYAAOIGAAAXBwAASQcAAI8HAACwBwAAvAcAAL0HAADoBwAAHQgAAPgAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APMAAAAAAAAAAAAAAAAAAAAAAAAFDwANxgQBdiUABw8AD4TQAg3GBAF2JQAAHAAEAAAtBAAALgQA AC8EAABaBAAAjwQAAMEEAAAFBQAAJgUAAFYFAACGBQAAmwUAAJwFAADHBQAA/AUAAC4GAAB0BgAA lQYAALYGAAC3BgAA4gYAABcHAABJBwAAjwcAALAHAAC8BwAAvQcAAOgHAAAdCAAATwgAAJUIAAC2 CAAA5ggAAOwIAADtCAAAGAkAAE0JAAB/CQAAxQkAAOYJAADvCQAA8QkAAAMLAAB6CwAAewsAAHwL AAAIDAAA/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwIPAAAuHQgAAE8IAACVCAAA tggAAOYIAADsCAAA7QgAABgJAABNCQAAfwkAAMUJAADmCQAA7wkAAPEJAAADCwAAegsAAHsLAAB8 CwAACAwAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADAAADJAMFDwANxgQBdiUAABIrABIwABxQAQAfsNAv ILDgPSGwoAUisKAFI5CgBSSQoAUlsAAAF7CgBRiwoAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAEAAKAAEAWwAPAAIA AAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAEAG1ICQQAAAAAAAAAAAAAAAAA AAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYA bwBuAHQAAAAAAAAAAAAAAAAAYgD+bwEA8gBiAAAADABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAA ACgADwANxiMACwAAvwN+Bz0L/A67EnoWORr4HbchdiUAAAAAAAAAAAAAAA8AT0oEAFFKBABoCABu SAkEAAAAAAAICAAACAAAGAAABgD/////AAQAAAgMAAAIAAAAAAQAAB0IAAAIDAAACQAAAAsAAAAA BAAACAwAAAoAAAAAAAAAlQAAAKEAAADfAAAA5wAAAAICAAAOAgAANgIAADwCAAAdAwAAKQMAAFED AABXAwAAIwQAAC8EAABXBAAAXQQAAFMFAABfBQAAhwUAAI0FAAAKCAAABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA//8EAAAAAwBJAE0ARwAdAEMAOgBcAE0AeQAgAEQA bwBjAHUAbQBlAG4AdABzAFwASQBTAFUAUABfAE0AUwBHAFMALgBkAG8AYwADAEkATQBHADIAQwA6 AFwAVwBJAE4ARABPAFcAUwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA YQB2AGUAIABvAGYAIABJAFMAVQBQAF8ATQBTAEcAUwAuAGEAcwBkAP9AA4ABAAcIAAAHCAAAeKZ0 AAEAAQAHCAAAAAAAAHsHAAAAAAAAAhAAAAAAAAAACAgAAIAAAAgAQAAABQAAAEcWkAEAAAICBgMF BAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEA bgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAA ADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAA3JpAB AAACCwYEAwUEBAIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVgBlAHIAZABhAG4AYQAAAD81kAEA AAIHAwkCAgUCBAQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcA AAAiAAQAMQiIGAAA0AIAAGgBAAAAAEJ6cWZRenFmAAAAAAYABgAAACkBAACfBgAAAQADAAAABAAD EA4AAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAApQbAB7QAtACAADIwAAAAAAAAAAAAAAAAAAAhCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAA7 ADIANQAwAEYAIAAgACAAIAAgAEMANwBUAFUAMQAwADEAIABKAFUATgAxADkAIAAxADUAOgA0ADIA OgA1ADQAIAAwADQAMAAxACAASQBOAEYATwAgAEkATgBDAE8ATQBJAE4ARwAgAEwASQBOAEsAIABN AFMARwAAAAAAAAADAEkATQBHAAMASQBNAEcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACEAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAA1AAA AAQAAADgAAAABQAAAOwAAAAHAAAA+AAAAAgAAAAMAQAACQAAABgBAAASAAAAJAEAAAoAAABAAQAA DAAAAEwBAAANAAAAWAEAAA4AAABkAQAADwAAAGwBAAAQAAAAdAEAABMAAAB8AQAAAgAAAOQEAAAe AAAAPAAAADI1MEYgICAgIEM3VFUxMDEgSlVOMTkgMTU6NDI6NTQgMDQwMSBJTkZPIElOQ09NSU5H IExJTksgTVNHAB4AAAABAAAAADUwRh4AAAAEAAAASU1HAB4AAAABAAAAAE1HAB4AAAALAAAATm9y bWFsLmRvdABUHgAAAAQAAABJTUcAHgAAAAIAAAA2AEcAHgAAABMAAABNaWNyb3NvZnQgV29yZCA4 LjAATkAAAAAApJPWAAAAAEAAAAAAuKmpRrzCAUAAAAAA0hrCSLzCAQMAAAABAAAAAwAAACkBAAAD AAAAnwYAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALV zdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rmwBAAAoAQAADAAAAAEAAABoAAAADwAA AHAAAAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAA sAAAABYAAAC4AAAADQAAAMAAAAAMAAAACAEAAAIAAADkBAAAHgAAAAYAAAB3aXBybwAgAAMAAAAO AAAAAwAAAAMAAAADAAAAIQgAAAMAAABqEAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAQAAADwAAAAyNTBGICAgICBDN1RVMTAxIEpVTjE5IDE1OjQyOjU0IDA0MDEgSU5GTyBJ TkNPTUlORyBMSU5LIE1TRwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAJgAAAADAAAA AAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAA AE4AAAB7ADYAMwA2ADUAMQBFADAANgAtADIAOAA2ADgALQAxADEARAA3AC0AOABDAEIARAAtADAA MAAwADAARQAyADAARABDADcARgAzAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoA AAALAAAADAAAAP7///8OAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAA ABkAAAAaAAAAGwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7////9//// JwAAAP7////+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABG AAAAACDMrgtHvMIB4A4Y0Ei8wgEpAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAEAAAAAAAAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB BQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0YAAAA AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAVAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB0AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBjAHQA UABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAOAOGNBIvMIB4A4Y0Ei8wgEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJCeQAA6AQDwBwAAAAEAAAD+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQg V29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C2BD13.B9B30260-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu Jan 16 10:49:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14246 for ; Thu, 16 Jan 2003 10:49:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GG4LI32411 for tsvwg-archive@odin.ietf.org; Thu, 16 Jan 2003 11:04:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG2lJ32336; Thu, 16 Jan 2003 11:02:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFxKJ32127 for ; Thu, 16 Jan 2003 10:59:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14148 for ; Thu, 16 Jan 2003 10:43:38 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GFnCt02723 for ; Thu, 16 Jan 2003 17:49:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Jan 2003 17:46:59 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 17:47:00 +0200 Received: from there (sarolaht@hedhc04nrc041-120.research.nokia.com [172.21.41.120]) by mgw.research.nokia.com (8.9.3/8.9.3) with SMTP id RAA09763 for ; Thu, 16 Jan 2003 17:46:59 +0200 (EET) Message-Id: <200301161546.RAA09763@mgw.research.nokia.com> X-Authentication-Warning: mgw.research.nokia.com: Host sarolaht@hedhc04nrc041-120.research.nokia.com [172.21.41.120] claimed to be there Content-Type: text/plain; charset="iso-8859-1" From: Pasi Sarolahti Organization: Nokia Research Center To: tsvwg@ietf.org Date: Thu, 16 Jan 2003 17:46:59 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jan 2003 15:47:00.0080 (UTC) FILETIME=[81C5A700:01C2BD76] Content-Transfer-Encoding: 8bit Subject: [Tsvwg] Update on F-RTO draft Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, We submitted an update to F-RTO draft for dealing with spurious TCP retransmission timeouts. The draft can be found at http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-tcp-frto-03.txt Based on the feedback in Atlanta, the focus is now on detecting spurious RTO, and the response related text is taken out of the algorithm description, although possible response alternatives are discussed in the end of the draft. I'd like to have advise on how to proceed with the draft. Personally, I would like to see it become a tsvwg work item, which hopefully would attract a thorough review on it, and make its path towards experimental RFC easier. So I'm asking for input on would you approve it to become a WG item? If not, why not? Based on the earlier discussion on this list a few months ago, I got the feeling that generally folks were taking the idea of F-RTO quite positively, right? Btw, F-RTO is included as an option in Linux 2.5 TCP implementation, so the Linux users can try it out by installing some of the recent Linux kernel versions. I can also give a pointer to separate patch for anyone interested. - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 17 10:06:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24750 for ; Fri, 17 Jan 2003 10:06:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFMUP06543 for tsvwg-archive@odin.ietf.org; Fri, 17 Jan 2003 10:22:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFLkJ06496; Fri, 17 Jan 2003 10:21:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFKXJ06410 for ; Fri, 17 Jan 2003 10:20:33 -0500 Received: from web8206.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24651 for ; Fri, 17 Jan 2003 10:04:23 -0500 (EST) Message-ID: <20030117150745.19805.qmail@web8206.mail.in.yahoo.com> Received: from [203.123.167.157] by web8206.mail.in.yahoo.com via HTTP; Fri, 17 Jan 2003 15:07:45 GMT Date: Fri, 17 Jan 2003 15:07:45 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: Sigtran , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] (no subject) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all! we r a group of student from pune institute of computer technology,pune,india. we r working on ss7 as our final year project. i've some basic questions 1. is it possible to have ss7 signal on a EPABX? does telephone exchange provides it? 2. if possible then will it be possible that we can get those ss7 signals on computer by inserting some kind of card in ISA slot. 3. are such kind of cards available ? 4. how much such card will cost? 5. what kind of hardware is used at exchange to deal with ss7 signals? 6. is there any kind of software tool available which will simulate/ generate ss7 signals as actual. if u've any material available will u please mail it. thank u. anup ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 17 10:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25050 for ; Fri, 17 Jan 2003 10:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFP9B06851 for tsvwg-archive@odin.ietf.org; Fri, 17 Jan 2003 10:25:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFOlJ06741; Fri, 17 Jan 2003 10:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFMJJ06533 for ; Fri, 17 Jan 2003 10:22:19 -0500 Received: from web8204.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24738 for ; Fri, 17 Jan 2003 10:06:08 -0500 (EST) Message-ID: <20030117150930.28891.qmail@web8204.mail.in.yahoo.com> Received: from [203.123.167.157] by web8204.mail.in.yahoo.com via HTTP; Fri, 17 Jan 2003 15:09:30 GMT Date: Fri, 17 Jan 2003 15:09:30 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: Sigtran , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] (no subject) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all! we r a group of student from pune institute of computer technology,pune,india. we r working on ss7 as our final year project. i've some basic questions 1. is it possible to have ss7 signal on a EPABX? does telephone exchange provides it? 2. if possible then will it be possible that we can get those ss7 signals on computer by inserting some kind of card in ISA slot. 3. are such kind of cards available ? 4. how much such card will cost? 5. what kind of hardware is used at exchange to deal with ss7 signals? 6. is there any kind of software tool available which will simulate/ generate ss7 signals as actual. if u've any material available will u please mail it. thank u. amit ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 17 10:09:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25169 for ; Fri, 17 Jan 2003 10:09:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFPX106890 for tsvwg-archive@odin.ietf.org; Fri, 17 Jan 2003 10:25:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFP4J06809; Fri, 17 Jan 2003 10:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFNNJ06646 for ; Fri, 17 Jan 2003 10:23:23 -0500 Received: from web8201.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24793 for ; Fri, 17 Jan 2003 10:07:12 -0500 (EST) Message-ID: <20030117151034.50999.qmail@web8201.mail.in.yahoo.com> Received: from [203.123.167.157] by web8201.mail.in.yahoo.com via HTTP; Fri, 17 Jan 2003 15:10:34 GMT Date: Fri, 17 Jan 2003 15:10:34 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: Sigtran , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] (no subject) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all! we r a group of student from pune institute of computer technology,pune,india. we r working on ss7 as our final year project. i've some basic questions 1. is it possible to have ss7 signal on a EPABX? does telephone exchange provides it? 2. if possible then will it be possible that we can get those ss7 signals on computer by inserting some kind of card in ISA slot. 3. are such kind of cards available ? 4. how much such card will cost? 5. what kind of hardware is used at exchange to deal with ss7 signals? 6. is there any kind of software tool available which will simulate/ generate ss7 signals as actual. if u've any material available will u please mail it. thank u. amit ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 17 10:32:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26115 for ; Fri, 17 Jan 2003 10:32:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFm5t08733 for tsvwg-archive@odin.ietf.org; Fri, 17 Jan 2003 10:48:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFlgJ08640; Fri, 17 Jan 2003 10:47:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFj0J08399 for ; Fri, 17 Jan 2003 10:45:00 -0500 Received: from web8206.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25843 for ; Fri, 17 Jan 2003 10:28:46 -0500 (EST) Message-ID: <20030117153207.5184.qmail@web8206.mail.in.yahoo.com> Received: from [203.123.167.157] by web8206.mail.in.yahoo.com via HTTP; Fri, 17 Jan 2003 15:32:07 GMT Date: Fri, 17 Jan 2003 15:32:07 +0000 (GMT) From: =?iso-8859-1?q?amit=20somani?= To: Sigtran , tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Tsvwg] query regarding ss7 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all! we r a group of student from pune institute of computer technology,pune,india. we r working on ss7 as our final year project. i've some basic questions 1. is it possible to have ss7 signal on a EPABX? does telephone exchange provides it? 2. if possible then will it be possible that we can get those ss7 signals on computer by inserting some kind of card in ISA slot. 3. are such kind of cards available ? 4. how much such card will cost? 5. what kind of hardware is used at exchange to deal with ss7 signals? 6. is there any kind of software tool available which will simulate/ generate ss7 signals as actual. if u've any material available will u please mail it. thank u. amit ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jan 21 10:53:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03210 for ; Tue, 21 Jan 2003 10:53:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LGB3w27852 for tsvwg-archive@odin.ietf.org; Tue, 21 Jan 2003 11:11:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LG9vJ27728; Tue, 21 Jan 2003 11:09:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LG8TJ27655 for ; Tue, 21 Jan 2003 11:08:29 -0500 Received: from zippy.psc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03089 for ; Tue, 21 Jan 2003 10:50:23 -0500 (EST) Received: from localhost (mathis@localhost) by zippy.psc.edu (8.11.6/8.11.6) with ESMTP id h0LGrnE16672; Tue, 21 Jan 2003 11:53:49 -0500 X-Authentication-Warning: zippy.psc.edu: mathis owned process doing -bs Date: Tue, 21 Jan 2003 11:53:49 -0500 (EST) From: Matt Mathis To: Transport Area WG , IPv6 MIB team cc: "Peter O'Neil" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] TCP ESTATS design team Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , We are in the process of assembling a design team to update the TCP extended statistics MIB, draft-ietf-tsvwg-tcp-mib-extension-01.txt. If you would like to help with this effort please send a note to Peter O'Neil or me. The extended statistics MIB will endow TCP with substantial diagnostic capabilities. We will have a new draft for review by the TSVWG in time for the ID cutoff. This draft will incorporate the detailed per connection statistics from the web100 project and the good transport work that was done by the IPv6 team and later determined to be out of scope. The IPv6 team is finishing up update to rfc2012. Our document will be an extension to it. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jan 21 16:27:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12437 for ; Tue, 21 Jan 2003 16:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLikK18636 for tsvwg-archive@odin.ietf.org; Tue, 21 Jan 2003 16:44:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLgXJ18543; Tue, 21 Jan 2003 16:42:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLf4J18507 for ; Tue, 21 Jan 2003 16:41:04 -0500 Received: from cougar.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12362 for ; Tue, 21 Jan 2003 16:22:50 -0500 (EST) Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.3/8.12.3) with ESMTP id h0LLQEgn045649; Tue, 21 Jan 2003 13:26:15 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200301212126.h0LLQEgn045649@cougar.icir.org> To: "Andrei Gurtov" cc: tsvwg@ietf.org, "Sally Floyd" From: Sally Floyd Subject: Re: [Tsvwg] Is a TFRC sender allowed to increase the send rate more than twice? Date: Tue, 21 Jan 2003 13:26:14 -0800 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Andrei - >After a handover the receiver can set X_rcv to the new link's rate and p to >some small none-zero value which will cause the TFRC sender to send at the >higher rate immediately. >Of couse this shouldn't be used to the sender over the shared Internet, but >for servers connected by LAN it seems quite appropriate. It would be good to have additional mechanisms in place to ensure that something like this would *only* be used for servers connected by a LAN, with no competing traffic on the LAN, and would not be used over the shared Internet... (Apologies for the late reply.) - Sally _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue Jan 21 17:46:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14432 for ; Tue, 21 Jan 2003 17:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LN3vO23479 for tsvwg-archive@odin.ietf.org; Tue, 21 Jan 2003 18:03:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LN2VJ23447; Tue, 21 Jan 2003 18:02:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LN1TJ23404 for ; Tue, 21 Jan 2003 18:01:29 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14369 for ; Tue, 21 Jan 2003 17:43:14 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0LMkZOD009746; Tue, 21 Jan 2003 15:46:35 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA21115; Tue, 21 Jan 2003 15:46:35 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id h0LMgrf14221; Tue, 21 Jan 2003 16:42:53 -0600 (CST) Received: from Motorola.com (d41-3177.cig.mot.com [160.48.49.119]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA26588; Tue, 21 Jan 2003 16:44:32 -0600 (CST) Message-ID: <3E2DCD64.C73BF2B4@Motorola.com> Date: Tue, 21 Jan 2003 16:44:52 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Williams, Jim" CC: "'Randall Stewart'" , tsvwg@ietf.org Subject: Re: [Tsvwg] Concerns about SCTP References: <3356669BBE90C448AD4645C843E2BF289B8FA8@xbl.ma.emulex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ... > If one views it from a system perspective, a user may > be running a file system over RDDP over SCTP. If the > file system fails to mount, the user would regard this > a failure to interoperate. However this failure can > be prevented in multiple ways. > > 1. At the RDDP over SCTP adaption layer, specify that > if an endpoint specifies multiple IP addresses and > the association setup is aborted with a resource error, > the endpoint MUST retry the association with fewer > IP addresses. (The draft could also remain silent > on this and trust the good sense of the upper layers > to do this anyway, but that seems like asking > for interoperability woes unnecessarily.) As you indicated above that you are essentially talking about system level inter-operability (ie. what a user may see), "the good sense of the upper layers" is not only desirable, but is fundamental. One can not expect system level inter-operability without "the good sense" in system engineering at all the layers. > > Although this works, I regard it as more of a > work around than a well designed negotiation. > An example of a well designed negotiation is > the mechanism use by SCTP to determine the number > of streams per association. As a matter of fact, the SCTP design team had discussion on this and deliberately choose to use *minimal negotiation* at the association setup. The reason is that, nothing comes free and lower setup latency was considered more important to most applications. Moreover, the stream negotiation mechanism (that you seem to agree with) also need "the good sense of the upper layers" to work well - e.g., the initiator side's upper layer will need to allow its SCTP stack to re-try with a lowered number of outbound streams. -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed Jan 22 19:43:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12679 for ; Wed, 22 Jan 2003 19:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N11YQ01354 for tsvwg-archive@odin.ietf.org; Wed, 22 Jan 2003 20:01:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N112J01296; Wed, 22 Jan 2003 20:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N0x7J01179 for ; Wed, 22 Jan 2003 19:59:07 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12622 for ; Wed, 22 Jan 2003 19:40:19 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0N0hjHI020346; Wed, 22 Jan 2003 17:43:45 -0700 (MST) Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA13871; Wed, 22 Jan 2003 17:42:53 -0700 (MST)] Received: from quantix20.cig.mot.com (quantix20 [160.47.58.31]) by relay1.cig.mot.com (8.11.4/8.11.4) with ESMTP id h0N0hff18609; Wed, 22 Jan 2003 18:43:41 -0600 (CST) Received: from Motorola.com (d50-384a.cig.mot.com [160.47.56.74]) by quantix20.cig.mot.com (8.8.8+Sun/8.8.8) with ESMTP id SAA27963; Wed, 22 Jan 2003 18:45:20 -0600 (CST) Message-ID: <3E2F3B12.EE694111@Motorola.com> Date: Wed, 22 Jan 2003 18:45:06 -0600 From: Qiaobing Xie X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Ivan.Arias-Rodriguez@nokia.com, sri@us.ibm.com, tsvwg@ietf.org Subject: Re: [Tsvwg] queries on draft-ietf-tsvwg-sctpimpguide-05.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Armando, "Armando L. Caro Jr." wrote: .... > > Originally, Max.Burst was applied only in the case of a SACK > > acknowledging fast retransmitted DATA Chunks. However, Max.Burst is > > now used always. Note that this is a modification to the general > > congestion control algorithm. > > Yes, this change was made to avoid bursts at any time. Max.Burst was left > as a parameter, because we don't really know what an acceptable burst > is... 4 was a reasonable number chosen earlier, so we stuck with it. Do you have a reference to any analysis/discussion on the impact of this change to the data throughput over a long, fat SCTP connection? (or similar analysis for long fat TCP connections). regards, -Qiaobing _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 24 09:31:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20656 for ; Fri, 24 Jan 2003 09:31:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OEon003028 for tsvwg-archive@odin.ietf.org; Fri, 24 Jan 2003 09:50:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OEktJ02838; Fri, 24 Jan 2003 09:46:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OAT3J18985 for ; Fri, 24 Jan 2003 05:29:03 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14750; Fri, 24 Jan 2003 05:09:34 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jan 2003 10:13:01 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F195@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Cc: "'sigtran@ietf.org'" , "'tsvwg@ietf.org'" , "Allison Mankin (E-mail)" Date: Fri, 24 Jan 2003 10:13:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] RE: [rohc] Removing SCTP header compression from the ROHC charter Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Trying to fulfill this work item during the last year, we have > repeatedly asked for contributions to SCTP header compression, but > we have not received a single response. We published a first version of an SCTP compression profile in draft-west-sctp-epic-00.txt. This draft is based on the formal header compression notation (see draft-ietf-rohc-formal-notation-00.txt), so we intend to update the SCTP draft once the formal notation draft is finalised. > Given that this work item was originally added without immediate > market pull, and considering the lack of current interest in doing > the work (or even having it done at all), we intend to remove SCTP > header compression from the ROHC WG charter. To keep it in the > charter, justifications for developing SCTP header compression now > would have to be presented, as well as industry support and > commitments for doing the actual work. This work item is important because, unlike for TCP, there is currently no published scheme for SCTP compression. This will hinder the deployment of SCTP, particularly in the mobile environment. Regarding the industry support, we're currently working on SCTP compression at the moment in the form of the notation draft. Once this work is done we'll publish an updated version of our SCTP profile. > Barring further input, we will send a request to the ADs by Jan 24, > so please reply before this date if you believe SCTP header > compression should be on the agenda now. I believe that SCTP compression should remain on the ROHC charter. Regards, Richard _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 24 12:02:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24966 for ; Fri, 24 Jan 2003 12:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHLkd14051 for tsvwg-archive@odin.ietf.org; Fri, 24 Jan 2003 12:21:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHKbJ14012; Fri, 24 Jan 2003 12:20:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHJXJ13949 for ; Fri, 24 Jan 2003 12:19:33 -0500 Received: from mail.eecis.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24895 for ; Fri, 24 Jan 2003 11:59:56 -0500 (EST) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa26243; 24 Jan 2003 12:02 EST Date: Fri, 24 Jan 2003 12:02:16 -0500 (EST) From: Janardhan Iyengar To: tsvwg@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu cc: "Armando L. Caro Jr." , Sourabh Ladha , keyur shah , "Paul D. Amer" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] TCP SACK/FACK implementations on BSD Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi all, We are doing some experiments using the OpenBSD implementation of TCP SACK and FACK. Could anyone validate for us whether these are the docs that these implementations conform to (or are closest to)? OpenBSD TCP-SACK: A Conservative SACK-based Loss Recovery Algorithm for TCP (draft-allman-tcp-sack-13.txt) OpenBSD TCP-FACK: SIGCOMM'96 Paper "Forward Acknowledgment: Refining TCP Congestion Control" If not, then which are the implementations available right now that do? Further, do the ns-2 implementations of TCP-SACK/FACK conform to the docs above? thanks and regards, jana/armando ----------------------------------------------------------------------- Janardhan R. Iyengar iyengar@cis.udel.edu University of Delaware http://www.cis.udel.edu/~iyengar ----------------------------------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 24 12:11:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25124 for ; Fri, 24 Jan 2003 12:11:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHUa314454 for tsvwg-archive@odin.ietf.org; Fri, 24 Jan 2003 12:30:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHU5J14424; Fri, 24 Jan 2003 12:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHT9J14378 for ; Fri, 24 Jan 2003 12:29:09 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25103 for ; Fri, 24 Jan 2003 12:09:32 -0500 (EST) Received: (from elb@localhost) by localhost.localdomain (8.11.6/8.11.6) id h0OHCnd21789; Fri, 24 Jan 2003 12:12:49 -0500 Date: Fri, 24 Jan 2003 12:12:49 -0500 From: Ethan Blanton To: Janardhan Iyengar Cc: tsvwg@ietf.org, "Armando L. Caro Jr." , Sourabh Ladha , keyur shah , "Paul D. Amer" Subject: Re: [Tsvwg] TCP SACK/FACK implementations on BSD Message-ID: <20030124171249.GA4853@paco.resnet.purdue.edu> Mail-Followup-To: Janardhan Iyengar , tsvwg@ietf.org, "Armando L. Caro Jr." , Sourabh Ladha , keyur shah , "Paul D. Amer" References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Janardhan Iyengar spake unto us the following wisdom: > We are doing some experiments using the OpenBSD implementation of TCP SACK > and FACK. Could anyone validate for us whether these are the docs that > these implementations conform to (or are closest to)? >=20 > OpenBSD TCP-SACK: A Conservative SACK-based Loss Recovery Algorithm for > TCP (draft-allman-tcp-sack-13.txt) We have not heard anything about the OpenBSD people trying to implement our algorithm. That doesn't preclude that they might have done so, but I suspect that their SACK support predates draft-allman-tcp-sack-13. > Further, do the ns-2 implementations of TCP-SACK/FACK conform to the docs > above? The ns-2 SACK algorithm is similar to draft-allman-tcp-sack-13 (and is in fact the basis we worked from), but it is not the same. Ethan --=20 And if I claim to be a wise man / it surely means that I don't know. -- Kansas, "Carry on Wayward Son" --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+MXQRr9kA9Ig8HBQRAoswAKCxmfOAw+muuJr5k2lc5nwJiAMBzwCfU01N Wd4cdl2r4w0K7HLHGl0o7t4= =2Ewd -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon Jan 27 15:13:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25206 for ; Mon, 27 Jan 2003 15:13:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RKYKc14824 for tsvwg-archive@odin.ietf.org; Mon, 27 Jan 2003 15:34:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKWwJ14767; Mon, 27 Jan 2003 15:32:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RKUfJ14643 for ; Mon, 27 Jan 2003 15:30:41 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25148; Mon, 27 Jan 2003 15:09:34 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h0RKD3D08806; Mon, 27 Jan 2003 12:13:03 -0800 (PST) Message-Id: <200301272013.h0RKD3D08806@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, tsvwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 27 Jan 2003 12:13:03 -0800 Subject: [Tsvwg] RFC 3448 on TFRC: Protocol Specification Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3448 Title: TCP Friendly Rate Control (TFRC): Protocol Specification Author(s): M. Handley, S. Floyd, J. Padhye, J. Widmer Status: Standards Track Date: January 2003 Mailbox: mjh@icir.org, floyd@icir.org, padhye@microsoft.com, widmer@informatik.uni-mannheim.de Pages: 24 Characters: 52657 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-tfrc-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3448.txt This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. This document is a product of the Transport Area Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030127121112.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3448 --OtherAccess Content-Type: Message/External-body; name="rfc3448.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030127121112.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 31 06:30:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03708 for ; Fri, 31 Jan 2003 06:30:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VBXlI19378 for tsvwg-archive@odin.ietf.org; Fri, 31 Jan 2003 06:33:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VBVhJ19318; Fri, 31 Jan 2003 06:31:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VBUqJ19274 for ; Fri, 31 Jan 2003 06:30:52 -0500 Received: from erg.abdn.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03663; Fri, 31 Jan 2003 06:26:52 -0500 (EST) Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.7/8.12.7) with ESMTP id h0VBUJt5013647; Fri, 31 Jan 2003 11:30:19 GMT Message-ID: <3E3A5E4D.9F47F886@erg.abdn.ac.uk> Date: Fri, 31 Jan 2003 11:30:20 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Michael Welzl CC: dccp@ietf.org, tsvwg@ietf.org References: <1044002049.1595.11.camel@lap10-c703.uibk.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: [dccp] DCCP and UDP Lite Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See in-line comments. Michael Welzl wrote: > > Hi everybody, > > I just noticed the following sentences in the DCCP specification > (page 11, section 5.1, "checksum length"): > > "The checksum length field specifies what parts of the packet > are covered by the checksum field. The checksum always covers > at least the DCCP header, DCCP options, and a pseudoheader taken > from the network-layer header (see below). If the checksum > length field is zero, that is all the checksum covers." > > The functionality of setting the checksum length field > to zero closely resembles the capability of UDP Lite to > receive erroneous payload packets and deliver them to the > application. The current rev of the ID (with IESG) for UDP-Lite is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-lite-01.txt This contains advice on this topic, that had not been previously been included in draft-00. There is nothing dangerous with the transport layer employing partial checksums providing: a) The checksum always protect the appropriate headers. b) It is the application that requests partial protection, it is not something that the transport layer decides to use/not use. > > I would say that: > > EITHER: > > - a comment should be included that states that erroneous > payload MUST NOT be delivered to the applications and may > only be used for congestion control purposes (or, possibly > better, the sentence about values other than 0 or 15 being > experimental should be changed to "values other than 15"). > > OR: > > - UDP Lite should be accepted upon acceptance of DCCP. > Option (1) declares this experimental. Option (2) Since UDP-Lite -01 is now with the IESG, awaiting AD action, UDP-Lite should be published soon. Perhaps then, we should look again at whether/how DCCP should follow this? > This has nothing to do with personal preference - it's just > similar functionality that caused a lot of discussions in > the case of UDP Lite ... > > Cheers, > Michael > > _______________________________________________ > dccp IETF mailing list: dccp@ietf.org > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 31 08:12:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05695 for ; Fri, 31 Jan 2003 08:12:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VDG0M24981 for tsvwg-archive@odin.ietf.org; Fri, 31 Jan 2003 08:16:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VDFOJ24956; Fri, 31 Jan 2003 08:15:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0V8XXJ09838 for ; Fri, 31 Jan 2003 03:33:33 -0500 Received: from smtp.uibk.ac.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01282; Fri, 31 Jan 2003 03:29:37 -0500 (EST) Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.7/8.12.7/F1) with ESMTP id h0V8XA2B005080; Fri, 31 Jan 2003 09:33:10 +0100 From: Michael Welzl To: dccp@ietf.org, tsvwg@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 31 Jan 2003 09:34:08 +0100 Message-Id: <1044002049.1595.11.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Spam-Score: 0.1 () SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.26 at uibk.ac.at (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [Tsvwg] DCCP and UDP Lite Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everybody, I just noticed the following sentences in the DCCP specification (page 11, section 5.1, "checksum length"): "The checksum length field specifies what parts of the packet are covered by the checksum field. The checksum always covers at least the DCCP header, DCCP options, and a pseudoheader taken from the network-layer header (see below). If the checksum length field is zero, that is all the checksum covers." The functionality of setting the checksum length field to zero closely resembles the capability of UDP Lite to receive erroneous payload packets and deliver them to the application. I would say that: EITHER: - a comment should be included that states that erroneous payload MUST NOT be delivered to the applications and may only be used for congestion control purposes (or, possibly better, the sentence about values other than 0 or 15 being experimental should be changed to "values other than 15"). OR: - UDP Lite should be accepted upon acceptance of DCCP. This has nothing to do with personal preference - it's just similar functionality that caused a lot of discussions in the case of UDP Lite ... Cheers, Michael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 31 12:14:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12439 for ; Fri, 31 Jan 2003 12:14:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VHIX607075 for tsvwg-archive@odin.ietf.org; Fri, 31 Jan 2003 12:18:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHGiJ06980; Fri, 31 Jan 2003 12:16:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHFOJ06935 for ; Fri, 31 Jan 2003 12:15:24 -0500 Received: from slepton.muonics.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12311 for ; Fri, 31 Jan 2003 12:11:16 -0500 (EST) Received: from localhost (localhost.muonics.com [127.0.0.1]) by slepton.muonics.com (8.12.4/8.12.4) with ESMTP id h0VHDPcH077009; Fri, 31 Jan 2003 09:13:25 -0800 (PST) Date: Fri, 31 Jan 2003 09:13:20 -0800 (PST) From: Michael Kirkham To: Matt Mathis cc: tsvwg@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] Re: TCP ESTATS design team Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I thought I'd take a quick look through the MIB and make a few comments. I assume this is a new MIB and not one that's currently deployed (given the 'experimental' branch placement and the MODULE-IDENTITY's only revision DESCRIPTION). If I'm wrong, feel free to ignore these comments as they aren't things that can be changed due to revision policy. 1. It is recommended (although not required) that objects with 'Counter' types (Counter32, Counter64) denote plurality by ending in 's'. Of the the objects in this MIB with 'Counter' types, several do denote plurality, although by ending in (for example) 'AcksOut' versus 'OutAcks', and many do not. You might consider reversing the suffix where plurality is denoted, and modifying the descriptors of those that don't denote plurality to do. There are quite a few, so for the sake of brevety I haven't listed them. 2. The indexing scheme of the various tables seems a little confusing to me. Most of the tables are indexed solely on tcpEStatsConnectIndex except, oddly enough, the table that actually defines tcpEStatsConnectIndex: tcpEStatsConnectIdEntry OBJECT-TYPE SYNTAX TcpEStatsConnectIdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Connection ID table." INDEX { tcpEStatsConnectLocalAddressType, tcpEStatsConnectLocalAddress, tcpEStatsConnectLocalPort, tcpEStatsConnectRemAddressType, tcpEStatsConnectRemAddress, tcpEStatsConnectRemPort } ::= { tcpEStatsConnectIdTable 1 } TcpEStatsConnectIdEntry ::= SEQUENCE { tcpEStatsConnectLocalAddressType InetAddressType, tcpEStatsConnectLocalAddress InetAddress, tcpEStatsConnectLocalPort InetPortNumber, tcpEStatsConnectRemAddressType InetAddressType, tcpEStatsConnectRemAddress InetAddress, tcpEStatsConnectRemPort InetPortNumber, tcpEStatsConnectIndex Integer32 } I'm guessing that the intent here was to make it easy to find the tcpEStatsConnectIndex values for a particular 'local' address by e.g. doing a get-next walk of tcpEStatsConnectIndex..
and because all but tcpEStatsConnectIndex are not-accessible (and at least one column of a table must be accessible). But I don't see that this provides much benefit to the other tables. Why not have the other tables indexed by the same objects if they are going to be indexed externally anyway? Or, perhaps better, have the tcpEStatsConnectIdEntry table map only a single type/address/port triplet per row, and use a pair of tcpEStatsConnectIndex values (one for each side of the connection) to index the other tables? That way you locate statistics from either vantage point, that way you could quickly locate statistics from either direction (what defines 'local' versus 'remote' in the context of this MIB?) Disadvantage: using this method to allow for statistics to be located from either direction means doubling the data. Though maybe the data is already doubled, if the intent is for tcpEStatsConnectIdTable to contain two rows for every connection, with different values for tcpEStatsConnectIndex. Is the intended meaning behind the DESCRIPTION for tcpEStatsConnectIndex that there be two rows in TcpEStatsConnectIdTable for each connection, and for each of those two rows to have the same tcpEStatsConnectIndex value? I believe this could use some clarification. That's all for now. I appologize if I've overlooked something in my cursory viewing or if these issues have already been hashed out (I've only just subscribed to this list, in response to your mibs list posting). On Tue, 21 Jan 2003, Matt Mathis wrote: > Date: Tue, 21 Jan 2003 15:15:21 -0500 (EST) > From: Matt Mathis > To: mibs@ops.ietf.org > Subject: TCP ESTATS design team > > We are in the process of assembling a design team to update the TCP extended > statistics MIB, draft-ietf-tsvwg-tcp-mib-extension-02.txt. If you would like > to help with this effort please send a note to Peter O'Neil or me. > > The extended statistics MIB will endow TCP with substantial diagnostic > capabilities. > > We will have a new draft for review by the TSVWG in time for the ID cutoff. > This draft will incorporate the detailed per connection statistics from the > web100 project and the good transport work that was done by the IPv6 team and > later determined to be out of scope. > > The IPv6 team is finishing up update to rfc2012. Our document will be an > extension to it. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://www.psc.edu/~mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > > > > > -- Michael Kirkham www.muonics.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 31 12:51:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13580 for ; Fri, 31 Jan 2003 12:51:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VHstw08991 for tsvwg-archive@odin.ietf.org; Fri, 31 Jan 2003 12:54:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHrIJ08924; Fri, 31 Jan 2003 12:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHqGJ08892 for ; Fri, 31 Jan 2003 12:52:16 -0500 Received: from aardvark.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13518; Fri, 31 Jan 2003 12:48:07 -0500 (EST) Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.3/8.12.3) with ESMTP id h0VHpee0077898; Fri, 31 Jan 2003 09:51:40 -0800 (PST) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Michael Welzl cc: dccp@ietf.org, tsvwg@ietf.org In-reply-to: Your message of "31 Jan 2003 09:34:08 +0100." <1044002049.1595.11.camel@lap10-c703.uibk.ac.at> Date: Fri, 31 Jan 2003 09:51:40 -0800 Message-ID: <77897.1044035500@aardvark.icir.org> Subject: [Tsvwg] Re: [dccp] DCCP and UDP Lite Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Hi everybody, > >I just noticed the following sentences in the DCCP specification >(page 11, section 5.1, "checksum length"): > >"The checksum length field specifies what parts of the packet >are covered by the checksum field. The checksum always covers >at least the DCCP header, DCCP options, and a pseudoheader taken >from the network-layer header (see below). If the checksum >length field is zero, that is all the checksum covers." > > >The functionality of setting the checksum length field >to zero closely resembles the capability of UDP Lite to >receive erroneous payload packets and deliver them to the >application. > > >I would say that: > >EITHER: > >- a comment should be included that states that erroneous > payload MUST NOT be delivered to the applications and may > only be used for congestion control purposes (or, possibly > better, the sentence about values other than 0 or 15 being > experimental should be changed to "values other than 15"). > >OR: > >- UDP Lite should be accepted upon acceptance of DCCP. > > >This has nothing to do with personal preference - it's just >similar functionality that caused a lot of discussions in >the case of UDP Lite ... It's not just similar - it was entirely inspired by UDP Lite. We're still rather undecided as to whether this is a useful function. It can easily be removed if there's pushback, but so far the comments we've received have mostly been in favour. It's clearly not a dangerous thing for a transport to allow this. It's just rather pointless unless there are link-layers that might take advantage of it, and applications that can make use of it. In our case it comes down to whether we have a better use for those four bits. Currently we think it's worth spending those 4 bits in this way, given that the unreliable applications DCCP is primarily intended to support are the sort of applications that might be able to use this functionality. - Mark _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri Jan 31 14:45:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16862 for ; Fri, 31 Jan 2003 14:45:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VJmkH15412 for tsvwg-archive@odin.ietf.org; Fri, 31 Jan 2003 14:48:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VJl8J15365; Fri, 31 Jan 2003 14:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VJjRJ15291 for ; Fri, 31 Jan 2003 14:45:27 -0500 Received: from zippy.psc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16789 for ; Fri, 31 Jan 2003 14:41:18 -0500 (EST) Received: from localhost (mathis@localhost) by zippy.psc.edu (8.11.6/8.11.6) with ESMTP id h0VKimO06043; Fri, 31 Jan 2003 15:44:50 -0500 X-Authentication-Warning: zippy.psc.edu: mathis owned process doing -bs Date: Fri, 31 Jan 2003 15:44:48 -0500 (EST) From: Matt Mathis To: Michael Kirkham cc: tsvwg@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Tsvwg] Re: TCP ESTATS design team Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Thanks for the comments. About "denote plurality", yes, we got it wrong. The current document follows a prototype which doesn't use SNMP at all. We were unaware of the naming convention and I am sure we missed others too. This will get fixed. About indexing - we know we have a problem here, but I don't know enough about SNMP (I am a TCP guy) to grasp the subtleties. There are two main issues: 1) We want to support a fast way to poll on a known connection. The "generic" approach (again, used by the non-SNMP prototype) is to have a general (but slow) way to search a table to find a specific 4-tuple. This yields a "Connection ID" which is an opaque int. The Connection ID can then be used for fast polling on any variables in the logical row. 2) We want to be able to support sparse tables to reduce the memory load on a busy server. The current draft has controls per group of columns (which are actually separate smaller tables.) We are considering putting in per-connection controls as well. I will be defering to people with more MIB expertics on the details. BTW there is a document status page at http://www.web100.org/mib Thanks again for taking the time to look at the document, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg