From exim@www1.ietf.org Mon Dec 1 09:17:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11157 for ; Mon, 1 Dec 2003 09:17:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQorM-00014y-B7 for tsvwg-archive@odin.ietf.org; Mon, 01 Dec 2003 09:17:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EH8Kj004147 for tsvwg-archive@odin.ietf.org; Mon, 1 Dec 2003 09:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQorF-000141-1A; Mon, 01 Dec 2003 09:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoqn-00013Y-7d for tsvwg@optimus.ietf.org; Mon, 01 Dec 2003 09:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11140 for ; Mon, 1 Dec 2003 09:16:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoqg-0002D4-00 for tsvwg@ietf.org; Mon, 01 Dec 2003 09:16:26 -0500 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1AQoqg-0002Co-00 for tsvwg@ietf.org; Mon, 01 Dec 2003 09:16:26 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id hB1EFqIk007831; Mon, 1 Dec 2003 08:15:52 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FCB4D13.9040702@stewart.chicago.il.us> Date: Mon, 01 Dec 2003 08:15:47 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: tsvwg@ietf.org Subject: Re: [Tsvwg] SCTP and fragmentation at IP level References: In-Reply-To: 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 Pekka Pessi wrote: >Hello all, > >In the section 2.16 of draft-ietf-tsvwg-sctpimpguide-09.txt the >fragmentation and reassembly section says (new text): > > ... If an implementation does not support fragmentation of outbound > user messages, the endpoint must return an error to its upper layer > and not attempt to send the user message. > > Note: If an implementation that supports fragmentation makes > available to its upper layer a mechanism to turn off fragmentation > it may do so. However in so doing, it MUST react just like an > implementation that does NOT support fragmentation i.e. it MUST > reject sends that exceed the current P-MTU. > >So, if we play the game widely known as "Say it in ALL CAPS" (a >variation of "Simon says", ages 15 to 65) the 2960 could be interpreted >allowing that if the SCTP implementation does not support fragmentation, >it may as well try to send a message exceeding path MTU as a single IP >datagram (that will be fragmented). Now the note in sctpimpguide seems >to contradict the end of first paragraph. > >WOuld it be a nice idea not to play the game in first paragraph and do >it in caps, like "the endpoint MUST return an error", "the endpoint >SHOULD return an error" or "the endpoint MAY return an error"? > >--Pekka > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > good catch.. we missed the captial letters in the first paragraph... not intentionally :-0 I don't think we can get this fix in -10 (it was submitted at the IETF on Wed.. not sure why it has not popped out yet).. but I will get it into the XML for the next version :-> 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 exim@www1.ietf.org Tue Dec 2 09:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19306 for ; Tue, 2 Dec 2003 09:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBg9-0002E2-8c for tsvwg-archive@odin.ietf.org; Tue, 02 Dec 2003 09:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Ed5wE008546 for tsvwg-archive@odin.ietf.org; Tue, 2 Dec 2003 09:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBg5-0002D1-39; Tue, 02 Dec 2003 09:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARBff-0002CZ-Bb for tsvwg@optimus.ietf.org; Tue, 02 Dec 2003 09:38:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19277 for ; Tue, 2 Dec 2003 09:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARBfd-0001l0-00 for tsvwg@ietf.org; Tue, 02 Dec 2003 09:38:33 -0500 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 1ARBfX-0001kw-00 for tsvwg@ietf.org; Tue, 02 Dec 2003 09:38:27 -0500 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id hB2EbsIk015128; Tue, 2 Dec 2003 08:37:55 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3FCCA3C2.3060708@stewart.chicago.il.us> Date: Tue, 02 Dec 2003 08:37:54 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5b) Gecko/20030923 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments about the PKTDROP SCTP extension References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id hB2EbsIk015128 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ivan.Arias-Rodriguez@nokia.com wrote: Ivan: I need to go through the rest of your comments... I am still to far=20 behind :-0 But I saw this and wanted to do a quick comment. > - Section 6, Security considerations: I suppose that you have already t= hough about this, but, as said at the beginning of page 6, middle boxes a= re allowed to send a PKTDROP just to state the bandwidth value. What if t= he peer wants to speed up the transmission and sends a fake PKTDROP as be= ing sent by any middle box in between? This can be perfectly done... I'm = not sure whether you should allow any increase in the cwnd at all... :-/ > > =20 > Yes, I thought of this, and that is precisely the reason for the=20 RTO.Large being around 500ms. If a receiver decides it wants to "speed" things up it will have to maintain=20 the RTT time to be RTO.Large or greater. This means that it must suffer the same problems a satellite network does...=20 this would then result in a major slow down for the receiver.. not exactly what the guy wants :-> We probably do need to add something that states that if the RTT drops=20 smaller than RTO.Large during the association then all cwnd adjustments MUST be disabled (via the packet=20 drop mechanism and restored to its previous value.. this would prevent a guy from holding the RTT larger for a few=20 round trips and then dropping it back after it has "jazzed the window".. Of course that would mean one more state value to be held in your net=20 structure, old_cwnd_at_midbox_speedup, but it is worth it for satellite networks :-> R > > Ok, that's all (by now! ;->) > > BR Iv=E1n Arias Rodr=EDguez > > PS: I suppose this is the right list to send this mail.. > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg > > > > =20 > --=20 Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 3 13:47:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28813 for ; Wed, 3 Dec 2003 13:47:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1n-0006HE-OZ for tsvwg-archive@odin.ietf.org; Wed, 03 Dec 2003 13:47:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3IlBad024122 for tsvwg-archive@odin.ietf.org; Wed, 3 Dec 2003 13:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1d-0006Ef-Ie; Wed, 03 Dec 2003 13:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARc1a-0006EL-8m for tsvwg@optimus.ietf.org; Wed, 03 Dec 2003 13:46:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28779 for ; Wed, 3 Dec 2003 13:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARc1X-0006QT-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 13:46:56 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1ARc1X-0006QN-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 13:46:55 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id hB3IkpNK018318; Wed, 3 Dec 2003 11:46:51 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HPC007011I2ZE@lmco.com>; Wed, 03 Dec 2003 11:46:50 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HPC00ITE1I0BO@lmco.com>; Wed, 03 Dec 2003 11:46:50 -0700 (MST) Date: Wed, 03 Dec 2003 13:46:47 -0500 From: "Eagan, Christopher" To: fred@cisco.com, jmpolk@cisco.com, tibodeau@cisco.com Cc: tsvwg@ietf.org Message-id: <3F2F205501D3D411878C0008C7E6459410CFECD8@emss09m06.ems.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: comments on draft-baker-mlef-concerns-00.txt Thread-Index: AcO5zfMA9Pl+9Ob2Somq+AaPjGthOA== content-class: urn:content-classes:message Content-Transfer-Encoding: 7BIT Subject: [Tsvwg] comments on draft-baker-mlef-concerns-00.txt 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 on draft-baker-tsvwg-mlef-concerns-00 Thanks for putting out this draft. Although I don't agree with it, it is easier to criticize your work than write a whole new draft :) The major problems with this draft are: 1. A mechanism implementing PHB "MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter)" [RFC 2598, Section 2]. This means EF packets will be dropped if the aggregate EF traffic exceeds a policy driven rate limit - right? So, in some situations, EF packets will be dropped, whether one is using EF or MLEF or something else. The only thing MLEF adds to this picture is to provide a mechanism to choose *which* packets will be dropped. The fact that packets will be dropped in some situations does not change by including or excluding MLEF. 2. This draft implicitly assumes MLEF being implemented without other mechanisms also being implemented (e.g. without call admission control). Merits of other mechanisms aside, what is the basis for this assumption? Does an implementation of MLEF exclude other QoS mechanisms or vice versa? Not that I have seen. Maybe if you added interoperability concerns between MLEF and other existing mechanisms this would bolster your argument. The major issue that MLEF solves is network resource priority at a lower and more fundamental level than CAC. Specifically, MLEF allows higher priority traffic to survive without any prior state variables being set in the router. I can see the merits of CAC with respect to managing the problem you describe as "congestive collapse" in section 2.5. But does CAC work in all situations? Does it work in mobile ad hoc environments? Does it recover fast enough when an router routing voice traffic gets blown up or smashed? It makes a lot of sense to me that even using a great CAC mechanism, one would want a backup mechanism to assure important communications. MLEF provides this backup in a simple, easy to implement manner. 3. With regards to the last sentence in the last paragraph, no one has to be reminded of the seriousness of emergencies and how good or bad lines of communications can translate into people's lives. My comments are based on our own discussions within Lockheed Martin and comments previously posted to the IEPREP working group by participants there such as Mike Pierce and Steve Silverman. Having said that, these comments also represent my personal opinions. Christopher Eagan Software Engineer Lockheed Martin (301) 240 - 6328 christopher.eagan@lmco.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 3 14:13:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29708 for ; Wed, 3 Dec 2003 14:13:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcQs-0007L0-5T for tsvwg-archive@odin.ietf.org; Wed, 03 Dec 2003 14:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3JD63o028189 for tsvwg-archive@odin.ietf.org; Wed, 3 Dec 2003 14:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcQn-0007Jq-Kq; Wed, 03 Dec 2003 14:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARcQF-0007Jb-Tr for tsvwg@optimus.ietf.org; Wed, 03 Dec 2003 14:12:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29670 for ; Wed, 3 Dec 2003 14:12:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARcQC-0006lc-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 14:12:24 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1ARcQ6-0006lR-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 14:12:19 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id hB3JBHNM005949; Wed, 3 Dec 2003 12:11:17 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HPC008012MT8Y@lmco.com>; Wed, 03 Dec 2003 12:11:17 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HPC007642MMOR@lmco.com>; Wed, 03 Dec 2003 12:11:17 -0700 (MST) Date: Wed, 03 Dec 2003 14:11:09 -0500 From: "Eagan, Christopher" Subject: [Tsvwg] comments on draft-baker-mlpp-that-works-00 To: fred@cisco.com, jmpolk@cisco.com, tibodeau@cisco.com Cc: tsvwg@ietf.org Message-id: <3F2F205501D3D411878C0008C7E6459410CFECDA@emss09m06.ems.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: comments on draft-baker-mlef-concerns-00.txt Thread-Index: AcO5zfMA9Pl+9Ob2Somq+AaPjGthOAAAkqfw content-class: urn:content-classes:message 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 Thanks for putting out this draft. As you know and have written, MLPP over IP is major concern that has to be dealt with sooner rather than later. Also, having a standardized MLPP implementation will have a great benefit not only for traditional MLPP users but also will be a potential benefit to local first responders all over the world. I think the technical substance of the proposed solution is a good start. However, the proposed solution would be greatly enhanced by adding MLEF as a secondary mechanism to insure that priority calls get through (per the following email commenting the "mlef considered harmful" draft). Chris > -----Original Message----- > From: tsvwg-admin@ietf.org [mailto:tsvwg-admin@ietf.org]On Behalf Of > Eagan, Christopher > Sent: Wednesday, December 03, 2003 1:47 PM > To: fred@cisco.com; jmpolk@cisco.com; tibodeau@cisco.com > Cc: tsvwg@ietf.org > Subject: [Tsvwg] comments on draft-baker-mlef-concerns-00.txt > > > Comments on draft-baker-tsvwg-mlef-concerns-00 > > Thanks for putting out this draft. Although I don't agree > with it, it is easier to criticize your work than write a > whole new draft :) > > The major problems with this draft are: > > 1. A mechanism implementing PHB "MUST include some means to > limit the damage EF traffic could inflict on other traffic > (e.g., a token bucket rate limiter)" [RFC 2598, Section 2]. > This means EF packets will be dropped if the aggregate EF > traffic exceeds a policy driven rate limit - right? So, in > some situations, EF packets will be dropped, whether one is > using EF or MLEF or something else. The only thing MLEF adds > to this picture is to provide a mechanism to choose *which* > packets will be dropped. The fact that packets will be > dropped in some situations does not change by including or > excluding MLEF. > > 2. This draft implicitly assumes MLEF being implemented > without other mechanisms also being implemented (e.g. without > call admission control). Merits of other mechanisms aside, > what is the basis for this assumption? Does an > implementation of MLEF exclude other QoS mechanisms or vice > versa? Not that I have seen. Maybe if you added > interoperability concerns between MLEF and other existing > mechanisms this would bolster your argument. > > The major issue that MLEF solves is network resource priority > at a lower and more fundamental level than CAC. > Specifically, MLEF allows higher priority traffic to survive > without any prior state variables being set in the router. I > can see the merits of CAC with respect to managing the > problem you describe as "congestive collapse" in section 2.5. > But does CAC work in all situations? Does it work in mobile > ad hoc environments? Does it recover fast enough when an > router routing voice traffic gets blown up or smashed? It > makes a lot of sense to me that even using a great CAC > mechanism, one would want a backup mechanism to assure > important communications. MLEF provides this backup in a > simple, easy to implement manner. > > 3. With regards to the last sentence in the last paragraph, > no one has to be reminded of the seriousness of emergencies > and how good or bad lines of communications can translate > into people's lives. > > My comments are based on our own discussions within Lockheed > Martin and comments previously posted to the IEPREP working > group by participants there such as Mike Pierce and Steve > Silverman. Having said that, these comments also represent > my personal opinions. > > Christopher Eagan > Software Engineer > Lockheed Martin > (301) 240 - 6328 > christopher.eagan@lmco.com > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 3 15:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04233 for ; Wed, 3 Dec 2003 15:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddU-0002BK-S2 for tsvwg-archive@odin.ietf.org; Wed, 03 Dec 2003 15:30:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KUChw008382 for tsvwg-archive@odin.ietf.org; Wed, 3 Dec 2003 15:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddN-000293-U9; Wed, 03 Dec 2003 15:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdd9-00026Q-4Q for tsvwg@optimus.ietf.org; Wed, 03 Dec 2003 15:29:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04096; Wed, 3 Dec 2003 15:29:35 -0500 (EST) Message-Id: <200312032029.PAA04096@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: tsvwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Dec 2003 15:29:34 -0500 Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpimpguide-10.txt 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 Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Implementors Guide Author(s) : R. Stewart Filename : draft-ietf-tsvwg-sctpimpguide-10.txt Pages : 76 Date : 2003-12-3 This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document. This document updates RFC2960 [5] and text within this document supersedes the text found in RFC2960 [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tsvwg-sctpimpguide-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-3153033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctpimpguide-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpimpguide-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3153033.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 3 15:54:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05648 for ; Wed, 3 Dec 2003 15:54:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe0a-0003oi-FK for tsvwg-archive@odin.ietf.org; Wed, 03 Dec 2003 15:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ks4XZ014655 for tsvwg-archive@odin.ietf.org; Wed, 3 Dec 2003 15:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe0X-0003nU-9M; Wed, 03 Dec 2003 15:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARe02-0003n5-3F for tsvwg@optimus.ietf.org; Wed, 03 Dec 2003 15:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05587 for ; Wed, 3 Dec 2003 15:53:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARe00-0000N5-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 15:53:28 -0500 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1ARdzy-0000Mj-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 15:53:26 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id hB3KqxIW027323 for ; Wed, 3 Dec 2003 13:52:59 -0700 (MST) Received: from zuk28exm03.ecid.cig.mot.com (zuk28exm03.ecid.cig.mot.com [10.128.69.72]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hB3Kr058018543 for ; Wed, 3 Dec 2003 14:53:01 -0600 Received: by zuk28exm03.ecid.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 3 Dec 2003 20:53:01 -0000 Message-ID: From: Gil Jose-josegil1 To: tsvwg@ietf.org Date: Wed, 3 Dec 2003 20:53:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Subject: [Tsvwg] A few questions and observations on TCP SACK Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I have a few questions specific to the operation of loss recovery specified in RFC 3517 (A conservative Selective Acknowledgment SACK-based Loss Recovery algorithm for TCP). Perhaps an example will help to understand better my questions. Let's assume a window of six segments as an example. Let's numerate segments in that window from 16 to 21. Assume that segments 20 and 21 are lost. Let's say that the next immediate round of segments contains four segments (22 to 25) generated by the acks from segments 16 to 19 (no delayed ack assumed). Let's say that segment 25 is also lost. So in total three segments are lost. When the third dupack arrives for segment 19 then segment 20 is fast retransmitted. Following RFC 3517 pipe=2 after the fast retransmit. Because cwnd=3 > pipe=2 then segment 21 could be retransmitted also (since it is determined as lost by the function IsLost()). Therefore two immediate retransmissions could happen. My question is if there is any limit in the number of segments sent straight after the first fast retransmit if the condition cwnd > pipe is met (apart from the receiver's advertised window limit)? It seems to me that RFC 3517 would allow the fast retransmit of 'n' consecutive lost segments in one go (after the first three dupacks are received and provided that cwnd > pipe and receivers's advertised window limit is not exceeded). When the ack for segment 20 arrives (first partial ack) the value of pipe is recalculated to 2. Therefore only one segment can be transmitted. A new segment 26 could be then transmitted since no more segments have been determined as lost at this point. However reading Kevin Fall and Sally Floyd paper "Simulation-based comparisons of Tahoe, Reno and SACK TCP" pipe is decremented by two for every partial ack received. It seems to me that the RFC 3517 would not decrement pipe by two in my particular example. Is my understanding correct and can we say that decrementing pipe by two for every received partial ack cannot be generalised? My third question relates to the lost segment 25. When the partial ack for segment 24 arrives only one new segment (27) can be transmitted since pipe=2 and segment 25 is not determined yet as lost. Reading the definition of the procedure IsLost() defined in RFC 3517 it is my understanding that segment 25 cannot be retransmitted until three segments above the lost segment are SACKed since IsLost() determines the lost of a segment when "either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or (DupThresh*SMSS) bytes with sequence numbers greater than 'SeqNum' have been SACKed". Essentially, in my example we need to receive three dupacks for segment 24 before we can retransmit segment 25. Am i wrong? My confusion comes from reading Fall&Foyd paper where they retransmit a lost segment immediately after a SACK sequence above the lost segment is received (essentially after one dupack). Does the RFC 3517 allow for the operation described in this paper? Jose _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 3 23:59:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27744 for ; Wed, 3 Dec 2003 23:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARlZz-0006Wm-EK for tsvwg-archive@odin.ietf.org; Wed, 03 Dec 2003 23:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB44x7M6025088 for tsvwg-archive@odin.ietf.org; Wed, 3 Dec 2003 23:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARlZt-0006Vp-0K; Wed, 03 Dec 2003 23:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARlZ1-0006V6-LF for tsvwg@optimus.ietf.org; Wed, 03 Dec 2003 23:58:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27653 for ; Wed, 3 Dec 2003 23:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARlYz-0001nP-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 23:58:05 -0500 Received: from adsl-68-76-113-49.dsl.bcvloh.ameritech.net ([68.76.113.49] helo=lawyers.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1ARlYy-0001mc-00 for tsvwg@ietf.org; Wed, 03 Dec 2003 23:58:04 -0500 Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A3635F78EB; Wed, 3 Dec 2003 23:38:55 -0500 (EST) To: Gil Jose-josegil1 From: Mark Allman Reply-To: mallman@icir.org Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] A few questions and observations on TCP SACK In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Crazy Little Thing Called Love Date: Wed, 03 Dec 2003 23:38:55 -0500 Message-Id: <20031204043855.A3635F78EB@lawyers.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: , > When the third dupack arrives for segment 19 then segment 20 is fast > retransmitted. Following RFC 3517 pipe=2 after the fast > retransmit. Because cwnd=3 > pipe=2 then segment 21 could be > retransmitted also (since it is determined as lost by the function > IsLost()). Therefore two immediate retransmissions could happen. My > question is if there is any limit in the number of segments sent > straight after the first fast retransmit if the condition cwnd > pipe > is met (apart from the receiver's advertised window limit)? It seems > to me that RFC 3517 would allow the fast retransmit of 'n' consecutive > lost segments in one go (after the first three dupacks are received > and provided that cwnd > pipe and receivers's advertised window limit > is not exceeded). You are correct. If the cwnd is X segments before loss recovery then I think you can get a burst on the order of (X/2)-3 in the worst case (i.e., you cut cwnd by half and you need 3 segments (at the end of the window) to get through to indicate that all the intervening segments have been lost). While we increase burstiness a bit we also get to retransmit sooner and get the loss cleaned up as quickly and painlessly as possible. E.g., we have some simulations that show that when a retransmit is lost (and the connection RTOs) the RFC3517 style recovery ends up sending a lot fewer spurious retransmits in slow start loss recovery because we cleaned up a bunch of loss earlier in the process. > When the ack for segment 20 arrives (first partial ack) the value of > pipe is recalculated to 2. Therefore only one segment can be > transmitted. A new segment 26 could be then transmitted since no more > segments have been determined as lost at this point. However reading > Kevin Fall and Sally Floyd paper "Simulation-based comparisons of > Tahoe, Reno and SACK TCP" pipe is decremented by two for every partial > ack received. It seems to me that the RFC 3517 would not decrement > pipe by two in my particular example. Is my understanding correct and > can we say that decrementing pipe by two for every received partial > ack cannot be generalised? An important point, I think... The scheme in the Fall/Floyd paper is what we started with in writing RFC3517. However, we ended up some place fairly different. The spirit might be similar, but the details are not. So, reading both the Fall/Floyd paper and RFC3517 at the same time might be a tad confusing in that the details are going to be different. I.e., you cannot generalize them and say "why does this scheme decrement by 2 and this one only by 1?". The reason is that they started with two slightly different notions of "pipe" to begin with. As an example, Fall/Floyd start pipe at the number of outstanding segments when loss recovery is entered. Meanwhile, RFC3517 starts pipe from zero and counts the number of things that it believes are still in the network at various times within loss recovery. These are similar in their end result, but different in their approach. The two documents are filled with such things. So, I think you should try to understand how each algorithm works seperately without trying to intermix them and figure out why each detail is different. That said, you are right that RFC3517 does not decrement by 2 on each partial ACK, while Fall/Floyd does. But, the reason is that the schemes use two different approaches. Because one does and one does not is fairly meaningless. They are both reasonable choices in the context of the particular scheme. > My third question relates to the lost segment 25. When the partial ack > for segment 24 arrives only one new segment (27) can be transmitted > since pipe=2 and segment 25 is not determined yet as lost. Reading the > definition of the procedure IsLost() defined in RFC 3517 it is my > understanding that segment 25 cannot be retransmitted until three > segments above the lost segment are SACKed since IsLost() determines > the lost of a segment when "either DupThresh discontiguous SACKed > sequences have arrived above 'SeqNum' or (DupThresh*SMSS) bytes with > sequence numbers greater than 'SeqNum' have been SACKed". Essentially, > in my example we need to receive three dupacks for segment 24 before > we can retransmit segment 25. Am i wrong? My confusion comes from > reading Fall&Foyd paper where they retransmit a lost segment > immediately after a SACK sequence above the lost segment is received > (essentially after one dupack). Does the RFC 3517 allow for the > operation described in this paper? No. In some sense the RFC provides more aggressive retransmission than Fall/Floyd (by declaring some segments that have been "lost" as to have left the pipe). And, in other cases, (as you note above) the retransmission behavior in the RFC can be viewed as more conservative. That is, the RFC requires a higher bar before something is declared lost and so is eligible for retransmission (assuming new data to send). I hope that helps! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 8 16:56:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05930 for ; Mon, 8 Dec 2003 16:56:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTMP-0006s7-Bf for tsvwg-archive@odin.ietf.org; Mon, 08 Dec 2003 16:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Lu9d7026411 for tsvwg-archive@odin.ietf.org; Mon, 8 Dec 2003 16:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTMH-0006qr-Pp; Mon, 08 Dec 2003 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTLr-0006kz-BJ for tsvwg@optimus.ietf.org; Mon, 08 Dec 2003 16:55:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05843 for ; Mon, 8 Dec 2003 16:55:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTLp-0006ld-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 16:55:33 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ATTLo-0006k7-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 16:55:32 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2003 13:56:31 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB8Lt0At016233; Mon, 8 Dec 2003 13:55:00 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOG63644; Mon, 8 Dec 2003 13:54:59 -0800 (PST) Message-Id: <6.0.1.1.2.20031208125450.045f99a8@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 08 Dec 2003 13:46:49 -0800 To: "Eagan, Christopher" From: Fred Baker Cc: jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org In-Reply-To: <3F2F205501D3D411878C0008C7E6459410CFECD8@emss09m06.ems.lmc o.com> References: <3F2F205501D3D411878C0008C7E6459410CFECD8@emss09m06.ems.lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt 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: , At 02:46 AM 12/3/2003, Eagan, Christopher wrote: >1. A mechanism implementing PHB "MUST include some means to limit the >damage EF traffic could inflict on other traffic (e.g., a token bucket >rate limiter)" [RFC 2598, Section 2]. This means EF packets will be >dropped if the aggregate EF traffic exceeds a policy driven rate limit - right? You are correct that the problem I raise with MLEF is also a problem with EF; it needs effective CAC. The difference between EF and MLEF is that EF considers that one engineers capacity in such a way that one rarely actually crosses the policing thresholds, and I assure you that VoIP as deployed today does that. MLEF presumes that discard of excess traffic is normal. These are two very different scenarios. However, if you have heard much from me in the past decade, you have heard the line of reasoning outlined in http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt mentioned as appropriate for EF as well. >2. This draft implicitly assumes MLEF being implemented without other >mechanisms also being implemented (e.g. without call admission >control). Merits of other mechanisms aside, what is the basis for this >assumption? Does an implementation of MLEF exclude other QoS mechanisms >or vice versa? Not that I have seen. Maybe if you added interoperability >concerns between MLEF and other existing mechanisms this would bolster >your argument. The MLEF PHB states that packet loss is the means of call admission control. The simulations that Mike Pierce has sent me use packet loss to perform call admission control at the source - if a source is seeing a certain level of loss, it asks itself some policy-related questions and then potentially drops the call. Steve Silverman says the same thing: At 04:53 PM 11/19/2003, Steve Silverman wrote: >One possible solution for the lower priority calls would be a terminal >behaviour such that if a certain percentage (or number) of packets are >lost in a certain amount of time, the terminal issues a congestion notice >to the other party and either the call is suspended for a short period of >time or terminated. My draft addresses those directly, in section 2.6. A measurement-based counterpart to the MLPP procedure has been proposed, in which calls experiencing significant loss treat this as a signal from the network and drop the call. But if all calls at a precedence level are experiencing loss, many and perhaps all calls at the precedence level would be dropped by this heuristic; if many calls are vying for service, the effect would be rolling call disruption - a set of calls would be established, additional calls would be established disrupting that class of calls, many of the disrupted calls would drop, and then more of the competing calls would be established - only to be disrupted when the first set redialed. >I can see the merits of CAC with respect to managing the problem you >describe as "congestive collapse" in section 2.5. But does CAC work in >all situations? If, by policy, you want to decide that when faced with a choice you will choose among packets in a graded fashion, I'm OK with that, and say as much in section 2.2 of http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt. Remember, I wrote another PHB that does exactly that. However, depending on that as your primary CAC mechanism doesn't fly, for reasons outlined above and in the mlef-concerns document. And yes, bandwidth CAC actually does work. You don't, as mentioned in RFC 2210, want to be doing it in every router in the world, but you do in fact want to be doing it in the routers that have bottleneck interfaces. If you do it in the places it needs done, it does in fact limit the total offered load to be less than or equal to the capacity available to that load. >3. With regards to the last sentence in the last paragraph, no one has >to be reminded of the seriousness of emergencies and how good or bad lines >of communications can translate into people's lives. To be very honest, I'm not sure what sentence you're commenting on. The last sentence of the last paragraph in the document reads: Funding for the RFC Editor function is currently provided by the Internet Society. I'm pretty sure you're not referring to that one. But you may be referring to our recommendation: 3. Recommendation Considering the nature of real-time traffic and the effect of packet loss on known codecs, it is clear that degradation of voice quality in an MLEF environment for lower precedence calls will be severe. Even the advances in codec technology do not fix the problem. With all due respect to the engineers who have worked on designing and developing the DISA Assured Service and MLEF, the authors cannot in good conscience recommend its deployment as it stands. It will protect the calls placed by senior officers and constitutional officials, but it does not provide the same service that MLPP provides to those who respond to their orders, and therefore seriously impinges on the likelihood that those orders will be correctly disseminated and carried out. Considering the environment this proposed mechanism is for, the potential attractiveness for other environments, and that the effects could and should compound upon themselves, the worst case scenario includes loss of life due to communications failure. Nothing done here should enhance this possibility. Yes, I would hope that nobody has to be reminded that - unlike the difference between TCP with this congestion avoidance algorithm vs that one - lives depend on this PHB working. What I'm trying to do here is move this out of the ivory tower. I care deeply about this issue not because I have a pet solution I would prefer you use, although yes I do of course have an alternate proposal. I care about this because my son's life may be placed at risk because you haven't done your math. This is not ivory tower. This is "rubber, meet road; road, meet rubber." My concern is simply this. MLPP-preempted calls, and the attempted placement of more calls than available bandwidth will support, are the norm in military environments. I have a fairly long string of emails from present and former service personnel telling stories of real MLPP in action, and they are *frequent*. What I read as the VoIP solution for that level of problem is laden with assumptions that I can't make play as I do the math. My key concern is that The problem with MLEF, in a nutshell, is that it implements a different service than MLPP, and that service has a very different effect. The basic function of MLPP is to cause some number of lower precedence calls to be dropped, or not started, so that o higher precedence calls get placed, and o the remaining lower precedence calls stay at good quality. MLEF fails to achieve the second function. Instead, MLEF can create a situation where all lower precedence calls become unintelligible, thus destroying most of the usefulness of the communications system. OK, consider this. Here is a war story from a colleague: >...preempting my way to an Italian airbase during Desert Storm to prevent >a possible aircraft incident (running a flight of 6 OV-10's out of fuel >with no place to land) and as a lower ranking caller, preempting a call >between then Brig Gen Jones in Aviano and Gen Al Gray, then CMC, with a >priority call when they were using a routine circuit. So he used a "priority" call, which only preempts "routine" calls. But with MLEF, if the bandwidth is exactly 100% used and he has a typical unit configuration, what he has just done is impose upwards of 5% random loss on *every*single*one* of the competing routine calls. Pick your MOS score report; 5% loss drops their MOS well below 3.5 and in many I have read (and referenced in the draft), well below 3.0. That can just as easily result in fairly dire things happening in a military environment. We said we can't recommend depending on MLEF in an environment where lives depend on it because, well, we can't recommend it. We are in fact very deeply concerned about this. >My comments are based on our own discussions within Lockheed Martin and >comments previously posted to the IEPREP working group by participants >there such as Mike Pierce and Steve Silverman. Having said that, these >comments also represent my personal opinions. I have also discussed these things in ieprep, with Mike and Steve, and by the way they are my personal opinions. But this is not about opinion, whomsoever's it may be. My concerns derive fairly directly from mathematics. If a system is designed to carry 20 calls (T-1 line and using G.711 encoding as proposed in current DISA documents), adding a 21st call results in 5% loss roughly uniformly distributed among the calls at any lower precedence than the call added. 5% loss drops the MOS/PESQ score into the danger zone; 10% loss is so bad that the reports don't even attempt to characterize it. If ILBC is used as the codec, per the Miami University report I cited, you get a little better loss performance. That still has a limit, though, and when you go beyond that limit, the result is still horrendous. And, as described in section 2.2, any protection-based codec, ILBC being but one example, has a ballooning effect - when RCP starts reporting loss, the codec sends more traffic. Thus, if a link is capable of carrying 20 calls, adding a 21st call doesn't make it lose the traffic equivalent of a single call. It actually balloons the traffic to 150% of its former size, and as a result drops roughly 1/3 of the traffic - well beyond the limits of even ILBC. Mathematics is bedrock. You're building a system to operate in a storm. It can be a house built on bedrock, or it can be the ship that founders on the same bedrock. What you need to show is that the math is wrong, that 21/20 of a link does not result in 5% loss, or that 5% loss does not result in a low MOS score, or ... _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 8 20:16:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18289 for ; Mon, 8 Dec 2003 20:16:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWTs-00080t-Rb for tsvwg-archive@odin.ietf.org; Mon, 08 Dec 2003 20:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB91G4Ze030799 for tsvwg-archive@odin.ietf.org; Mon, 8 Dec 2003 20:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWTp-00080P-Fm; Mon, 08 Dec 2003 20:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWSy-0007yh-V8 for tsvwg@optimus.ietf.org; Mon, 08 Dec 2003 20:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18266 for ; Mon, 8 Dec 2003 20:14:53 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWSw-000406-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:15:06 -0500 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx with esmtp (Exim 4.12) id 1ATWSw-0003zp-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:15:06 -0500 Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v36_r1.1.) id l.5b.4314111c (4446) for ; Mon, 8 Dec 2003 20:14:35 -0500 (EST) Message-ID: <5b.4314111c.2d067bfb@aol.com> Date: Mon, 8 Dec 2003 20:14:35 EST To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_5b.4314111c.2d067bfb_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Tsvwg] Question on "draft-baker-tsvwg-mlpp-that-works" 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: , --part1_5b.4314111c.2d067bfb_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In Section 2.2 of the draft, there is a reference to SRTCM and TRTCM, implying that it could be used for the DISA requirement of 5 (or 6) precedence levels. As I read SRTCM and TRTCM, they seem to be applicable to packet flows with widely varying rates and bursts (colors set according to Committed Burst Size and Excess Burst Size). How would these apply to a voice packet stream, which must originate at codecs with very constant (or well regulated) rates? Further, the draft states that they can be "trivally extended to an arbitrary number of colors". How could this be done, when the RFCs are based on exactly 3 colors depending on comparison with CBS and EBS? Does this mean using a different "color" for the packets of each of the 5 (or 6) precedence levels of calls? SRTCM and TRTCM appear to be describing packet marking within a single flow. How could this be applied to different flows (calls)? (Juha, if you could respond to this. The latest e-mail address I had for you bounced.) Mike Pierce --part1_5b.4314111c.2d067bfb_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In Section 2.2 of the dra= ft, there is a reference to SRTCM and TRTCM, implying that it could be used=20= for the DISA requirement of 5 (or 6) precedence levels.

As I read SRTCM and TRTCM, they seem to be applicable to packet flows wi= th widely varying rates and bursts (colors set according to Committed Burst=20= Size and Excess Burst Size). How would these apply to a voice packet stream,= which must originate at codecs with very constant (or well regulated) rates= ?

Further, the draft states that they can be "trivally extended to an arbi= trary number of colors". How could this be done, when the RFCs are based on=20= exactly 3 colors depending on comparison with CBS and EBS? Does this mean us= ing a different "color" for the packets of each of the 5 (or 6) precedence l= evels of calls?

SRTCM and TRTCM appear to be describing packet marking within a single f= low. How could this be applied to different flows (calls)?

(Juha, if you could respond to this. The latest e-mail address I had for= you bounced.)

Mike Pierce

--part1_5b.4314111c.2d067bfb_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 8 20:23:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18769 for ; Mon, 8 Dec 2003 20:23:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWac-0008JM-Fn for tsvwg-archive@odin.ietf.org; Mon, 08 Dec 2003 20:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB91N2ip031925 for tsvwg-archive@odin.ietf.org; Mon, 8 Dec 2003 20:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWab-0008I8-78; Mon, 08 Dec 2003 20:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWaW-0008Hv-AI for tsvwg@optimus.ietf.org; Mon, 08 Dec 2003 20:22:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18746 for ; Mon, 8 Dec 2003 20:22:40 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWaU-0004EM-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:22:54 -0500 Received: from imo-m05.mx.aol.com ([64.12.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1ATWaT-0004EE-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:22:53 -0500 Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v36_r1.1.) id c.12b.36f22cb5 (4446); Mon, 8 Dec 2003 20:17:54 -0500 (EST) Message-ID: <12b.36f22cb5.2d067cc1@aol.com> Date: Mon, 8 Dec 2003 20:17:53 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt To: fred@cisco.com, christopher.eagan@lmco.com CC: jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12b.36f22cb5.2d067cc1_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_12b.36f22cb5.2d067cc1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes: >[Chris Eagen wrote] 2. This draft implicitly assumes MLEF being implemented without other >mechanisms also being implemented (e.g. without call admission >control). Merits of other mechanisms aside, what is the basis for this >assumption? Does an implementation of MLEF exclude other QoS mechanisms >or vice versa? Not that I have seen. Maybe if you added interoperability >concerns between MLEF and other existing mechanisms this would bolster >your argument. [FB answered] The MLEF PHB states that packet loss is the means of call admission control. The simulations that Mike Pierce has sent me use packet loss to perform call admission control at the source - if a source is seeing a certain level of loss, it asks itself some policy-related questions and then potentially drops the call. Steve Silverman says the same thing: [MAP] No, I have never suggested the use of packet loss to perform call admission control. I have always assumed, and I hope I have made clear, that CAC and MLEF are two separate mechanisms, and that both are required. The MLEF PHB draft does not say it uses packet loss to affect admission control. It does not mention call admission. The simulation I sent is not based on using packet loss to affect call admission. It is based on fixed call admission limits. I know it needs more explanation which I'll try in a follow-up e-mail. Call admission control (without or without MLEF and with or without multiple precedence levels) must be done based on knowledge of how many packet flows a facility (link) can support and still provide the desired QoS. This is relatively easy to estimate with constant bit rate codecs like G.711. As Fred wrote in his draft, it is more complicated and uncertain with variable rates (such as with silence suppression). MLEF (for multiple precedence levels) is what takes care of the (hopefully) short periods in which the expectations of CAC are not quite met that must result in periods during which the buffer overflows and packets are discarded (as required by EF). This is especially a problem when using variable rate codecs as Fred described. These make a mechanism such as MLEF all the more important. The idea of causing packet flows to be stopped by the source based on detection of excess packet loss (and reporting back in the other direction) was also raised as a method of dealing with congestion, but it is not a part of MLEF. I don't consider it part of CAC either, but that a question of definition. MIke Pierce --part1_12b.36f22cb5.2d067cc1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 12/8/2= 003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes:


>[Chris Eagen wrote]=20
2.  This draft implicitly assumes MLEF being implemented without ot= her=20
>mechanisms also being implemented (e.g. without call admission=20
>control).  Merits of other mechanisms aside, what is the basis=20= for this=20
>assumption?  Does an implementation of MLEF exclude other QoS m= echanisms=20
>or vice versa?  Not that I have seen.  Maybe if you added=20= interoperability=20
>concerns between MLEF and other existing mechanisms this would bolst= er=20
>your argument.

[FB answered] The MLEF PHB states that packet loss is the means of call=20= admission=20
control. The simulations that Mike Pierce has sent me use packet loss to= =20
perform call admission control at the source - if a source is seeing a=20
certain level of loss, it asks itself some policy-related questions and=20
then potentially drops the call. Steve Silverman says the same thing:


[MAP] No, I have never suggested the use of packet loss to perform call=20= admission control. I have always assumed, and I hope I have made clear, that= CAC and MLEF are two separate mechanisms, and that both are required. The M= LEF PHB draft does not say it uses packet loss to affect admission control.=20= It does not mention call admission.

The simulation I sent is not based on using packet loss to affect call a= dmission. It is based on fixed call admission limits. I know it needs more e= xplanation which I'll try in a follow-up e-mail.

Call admission control (without or without MLEF and with or without mult= iple precedence levels) must be done based on knowledge of how many packet f= lows a facility (link) can support and still provide the desired QoS. This i= s relatively easy to estimate with constant bit rate codecs like G.711. As F= red wrote in his draft, it is more complicated and uncertain with variable r= ates (such as with silence suppression).

MLEF (for multiple precedence levels) is what takes care of the (hopeful= ly) short periods in which the expectations of CAC are not quite met that mu= st result in periods during which the buffer overflows and packets are disca= rded (as required by EF). This is especially a problem when using variable r= ate codecs as Fred described. These make a mechanism such as MLEF all the mo= re important.

The idea of causing packet flows to be stopped by the source based on de= tection of excess packet loss (and reporting back in the other direction) wa= s also raised as a method of dealing with congestion, but it is not a part o= f MLEF. I don't consider it part of CAC either, but that a question of defin= ition.

MIke Pierce

--part1_12b.36f22cb5.2d067cc1_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 8 20:27:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18894 for ; Mon, 8 Dec 2003 20:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWeT-0008TF-DZ for tsvwg-archive@odin.ietf.org; Mon, 08 Dec 2003 20:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB91R1Ji032535 for tsvwg-archive@odin.ietf.org; Mon, 8 Dec 2003 20:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWeS-0008Rx-Vl; Mon, 08 Dec 2003 20:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWdq-0008Rd-RW for tsvwg@optimus.ietf.org; Mon, 08 Dec 2003 20:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18853 for ; Mon, 8 Dec 2003 20:26:06 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWdo-0004HD-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:26:20 -0500 Received: from imo-r01.mx.aol.com ([152.163.225.97]) by ietf-mx with esmtp (Exim 4.12) id 1ATWdn-0004GF-00 for tsvwg@ietf.org; Mon, 08 Dec 2003 20:26:19 -0500 Received: from Mpierce1@aol.com by imo-r01.mx.aol.com (mail_out_v36_r1.1.) id c.37.41c466fb (3996); Mon, 8 Dec 2003 20:22:50 -0500 (EST) Message-ID: <37.41c466fb.2d067dea@aol.com> Date: Mon, 8 Dec 2003 20:22:50 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt To: fred@cisco.com, christopher.eagan@lmco.com CC: jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_37.41c466fb.2d067dea_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_37.41c466fb.2d067dea_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes: >[Chris Eagen wrote] 2. This draft implicitly assumes MLEF being implemented without other >mechanisms also being implemented (e.g. without call admission >control). Merits of other mechanisms aside, what is the basis for this >assumption? Does an implementation of MLEF exclude other QoS mechanisms >or vice versa? Not that I have seen. Maybe if you added interoperability >concerns between MLEF and other existing mechanisms this would bolster >your argument. [FB answered] The MLEF PHB states that packet loss is the means of call admission control. The simulations that Mike Pierce has sent me use packet loss to perform call admission control at the source - if a source is seeing a certain level of loss, it asks itself some policy-related questions and then potentially drops the call. Steve Silverman says the same thing: [MAP] No, I have never suggested the use of packet loss to perform call admission control. I have always assumed, and I hope I have made clear, that CAC and MLEF are two separate mechanisms, and that both are required. The MLEF PHB draft does not say it uses packet loss to affect admission control. It does not mention call admission. The simulation I sent is not based on using packet loss to affect call admission. It is based on fixed call admission limits. I know it needs more explanation which I'll try in a follow-up e-mail. Call admission control (without or without MLEF and with or without multiple precedence levels) must be done based on knowledge of how many packet flows a facility (link) can support and still provide the desired QoS. This is relatively easy to estimate with constant bit rate codecs like G.711. As Fred wrote in his draft, it is more complicated and uncertain with variable rates (such as with silence suppression). MLEF (for multiple precedence levels) is what takes care of the (hopefully) short periods in which the expectations of CAC are not quite met that must result in periods during which the buffer overflows and packets are discarded (as required by EF). This is especially a problem when using variable rate codecs as Fred described. These make a mechanism such as MLEF all the more important. The idea of causing packet flows to be stopped by the source based on detection of excess packet loss (and reporting back in the other direction) was also raised as a method of dealing with congestion, but it is not a part of MLEF. I don't consider it part of CAC either, but that a question of definition. MIke Pierce --part1_37.41c466fb.2d067dea_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 12/8/2= 003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes:


>[Chris Eagen wrote]=20
2.  This draft implicitly assumes MLEF being implemented without ot= her=20
>mechanisms also being implemented (e.g. without call admission=20
>control).  Merits of other mechanisms aside, what is the basis=20= for this=20
>assumption?  Does an implementation of MLEF exclude other QoS m= echanisms=20
>or vice versa?  Not that I have seen.  Maybe if you added=20= interoperability=20
>concerns between MLEF and other existing mechanisms this would bolst= er=20
>your argument.

[FB answered] The MLEF PHB states that packet loss is the means of call=20= admission=20
control. The simulations that Mike Pierce has sent me use packet loss to= =20
perform call admission control at the source - if a source is seeing a=20
certain level of loss, it asks itself some policy-related questions and=20
then potentially drops the call. Steve Silverman says the same thing:


[MAP] No, I have never suggested the use of packet loss to perform call=20= admission control. I have always assumed, and I hope I have made clear, that= CAC and MLEF are two separate mechanisms, and that both are required. The M= LEF PHB draft does not say it uses packet loss to affect admission control.=20= It does not mention call admission.

The simulation I sent is not based on using packet loss to affect call a= dmission. It is based on fixed call admission limits. I know it needs more e= xplanation which I'll try in a follow-up e-mail.

Call admission control (without or without MLEF and with or without mult= iple precedence levels) must be done based on knowledge of how many packet f= lows a facility (link) can support and still provide the desired QoS. This i= s relatively easy to estimate with constant bit rate codecs like G.711. As F= red wrote in his draft, it is more complicated and uncertain with variable r= ates (such as with silence suppression).

MLEF (for multiple precedence levels) is what takes care of the (hopeful= ly) short periods in which the expectations of CAC are not quite met that mu= st result in periods during which the buffer overflows and packets are disca= rded (as required by EF). This is especially a problem when using variable r= ate codecs as Fred described. These make a mechanism such as MLEF all the mo= re important.

The idea of causing packet flows to be stopped by the source based on de= tection of excess packet loss (and reporting back in the other direction) wa= s also raised as a method of dealing with congestion, but it is not a part o= f MLEF. I don't consider it part of CAC either, but that a question of defin= ition.

MIke Pierce

--part1_37.41c466fb.2d067dea_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Dec 9 11:24:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02324 for ; Tue, 9 Dec 2003 11:24:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkea-00045o-Dh for tsvwg-archive@odin.ietf.org; Tue, 09 Dec 2003 11:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GO47r015728 for tsvwg-archive@odin.ietf.org; Tue, 9 Dec 2003 11:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeY-00044W-1a; Tue, 09 Dec 2003 11:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkdp-00043R-6a for tsvwg@optimus.ietf.org; Tue, 09 Dec 2003 11:23:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02208 for ; Tue, 9 Dec 2003 11:23:00 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkdo-0002SK-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 11:23:16 -0500 Received: from imo-m03.mx.aol.com ([64.12.136.6]) by ietf-mx with esmtp (Exim 4.12) id 1ATkdn-0002Rc-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 11:23:15 -0500 Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v36_r1.1.) id c.85.e2db7e (16335); Tue, 9 Dec 2003 11:16:58 -0500 (EST) Message-ID: <85.e2db7e.2d074f79@aol.com> Date: Tue, 9 Dec 2003 11:16:57 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (2) To: fred@cisco.com, christopher.eagan@lmco.com CC: jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_85.e2db7e.2d074f79_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_85.e2db7e.2d074f79_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes: > My concerns derive fairly directly from mathematics. If a system is > designed to carry 20 calls (T-1 line and using G.711 encoding as proposed > in current DISA documents), adding a 21st call results in 5% loss roughly > uniformly distributed among the calls at any lower precedence than the call > added. 5% loss drops the MOS/PESQ score into the danger zone; 10% loss is > so bad that the reports don't even attempt to characterize it. If ILBC is > used as the codec, per the Miami University report I cited, you get a > little better loss performance. That still has a limit, though, and when > you go beyond that limit, the result is still horrendous. And, as described > in section 2.2, any protection-based codec, ILBC being but one example, has > a ballooning effect - when RCP starts reporting loss, the codec sends more > traffic. Thus, if a link is capable of carrying 20 calls, adding a 21st > call doesn't make it lose the traffic equivalent of a single call. It > actually balloons the traffic to 150% of its former size, and as a result > drops roughly 1/3 of the traffic - well beyond the limits of even ILBC. > > Mathematics is bedrock. You're building a system to operate in a storm. It > can be a house built on bedrock, or it can be the ship that founders on the > same bedrock. What you need to show is that the math is wrong, that 21/20 > of a link does not result in 5% loss, or that 5% loss does not result in a > low MOS score, or ... > [MAP] Okay, what's the reality of the above situation you suggest. 20 routine calls are in place when the emergency begins. Let's assume that there is an effective CAC in place that limits new calls so that: - a new Routine call is allowed only if the current number of Routine calls is not > 20 - a new Priority call is allowed only if the current number of Priority calls is not > 1 As the new Priority call is started, it adds to the count that CAC uses for this limit. Let's say the call set up time is 6 seconds. This means it won't need a packet flow until 6 seconds after it starts. The average holding time for the existing Routine calls is 180 seconds. Assume that the next call does not release until 9 seconds after the emergency (time 0) (the average is really 4.5 seconds after any point in time). Let's say 1 new Priority call begins at time 1 sec after the emergency. The simulation results in 5.25% packet loss on the 20 routine calls for 2 seconds (with MLEF). The alternative (without MLEF) is that all 21 calls experience 5% packet loss, including the first 2 seconds of the Priority call, just as their conversation starts. Yes, the math shows that 21/20 results in 5% loss, but normal call handling (call releases and CAC to limit new ones) results in this being a rather short duration loss. Mike Pierce --part1_85.e2db7e.2d074f79_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 12/8/2= 003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes:


My concerns derive fairly d= irectly from mathematics. If a system is=20
designed to carry 20 calls (T-1 line and using G.711 encoding as propose= d=20
in current DISA documents), adding a 21st call results in 5% loss roughl= y=20
uniformly distributed among the calls at any lower precedence than the c= all=20
added. 5% loss drops the MOS/PESQ score into the danger zone; 10% loss i= s=20
so bad that the reports don't even attempt to characterize it. If ILBC i= s=20
used as the codec, per the Miami University report I cited, you get a=20
little better loss performance. That still has a limit, though, and when= =20
you go beyond that limit, the result is still horrendous. And, as descri= bed=20
in section 2.2, any protection-based codec, ILBC being but one example,=20= has=20
a ballooning effect - when RCP starts reporting loss, the codec sends mo= re=20
traffic. Thus, if a link is capable of carrying 20 calls, adding a 21st=20
call doesn't make it lose the traffic equivalent of a single call. It=20
actually balloons the traffic to 150% of its former size, and as a resul= t=20
drops roughly 1/3 of the traffic - well beyond the limits of even ILBC.

Mathematics is bedrock. You're building a system to operate in a storm.=20= It=20
can be a house built on bedrock, or it can be the ship that founders on=20= the=20
same bedrock. What you need to show is that the math is wrong, that 21/2= 0=20
of a link does not result in 5% loss, or that 5% loss does not result in= a=20
low MOS score, or ...  



[MAP]
Okay, what's the reality of the above situation you suggest.

20 routine calls are in place when the emergency begins.
Let's assume that there is an effective CAC in place that limits new cal= ls so that:
 - a new Routine call is allowed only if the current number of Rou= tine calls is not > 20
 - a new Priority call is allowed only if the current number of Pr= iority calls is not > 1
As the new Priority call is started, it adds to the count that CAC uses=20= for this limit.
Let's say the call set up time is 6 seconds. This means it won't need a=20= packet flow until 6 seconds after it starts.
The average holding time for the existing Routine calls is 180 seconds.=20= Assume that the next call does not release until 9 seconds after the emergen= cy (time 0) (the average is really 4.5 seconds after any point in time).
Let's say 1 new Priority call begins at time 1 sec after the emergency.

The simulation results in 5.25% packet loss on the 20 routine calls for=20= 2 seconds (with MLEF).
The alternative (without MLEF) is that all 21 calls experience 5% packet= loss, including the first 2 seconds of the Priority call, just as their con= versation starts.

Yes, the math shows that 21/20 results in 5% loss, but normal call handl= ing (call releases and CAC to limit new ones) results in this being a rather= short duration loss.

Mike Pierce


--part1_85.e2db7e.2d074f79_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Dec 9 11:31:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02572 for ; Tue, 9 Dec 2003 11:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATklM-0004Ww-Go for tsvwg-archive@odin.ietf.org; Tue, 09 Dec 2003 11:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GV4Jp017371 for tsvwg-archive@odin.ietf.org; Tue, 9 Dec 2003 11:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATklK-0004VO-KI; Tue, 09 Dec 2003 11:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkl8-0004SS-ID for tsvwg@optimus.ietf.org; Tue, 09 Dec 2003 11:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02536 for ; Tue, 9 Dec 2003 11:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkl7-0002dH-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 11:30:49 -0500 Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx with esmtp (Exim 4.12) id 1ATkl7-0002dA-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 11:30:49 -0500 Received: from Steve (ha96s460.d.shentel.net [204.111.97.204]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hB9GUC426604; Tue, 9 Dec 2003 11:30:12 -0500 From: "Steve Silverman" To: Subject: [Tsvwg] Response to Fred Baker on MLEF and MLPPoIP Date: Tue, 9 Dec 2003 11:30:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Someone called my attention to two IDs on the subject of MLEF ( "MLEF Considered Harmful" (by Fred Baker and James Polk), and "Implementing MLPP in the Internet Protocol Suite" by Fred Baker. Sorry it has taken so long to respond but personal issues related to a snowstorm have kept me otherwise occupied. MLEF is not mutually exclusive with a CAC. I think they provide complimentary functionality. As Fred points out, in some situations, more bandwidth can NOT be deployed easily. Therefore, silence suppression (or Voice Activity Detection), which will provide two to three times more voice channels in a fixed amount of bandwidth, may be a necessary function even if it limits the precision of the CAC. MLEF can guarantee that the critical calls get thru short periods of congestion. Much was made in "MLEF Considered Harmful" of the impact of MLEF on ILBC. I do not know of any use of this codec in the DOD. I would hope that a better choice would be make for a VoIP codec. MLEF does NOT introduce a delay into packet flow. When congestion occurs, some packets (from the lowest priority class) are dropped. This allows the higher priority packets to proceed thru the bottleneck faster. I never claimed that MLEF is a complete solution to the issue of VoIP congestion. Call Control was not considered in this work. It dealt solely with a PHB that would act at the packet level. Since we had limited funding, I picked one aspect of the problem (a PHB) that I thought I could do within a limited time frame. I felt that this was one key issue that required additional analysis. Other people were already working on Call Control. I have always said that considerable additional work was needed. Steve Silverman _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Dec 9 15:22:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13388 for ; Tue, 9 Dec 2003 15:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToMw-0006oh-6a for tsvwg-archive@odin.ietf.org; Tue, 09 Dec 2003 15:22:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9KM6k6026202 for tsvwg-archive@odin.ietf.org; Tue, 9 Dec 2003 15:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToMr-0006nP-S9; Tue, 09 Dec 2003 15:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToMM-0006mX-W2 for tsvwg@optimus.ietf.org; Tue, 09 Dec 2003 15:21:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13289 for ; Tue, 9 Dec 2003 15:21:15 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AToML-00076t-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 15:21:29 -0500 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx with esmtp (Exim 4.12) id 1AToML-00074A-00 for tsvwg@ietf.org; Tue, 09 Dec 2003 15:21:29 -0500 Received: from Mpierce1@aol.com by imo-d03.mx.aol.com (mail_out_v36_r1.1.) id c.1d0.15c56007 (4320); Tue, 9 Dec 2003 15:19:56 -0500 (EST) Message-ID: <1d0.15c56007.2d07886c@aol.com> Date: Tue, 9 Dec 2003 15:19:56 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) To: fred@cisco.com, christopher.eagan@lmco.com CC: jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1d0.15c56007.2d07886c_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_1d0.15c56007.2d07886c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes: > My draft addresses those directly, in section 2.6. > > A measurement-based counterpart to the MLPP procedure has been > proposed, in which calls experiencing significant loss treat this as > a signal from the network and drop the call. But if all calls at a > precedence level are experiencing loss, many and perhaps all calls at > the precedence level would be dropped by this heuristic; if many > calls are vying for service, the effect would be rolling call > disruption - a set of calls would be established, additional calls > would be established disrupting that class of calls, many of the > disrupted calls would drop, and then more of the competing calls > would be established - only to be disrupted when the first set > redialed. > Besides the problem you noted above with this method of dealing with congestion (packet loss), there is also the problem that it can not function in a multi-precedence level environment without a selective packet discard mechanism as defined in MLEF. It must be presumed that the intention of the above is that the decision to drop a call based on packet loss is made by the endpoint, that is, the user's terminal. If there were only 2 levels, a terminal could know that it is involved in a call at the lowest level and release, or know that it has a call at the higher level and not release when packet losses occur. However, the requirement is for 5 (or 6 levels). A teminal which is involved in a Priority call and is getting packet losses does not know if the loss is due to contention with 20 other routine calls, in which case it should just wait for the others to release, or if it is due to 20 other Flash calls, in which case this terminal must release quickly. An MLEF-type mechanism at the congestion point in between would resolve this problem. Mike --part1_1d0.15c56007.2d07886c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 12/8/2= 003 4:56:54 PM Eastern Standard Time, fred@cisco.com writes:


My draft addresses those di= rectly, in section 2.6.

   A measurement-based counterpart to the MLPP procedure= has been
   proposed, in which calls experiencing significant los= s treat this as
   a signal from the network and drop the call. But if a= ll calls at a
   precedence level are experiencing loss, many and perh= aps all calls at
   the precedence level would be dropped by this heurist= ic; if many
   calls are vying for service, the effect would be roll= ing call
   disruption - a set of calls would be established, add= itional calls
   would be established disrupting that class of calls,=20= many of the
   disrupted calls would drop, and then more of the comp= eting calls
   would be established - only to be disrupted when the=20= first set
   redialed.

Besides the problem you noted above with this method of deal= ing with congestion (packet loss), there is also the problem that it can not= function in a multi-precedence level environment without a selective packet= discard mechanism as defined in MLEF.

It must be presumed that the intention of the above is that the decision= to drop a call based on packet loss is made by the endpoint, that is, the u= ser's terminal.

If there were only 2 levels, a terminal could know that it is involved i= n a call at the lowest level and release, or know that it has a call at the=20= higher level and not release when packet losses occur.

However, the requirement is for 5 (or 6 levels). A teminal which is invo= lved in a Priority call and is getting packet losses does not know if the lo= ss is due to contention with 20 other routine calls, in which case it should= just wait for the others to release, or if it is due to 20 other Flash call= s, in which case this terminal must release quickly. An MLEF-type mechanism=20= at the congestion point in between would resolve this problem.

Mike

--part1_1d0.15c56007.2d07886c_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Tue Dec 9 19:09:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25438 for ; Tue, 9 Dec 2003 19:09:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATrua-00015H-9i for tsvwg-archive@odin.ietf.org; Tue, 09 Dec 2003 19:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA094no004161 for tsvwg-archive@odin.ietf.org; Tue, 9 Dec 2003 19:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATruW-00013x-Mn; Tue, 09 Dec 2003 19:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATruK-00013Y-Nw for tsvwg@optimus.ietf.org; Tue, 09 Dec 2003 19:08:48 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25420 for ; Tue, 9 Dec 2003 19:08:29 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATrto-0004XH-B9; Tue, 09 Dec 2003 19:08:16 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Tue, 09 Dec 2003 19:08:16 -0500 Subject: [Tsvwg] Protocol Action: 'The UDP-Lite Protocol' 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 approved the following document: - 'The UDP-Lite Protocol ' as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document describes the UDP-Lite protocol, which is similar to UDP (RFC 768), but can also serve applications that in error-prone network environments prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP- Lite is semantically identical to UDP. UDP-Lite provides a checksum with optional partial coverage. When using this option, a packet is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). Errors in the insensitive part will not cause the packet to be discarded by the transport layer. Working Group Summary The Transport Working Group supported advancement of this specification. There was Last Call dissent about two aspects: first, its original plan of being a variant of UDP itself. The response was to develop the protocol as a separate transport protocol, which has better properties in general. Second, there were questions about the applicability. For this, the debate was referred to the authors' more detailed conference paper on audio use of errored data. The flexibility of UDP-Lite is not for broad classes of applications, but the conclusion was that it has utility for a significant class of cellular uses now and should be advanced. An additional debate occurred relevant to UDP-lite during IETF 57 during discussion of Aaron Falk's presentation of partial checksum for the IAB plenary: there was mixed support of the value of this general feature in the Internet architecture, but again there were many considerations of applicability. Protocol Quality The protocol was reviewed for the IESG by Allison Mankin and Erik Nordmark. There have been implementations for a number of years and many experimental trials. RFC Editor Notes: 1/ Abstract - Replace "[RFC-768]" with "(RFC 768)" 2/ Security Considerations - Old: Many strong encryption transforms today exhibit this behavior, for reasons obvious from a security point of view. There exist encryption transforms, stream ciphers, which do not spread errors in this way when the damage occurs in the insensitive part of the packet. New: Many encryption transforms today exhibit this behavior. There exist encryptions transforms, stream ciphers, which do not cause error propagation. Note that omitting an integrity check can, under certain circumstances, compromise confidentiality [Bellovin98]. Proper use of stream ciphers poses its own challenges [BB01]. [Bellovin98] Steven M. Bellovin, "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1998. [BB01] S. Bellovin and M. Blaze, "Cryptographic Modes of Operation for the Internet", Second NIST Workshop on Modes of Operation, August 2001. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 10 11:46:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22962 for ; Wed, 10 Dec 2003 11:46:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU7TR-0002IA-GF for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 11:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAGk5k4008806 for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 11:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU7TP-0002HP-AX; Wed, 10 Dec 2003 11:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU7So-0002FU-Gl for tsvwg@optimus.ietf.org; Wed, 10 Dec 2003 11:45:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21841 for ; Wed, 10 Dec 2003 11:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU7Sn-0001Yg-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 11:45:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AU7Sm-0001Y6-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 11:45:24 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Dec 2003 08:47:02 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBAGipAt021314; Wed, 10 Dec 2003 08:44:52 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn1-546.cisco.com [10.21.98.34]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOI49317; Wed, 10 Dec 2003 08:44:49 -0800 (PST) Message-Id: <6.0.1.1.2.20031210111917.048e28c0@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Dec 2003 11:34:12 -0200 To: Mpierce1@aol.com From: Fred Baker Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) Cc: christopher.eagan@lmco.com, jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org In-Reply-To: <1d0.15c56007.2d07886c@aol.com> References: <1d0.15c56007.2d07886c@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 06:19 PM 12/9/2003, Mpierce1@aol.com wrote: >Besides the problem you noted above with this method of dealing with >congestion (packet loss), there is also the problem that it can not >function in a multi-precedence level environment without a selective >packet discard mechanism as defined in MLEF. You will note in the draft you pulled that text from (draft-baker-tsvwg-mlpp-that-works-00.txt), that I suggested that an extension to SRTCM or TRTCM, involving a color-aware mode with N colors, could be used with this, and would address situations where routing changed. Something with MLEF that you want to seriously consider are "how do I know what number of calls to configure to police to" if there is no routing-aware CAC is that the numbers can be pretty seriously wrong, because there is no way to tell how to make them right. Even with RSVP-or-some-thing-like-it going along the path, if you are policing to the number of calls that have been admitted on each precedence level, if routing changes (say "manet") the numbers will be wrong until RSVP adjusts to track routing. MLEF as specified permits one packet in the queue per call allocated in each level. If two FO calls were admitted on one path, setting the policer to look for two calls, and one FO call was admitted on another path, and routing changed combining the paths, your policer would only allow packets from two of the calls at any given time. SRTCM/TRTCM would downgrade the second packets but keep them alive, which is closer to (although not exactly) what you want. In CAC procedures, I'm looking for something deterministic (if M calls need to be dropped, drop exactly M calls, and if a call needs to be refused, refuse it before it sends any data traffic, and do so according to a network-controlled policy as opposed to a policy enforced only by the end station), and something that is routing-aware - if I have three exit paths, it asks about the one being used and ignores the ones not being used. I am also looking for one that cannot be displaced from the end station or the routing path; in a manet case, the DNS model would in effect require DNS servers in each vehicle in order for the DNS server to be in any sense aware of the paths, but one would generally find two or three redundant servers, at least one being reachable via satcom "back at the ranch". Ditto a gate-keeper if call counting is what you have in mind. What I am very concerned about is that the CAC involved here doesn't meet the basic requirements to actually perform the service that MLPP performs. So exactly what CAC model do you have in mind? _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 10 13:51:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09324 for ; Wed, 10 Dec 2003 13:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9QM-0007Dd-NX for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 13:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIp2UL027743 for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 13:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9QK-0007CU-Ic; Wed, 10 Dec 2003 13:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9PV-0007C4-33 for tsvwg@optimus.ietf.org; Wed, 10 Dec 2003 13:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09240 for ; Wed, 10 Dec 2003 13:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9PS-0005cA-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 13:50:06 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AU9PS-0005bY-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 13:50:06 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Dec 2003 10:51:46 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBAInXAt002378; Wed, 10 Dec 2003 10:49:34 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn4-130.cisco.com [10.21.80.130]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOI65249; Wed, 10 Dec 2003 10:49:31 -0800 (PST) Message-Id: <6.0.1.1.2.20031210164120.056d6a78@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 10 Dec 2003 16:42:50 -0200 To: "Steve Silverman" From: Fred Baker Subject: RE: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) MLEF Thresholds Cc: , , , , In-Reply-To: References: <6.0.1.1.2.20031210111917.048e28c0@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 03:45 PM 12/10/2003, Steve Silverman wrote: >At the packet level, the MLEF PHB does not know >about calls, it just sees packets at each DSCP level. ok, so that brings us back to the fundamental concern, that it is designed for use in environments where congestive loss is normal, unlike EF, which is designed for an environment where bandwidth available exceeds offered load in anything resembling a normal circumstance. Nobody has yet responded to the math, or the fundamental system effects. All I have heard is handwaving about how it couldn't be that bad, because EF seems to work, but ignoring the fundamental reason why the military is concerned about call preemption. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Wed Dec 10 22:10:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02244 for ; Wed, 10 Dec 2003 22:10:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHDL-0005RC-O9 for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 22:10:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB3A7dI020903 for tsvwg-archive@odin.ietf.org; Wed, 10 Dec 2003 22:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHDG-0005QM-SZ; Wed, 10 Dec 2003 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHCv-0005Pe-BD for tsvwg@optimus.ietf.org; Wed, 10 Dec 2003 22:09:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02221 for ; Wed, 10 Dec 2003 22:09:37 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUHCr-0000zS-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 22:09:37 -0500 Received: from imo-r06.mx.aol.com ([152.163.225.102]) by ietf-mx with esmtp (Exim 4.12) id 1AUHCr-0000zG-00 for tsvwg@ietf.org; Wed, 10 Dec 2003 22:09:37 -0500 Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v36_r1.1.) id c.1c6.12ff93b7 (4468); Wed, 10 Dec 2003 22:05:46 -0500 (EST) Message-ID: <1c6.12ff93b7.2d09390a@aol.com> Date: Wed, 10 Dec 2003 22:05:46 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) To: fred@cisco.com CC: christopher.eagan@lmco.com, jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1c6.12ff93b7.2d09390a_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_1c6.12ff93b7.2d09390a_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Fred, Thanks for the detailed response and the time you're spending on this. In a message dated 12/10/2003 11:45:16 AM Eastern Standard Time, fred@cisco.com writes: You will note in the draft you pulled that text from (draft-baker-tsvwg-mlpp-that-works-00.txt), that I suggested that an extension to SRTCM or TRTCM, involving a color-aware mode with N colors, could be used with this, and would address situations where routing changed. [MAP] Yes, I noted that, and this was the subject of another e-mail, asking what was meant by that, especially the part about it being "trivially extended to an arbitrary number of colors". SRTCM and TRTCM are based on exactly three colors ("TC") which are derived from comparisons with CBS and EBS, so I don't see how they can be extended. If they were extended to 5 "colors" which are then used to determine discard probability (as I think you implied), it sounds a lot like MLEF. Something with MLEF that you want to seriously consider are "how do I know what number of calls to configure to police to" if there is no routing-aware CAC is that the numbers can be pretty seriously wrong, because there is no way to tell how to make them right. Even with RSVP-or-some-thing-like-it going along the path, if you are policing to the number of calls that have been admitted on each precedence level, if routing changes (say "manet") the numbers will be wrong until RSVP adjusts to track routing. [MAP] I think it is important to keep CAC (to limit new calls) and MLEF (to control packet discard) separate in this discussion, although it is fully agreed that MLEF can't work without an effective CAC. They're essentially on different "layers" and operate independently. Your first comment about needing to know how many calls to configure to police to and needing a "routing-aware CAC" would apply just as much to the non-MLEF case. This needs to be solved even without MLEF. Your comment about "policing to the number of calls" in this discussion about MLEF makes me think that we haven't described MLEF well enough. MLEF has nothing to do with "calls", since it operates in a router on individual packets. CAC does this policing on calls. [MAP] Yes, in the case of "manet" or any rearrangement of packet flows due to a failure, this could cause the numbers (of packet flows) to be wrong until something else changes, and it is MLEF that ensures that the packet flows for high priority calls still get through during that period (until CAC or preemption brings the numbers back in line). MLEF as specified permits one packet in the queue per call allocated in each level. If two FO calls were admitted on one path, setting the policer to look for two calls, and one FO call was admitted on another path, and routing changed combining the paths, your policer would only allow packets from two of the calls at any given time. [MAP] I'm not sure what you meant by the above, but it does not sound like the way MLEF is defined. If the limits set on the output queue, for example, are 10 for when a routine packet is being queued, and 11 for when a Priority packet is being queued, there can be more that 1 Priority packet in the queue at one time for more than 1 Priority call. I would not expect there to be more than 1 packet for the same call in the queue at the same time, Priority or not, since that might represent excessive delay. But, MLEF does not prevent this any more than EF did. It is unaware of which packets belong to the same flow (call). SRTCM/TRTCM would downgrade the second packets but keep them alive, which is closer to (although not exactly) what you want. [MAP] Not sure how one "degrades" a voice packet, but "keep them alive". I believe that at any point (in a router) there are only two choices for a voice packet: queue it or discard it. Just as described in EF, it can't be delayed by priority queuing or reordered. SRTCM/TRTCM gave the example of discarding "Red" packets and putting the "Yellow" ones in the "Best Effort Queue", which we can't do for voice packets. In CAC procedures, I'm looking for something deterministic (if M calls need to be dropped, drop exactly M calls, and if a call needs to be refused, refuse it before it sends any data traffic, and do so according to a network-controlled policy as opposed to a policy enforced only by the end station), and something that is routing-aware - if I have three exit paths, it asks about the one being used and ignores the ones not being used. I am also looking for one that cannot be displaced from the end station or the routing path; in a manet case, the DNS model would in effect require DNS servers in each vehicle in order for the DNS server to be in any sense aware of the paths, but one would generally find two or three redundant servers, at least one being reachable via satcom "back at the ranch". Ditto a gate-keeper if call counting is what you have in mind. What I am very concerned about is that the CAC involved here doesn't meet the basic requirements to actually perform the service that MLPP performs. So exactly what CAC model do you have in mind? [MAP] Clearly, we need to first agree on a definition of what CAC is. Is there one anyplace? I especially have a problem with including "dropping of calls" under "CAC" (since the "A" means "acceptance"). I would define CAC as those procedures/algorithms that decide whether or not a new call attempt can be setup. This would include authentication, restrictions of reachability, and bandwidth limitations. We should include the notion of forcing disconnect ("preemption") under a different term (not "CAC"). With that definition, I'm not sure what you would mean by a "model". This is largely dependent on the architecure. With the architecture described in one of my drafts, it is the assigned proxy server that performs the CAC function for the calling party. The proxy needs to know three things: - What route the packet flows will (likely) take - What the limits are for each link in the route - What the current load is on each link (e.g., number of packet flows or total committed rate) With Multilevel Precedence added, the above information for limits and loads would need to be known for each precedence level. Beyond that, one could define different algorithms for the ways that limits would be defined and applied. I'm working on a draft to descibe one such method. I also realize that a proxy knowing the above is a stretch, and I think your comments partly indicated that the above is impossible. If so, then CAC is impossible, and, if so, VoIP is impossible in any network which might experience congestion but which must provide "assured service" to some users. So I can rephrase your final sentence above as "What I am very concerned about is that the CAC involved here doesn't meet the basic requirements to actually perform the service that telephony performs." Mike Pierce --part1_1c6.12ff93b7.2d09390a_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Fred,

Thanks for the detailed response and the time you're spending on this.

In a message dated 12/10/2003 11:45:16 AM Eastern Standard Time, fred@ci= sco.com writes:


You will note in the draft you pulled that text from=20
(draft-baker-tsvwg-mlpp-that-works-00.txt), that I suggested that an=20
extension to SRTCM or TRTCM, involving a color-aware mode with N colors,= =20
could be used with this, and would address situations where routing chan= ged.

[MAP] Yes, I noted that, and this was the subject of another e-mail, ask= ing what was meant by that, especially the part about it being "trivially ex= tended to an arbitrary number of colors". SRTCM and TRTCM are based on exact= ly three colors ("TC") which are derived from comparisons with CBS and EBS,=20= so I don't see how they can be extended. If they were extended to 5 "colors"= which are then used to determine discard probability (as I think you implie= d), it sounds a lot like MLEF.


Something with MLEF that you want to seriously consider are "how do I kn= ow=20
what number of calls to configure to police to" if there is no=20
routing-aware CAC is that the numbers can be pretty seriously wrong,=20
because there is no way to tell how to make them right. Even with=20
RSVP-or-some-thing-like-it going along the path, if you are policing to=20= the=20
number of calls that have been admitted on each precedence level, if=20
routing changes (say "manet") the numbers will be wrong until RSVP adjus= ts=20
to track routing.=20

[MAP] I think it is important to keep CAC (to limit new calls) and MLEF=20= (to control packet discard) separate in this discussion, although it is full= y agreed that MLEF can't work without an effective CAC. They're essentially=20= on different "layers" and operate independently. Your first comment about ne= eding to know how many calls to configure to police to and needing a "routin= g-aware CAC" would apply just as much to the non-MLEF case. This needs to be= solved even without MLEF. Your comment about "policing to the number of cal= ls" in this discussion about MLEF makes me think that we haven't described M= LEF well enough. MLEF has nothing to do with "calls", since it operates in a= router on individual packets. CAC does this policing on calls.

[MAP] Yes, in the case of "manet" or any rearrangement of packet flows d= ue to a failure, this could cause the numbers (of packet flows) to be wrong=20= until something else changes, and it is MLEF that ensures that the packet fl= ows for high priority calls still get through during that period (until CAC=20= or preemption brings the numbers back in line).


MLEF as specified permits one packet in the queue per
call allocated in each level. If two FO calls were admitted=20= on one path,=20
setting the policer to look for two calls, and one FO call was admitted=20= on=20
another path, and routing changed combining the paths, your policer woul= d=20
only allow packets from two of the calls at any given time.

[MAP] I'm not sure what you meant by the above, but it does not sound li= ke the way MLEF is defined. If the limits set on the output queue, for examp= le, are 10 for when a routine packet is being queued, and 11 for when a Prio= rity packet is being queued, there can be more that 1 Priority packet in the= queue at one time for more than 1 Priority call. I would not expect there t= o be more than 1 packet for the same call in the queue at the same time, Pri= ority or not, since that might represent excessive delay. But, MLEF does not= prevent this any more than EF did. It is unaware of which packets belong to= the same flow (call).
=20

SRTCM/TRTCM would downgrade the second packets=20= but keep them alive, which is closer to=20
(although not exactly) what you want.

[MAP] Not sure how one "degrades" a voice packet, but "keep them alive".= I believe that at any point (in a router) there are only two choices for a=20= voice packet: queue it or discard it. Just as described in EF, it can't be d= elayed by priority queuing or reordered. SRTCM/TRTCM gave the example of dis= carding "Red" packets and putting the "Yellow" ones in the "Best Effort Queu= e", which we can't do for voice packets.


In CAC procedures, I'm looking for something deterministic (if M calls n= eed=20
to be dropped, drop exactly M calls, and if a call needs to be refused,=20
refuse it before it sends any data traffic, and do so according to a=20
network-controlled policy as opposed to a policy enforced only by the en= d=20
station), and something that is routing-aware - if I have three exit pat= hs,=20
it asks about the one being used and ignores the ones not being used. I=20= am=20
also looking for one that cannot be displaced from the end station or th= e=20
routing path; in a manet case, the DNS model would in effect require DNS= =20
servers in each vehicle in order for the DNS server to be in any sense=20
aware of the paths, but one would generally find two or three redundant=20
servers, at least one being reachable via satcom "back at the ranch". Di= tto=20
a gate-keeper if call counting is what you have in mind.

What I am very concerned about is that the CAC involved here doesn't mee= t=20
the basic requirements to actually perform the service that MLPP perform= s.

So exactly what CAC model do you have in mind?=20


[MAP] Clearly, we need to first agree on a definition of what CAC is. Is= there one anyplace? I especially have a problem with including "dropping of= calls" under "CAC" (since the "A" means "acceptance"). I would define CAC a= s those procedures/algorithms that decide whether or not a new call attempt=20= can be setup. This would include authentication, restrictions of reachabilit= y, and bandwidth limitations. We should include the notion of forcing discon= nect ("preemption") under a different term (not "CAC").

With that definition, I'm not sure what you would mean by a "model". Thi= s is largely dependent on the architecure. With the architecture described i= n one of my drafts, it is the assigned proxy server that performs the CAC fu= nction for the calling party. The proxy needs to know three things:
- What route the packet flows will (likely) take
- What the limits are for each link in the route
- What the current load is on each link (e.g., number of packet flows or= total committed rate)

With Multilevel Precedence added, the above information for limits and l= oads would need to be known for each precedence level. Beyond that, one coul= d define different algorithms for the ways that limits would be defined and=20= applied. I'm working on a draft to descibe one such method.

I also realize that a proxy knowing the above is a stretch, and I think=20= your comments partly indicated that the above is impossible. If so, then CAC= is impossible, and, if so, VoIP is impossible in any network which might ex= perience congestion but which must provide "assured service" to some users.

So I can rephrase your final sentence above as "What I am very concerned= about is that the CAC involved here doesn't meet the basic requirements to=20= actually perform the service that telephony performs."


Mike Pierce




--part1_1c6.12ff93b7.2d09390a_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 05:30:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24306 for ; Thu, 11 Dec 2003 05:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO56-0005MD-KM for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 05:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBAU4Um020587 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 05:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO53-0005L4-KT; Thu, 11 Dec 2003 05:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUO48-0005KM-AR for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 05:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24273 for ; Thu, 11 Dec 2003 05:29:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUO44-0007L9-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 05:29:00 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUO43-0007Kz-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 05:28:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 02:30:49 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBBASTAt020854; Thu, 11 Dec 2003 02:28:29 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn4-24.cisco.com [10.21.80.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOJ40042; Thu, 11 Dec 2003 02:28:26 -0800 (PST) Message-Id: <6.0.1.1.2.20031211080321.047bed50@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 11 Dec 2003 08:28:09 -0200 To: Mpierce1@aol.com From: Fred Baker Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) Cc: christopher.eagan@lmco.com, jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org In-Reply-To: <1c6.12ff93b7.2d09390a@aol.com> References: <1c6.12ff93b7.2d09390a@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 01:05 AM 12/11/2003, Mpierce1@aol.com wrote: >[MAP] Yes, I noted that, and this was the subject of another e-mail, >asking what was meant by that, especially the part about it being >"trivially extended to an arbitrary number of colors". SRTCM and TRTCM are >based on exactly three colors ("TC") which are derived from comparisons >with CBS and EBS, so I don't see how they can be extended. If they were >extended to 5 "colors" which are then used to determine discard >probability (as I think you implied), it sounds a lot like MLEF. It does. The difference is that if a high precedence session exists but doesn't have credits to support it, it is downgraded and survives rather than being dropped. >[MAP] Clearly, we need to first agree on a definition of what CAC is. Is >there one anyplace? I don't know of a formal definition anywhere. Informally, Call Admission Control is any procedure by which calls are individually considered, a policy is applied to them, and some are accepted and some aren't. This differs from packets being considered, and the only places I have ever seen the term applied apply it to a control plane procedure. There are several that are used in the industry: - ATM CAC is part of the method by which a VC is placed by the central VC routing system - H.323 has a call counting procedure in the gatekeeper. - SIP has a way of counting calls through a SIP Proxy - There is a procedure (name of the draft escapes me) that does a simple call counting procedure in a DNS server or proxy - RSVP/nsis offers a form of bandwidth admission with a fairly well-defined capability for preemption under a policy. > I especially have a problem with including "dropping of calls" under > "CAC" (since the "A" means "acceptance"). I would define CAC as those > procedures/algorithms that decide whether or not a new call attempt can > be setup. This would include authentication, restrictions of > reachability, and bandwidth limitations. We should include the notion of > forcing disconnect ("preemption") under a different term (not "CAC"). Maybe. If I look very hard at MLPP as specified for SS7, at least as I understand it, preemption is sort of a side effect of call admission; one first asks whether there is sufficient bandwidth for the call, if not one attempts to create the bandwidth by preempting another call, and depending on the success or failure of those steps, one finally accepts or does not accept the call. However, I tend to think that we could get into serious hair splitting very prematurely with this one. Bottom line, for your policy to work, both things need to happen, whatever we choose to call them. >With that definition, I'm not sure what you would mean by a "model". This >is largely dependent on the architecure. With the architecture described >in one of my drafts, it is the assigned proxy server that performs the CAC >function for the calling party. The proxy needs to know three things: >- What route the packet flows will (likely) take >- What the limits are for each link in the route >- What the current load is on each link (e.g., number of packet flows or >total committed rate) Yes. And this fact fairly severely limits the choices: the proxy server could easily be on the other side of the planet, and generally has no concept of the routing or current load. That is fairly problematic. >I also realize that a proxy knowing the above is a stretch, and I think >your comments partly indicated that the above is impossible. If so, then >CAC is impossible, and, if so, VoIP is impossible in any network which >might experience congestion but which must provide "assured service" to >some users. Not so. May I suggest that you re-read and comment on draft-baker-tsvwg-mlpp-that-works-00.txt? I provide exactly what you're asking for: - as many marks on data packets as you like - correct calculation of the policing limits for each mark - bandwidth and route aware CAC at the points that experience congestion - specific layered policy controlling same - lack of state in places that are not bandwidth constrained - refusal of a call before it transmits *any* data, protecting other calls from same It also happens to be (mostly, not the extended srtcm/trtcm part, and by the way there are other possible policing algorithms that we should perhaps discuss) implemented on a certain random vendor's router, and is standards-based as the bibliography of that document will attest. By the way, on the no-called extended srtcm/trtcm, I sketched together drafts for same. They're probably not in form to post yet, but this will give you the drift of that line of reasoning: ftp://ftpeng.cisco.com/fred/mlpp/mrmcm.html ftp://ftpeng.cisco.com/fred/mlpp/srmcm.html _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 06:48:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26208 for ; Thu, 11 Dec 2003 06:48:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPIZ-0007v5-2p for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 06:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBBm3h3030415 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 06:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPIW-0007ta-NW; Thu, 11 Dec 2003 06:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPHc-0007qy-Ad for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 06:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26159 for ; Thu, 11 Dec 2003 06:46:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPHX-0000rk-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 06:46:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUPHX-0000rb-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 06:46:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 03:48:49 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBBBkSZ0021666; Thu, 11 Dec 2003 03:46:28 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn1-136.cisco.com [10.21.96.136]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOJ42268; Thu, 11 Dec 2003 03:46:26 -0800 (PST) Message-Id: <6.0.1.1.2.20031211094032.0408e378@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 11 Dec 2003 09:46:19 -0200 To: Mpierce1@aol.com From: Fred Baker Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) Cc: christopher.eagan@lmco.com, jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org In-Reply-To: <6.0.1.1.2.20031211080321.047bed50@mira-sjc5-b.cisco.com > References: <1c6.12ff93b7.2d09390a@aol.com> <6.0.1.1.2.20031211080321.047bed50@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , At 08:28 AM 12/11/2003, Fred Baker wrote: >Not so. May I suggest that you re-read and comment on >draft-baker-tsvwg-mlpp-that-works-00.txt? I provide exactly what you're >asking for: > > - as many marks on data packets as you like > - correct calculation of the policing limits for each mark by the way, as I note in the draft, the actual value of marking the data packets is very limited. If we know that all data packets in a queue have been admitted by an admission policy implementing mlpp, no packet should ever be dropped as long as they all are sending at less than or equal to the rate they said they would send at - regardless of the marking policy. The only case I can think of where marking actually buys you anything is in the short interval between a routing change and rsvp admission tracking that routing change. In such a case, what the "extended srtcm/trtcm" model buys you is that preferred calls drop less packets than others. At this point, frankly, I'm splitting the difference with you - you want the marks real badly, and OK, I'll give them to you, but please don't take my doing so as an endorsement of a real need for them. I see little to no practical benefit in the presence of effective bandwidth admission (CAC). _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 08:42:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00084 for ; Thu, 11 Dec 2003 08:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUR4t-0004NB-Ns for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 08:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBDg3RR016803 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 08:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUR4r-0004Mr-OY; Thu, 11 Dec 2003 08:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUR4T-0004M9-RR for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 08:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00028 for ; Thu, 11 Dec 2003 08:41:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUR4S-0003fX-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 08:41:36 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AUR4R-0003eE-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 08:41:35 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id BC06E77A6D4; Thu, 11 Dec 2003 08:40:58 -0500 (EST) To: "Peterson, Jon" From: Mark Allman Reply-To: mallman@icir.org Cc: "'tsvwg@ietf.org'" Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lift Me Up Date: Thu, 11 Dec 2003 08:40:58 -0500 Message-Id: <20031211134058.BC06E77A6D4@guns.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: , > The chairs would like to announce a two-week Working Group Last Call > for draft-ietf-tsvwg-tcp-eifel-response-04, commencing on November > 26th and concluding on December 10th. Please send any final comments > relating to this document to the TSVWG mailing list. > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-04.t > xt I'm a day late. What's new?! For the most part I think this document is in quite good shape and should be forwarded. One thing I am sort of muddled on: - Section 4. Hm. I guess I am OK with this. I always worry about documents that say "you can do X" without really specifying a way to do it. But, we have done this before and I guess things have been scoped tightly enough to make it OK. I am flagging this for two reasons: - My thinking is fuzzy here as to whether this is OK or not. And, if anyone else has thoughts I think I'd love to hear them. - I do wonder, however, if it would be good to say something to the effect that we expect such algorithms to be brought up in the IETF. Does that make sense? A less fundemental issue: You mention that RFC3517 is conservative in that it has a dupthresh. But, some think that is a feature not a bug (i.e., when we mentioned removing that from the draft of 3517 a number of people yelled). So, I'd like to see some words stating the other side of the case (i.e., you have given one side, but I'd like to see something that says triggering on one dup ack has its own set of issues). Two things I think need attention: + In (STO.2) I think you should also include the bounds checks from (2.4) & (2.5) of RFC2988. I.e., if the RTO becomes too big or too small then it should be tweaked. (You don't have to include a huge explanation. I think it'd be fine to note that RFC2988 includes bounds checks that should be applied.) + In section 3.1 you note that the Eifel algorithm is used in response to "loss recovery". I'd prefer to see the language in the paragraph (second in 3.1) scrubbed to clearly indicate that you mean loss recovery detected by the RTO. And, then a few smaller comments that are not fundemental. I think they should be made, but ultimately if they are not the document is still OK and should move forward. = When discussing terminology you might note that IW is currently defined in RFC3390. = In (STO.1) I'd change "off the top" to "of previously unsent data" to make it explcitly clear what you mean. = In (STO.2) you should define "G" (the granularity, I assume). = In (ReCC) please define "bytes_acked". = In (CVW) it'd be nice to do a sentence that remind us what 'T_last' and 'tcpnow' actually mean (for the feeble minded like me!). = In section 3.2: "approach would be in place" --> "approach should be in place" = In 3.3.2: "likely to be off" --> "likely to be inaccurate" = In 3.3.2, second paragraph: it'd be nice to include a reminder that you're hacking the RTO components in this way because you don't have an accurate RTT-SAMPLE to go off of. = I'd re-title section 4. Maybe just drop "Non-Conservative". Something, though... it is pretty confusing. I hope this is useful. And, I hope the document can be forwarded for RFC publication very soon. It's time. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 08:52:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00449 for ; Thu, 11 Dec 2003 08:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUREc-0004jq-91 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 08:52:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBDq6Z3018191 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 08:52:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUREY-0004i8-2p; Thu, 11 Dec 2003 08:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUREW-0004hM-8U for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 08:52:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00392 for ; Thu, 11 Dec 2003 08:51:57 -0500 (EST) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUREU-0003xJ-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 08:51:58 -0500 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 1AUREU-0003wl-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 08:51:58 -0500 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r1.1.) id c.97.41df5a82 (16930); Thu, 11 Dec 2003 08:49:46 -0500 (EST) Message-ID: <97.41df5a82.2d09cffa@aol.com> Date: Thu, 11 Dec 2003 08:49:46 EST Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (3) MLEF Thres... To: fred@cisco.com, steves@shentel.net CC: christopher.eagan@lmco.com, jmpolk@cisco.com, tibodeau@cisco.com, tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_97.41df5a82.2d09cffa_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_97.41df5a82.2d09cffa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/10/2003 1:49:49 PM Eastern Standard Time, fred@cisco.com writes: > Nobody has yet responded to the math, or the fundamental system effects. > All I have heard is handwaving about how it couldn't be that bad, because > EF seems to work, but ignoring the fundamental reason why the military is > concerned about call preemption. > > [MAP] I'm not sure what the math is here that needs to be responded to. There were comments before (included some from me and in the MLEF draft) that used rather crude math for the situation that talked about 20 routine calls being 100% utilization and adding 1 priority call causing 5% packet loss. However, I realize that the real math is a little more complex, and is probably rather meaningless without actual traffic studies (or a very complex model). As you pointed out in your e-mail, "congestion" != "100% utilization" and " In the Internet, congestion is related to the probability of a significant queuing delay or the occurrence of packet loss, which is something that queuing theory tells me happens at a utilization rather lower than 100%." I believe that an actual simulation would show that, in order to meet a desired performance (lost packets, etc) that the traffic needs to be limited to maybe 70%. Adding 1 Priority call then brings it to 73.5%. Real simulations (or real live traffic) would be needed to determine what impact this has on packet loss rate. The 5% above is the layman's (mine) answer, but I suspect it is in the ballpark. In any case, going from 0% to 5% packet loss results in a drop in the MOS score from about 4.1 to 3.9 (for random loss) and to 3.3 (for bursty loss), according to your reference [18]. Certainly something DoD should accept as the price for getting a high priority call through. The point is that adjustment of the parameters (queue thresholds for MLEF) as well as the CAC limits will be done in real live networks with real traffic. Before that, if one decides what result they can tolerate (MOS degradation, length of impairment, blocked calls, etc.) one can also do simulations to approximate these limits. Mike Pierce --part1_97.41df5a82.2d09cffa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 12/10/= 2003 1:49:49 PM Eastern Standard Time, fred@cisco.com writes:


Nobody has yet responded to= the math, or the fundamental system effects.=20
All I have heard is handwaving about how it couldn't be that bad, becaus= e=20
EF seems to work, but ignoring the fundamental reason why the military i= s=20
concerned about call preemption.=20



[MAP] I'm not sure what the math is here that needs to be responded to.=20= There were comments before (included some from me and in the MLEF draft) tha= t used rather crude math for the situation that talked about 20 routine call= s being 100% utilization and adding 1 priority call causing 5% packet loss.=20= However, I realize that the real math is a little more complex, and is proba= bly rather meaningless without actual traffic studies (or a very complex mod= el). As you pointed out in your e-mail, "congestion" !=3D "100% utilization"= and " In the Internet, congestion is related to the probability of a signif= icant queuing delay or the occurrence of packet loss, which is something tha= t queuing theory tells me happens at a utilization rather lower than 100%."

I believe that an actual simulation would show that, in order to meet a=20= desired performance (lost packets, etc) that the traffic needs to be limited= to maybe 70%. Adding 1 Priority call then brings it to 73.5%. Real simulati= ons (or real live traffic) would be needed to determine what impact this has= on packet loss rate. The 5% above is the layman's (mine) answer, but I susp= ect it is in the ballpark. In any case, going from 0% to 5% packet loss resu= lts in a drop in the MOS score from about 4.1 to 3.9 (for random loss) and t= o 3.3 (for bursty loss), according to your reference [18]. Certainly somethi= ng DoD should accept as the price for getting a high priority call through.

The point is that adjustment of the parameters (queue thresholds for MLE= F) as well as the CAC limits will be done in real live networks with real tr= affic. Before that, if one decides what result they can tolerate (MOS degrad= ation, length of impairment, blocked calls, etc.) one can also do simulation= s to approximate these limits.

Mike Pierce
--part1_97.41df5a82.2d09cffa_boundary-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 11:15:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08268 for ; Thu, 11 Dec 2003 11:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTT0-0003Aw-QH for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 11:15:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBGF6lk012202 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 11:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTSv-00039z-8U; Thu, 11 Dec 2003 11:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTSE-00039G-3b for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 11:14:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08255 for ; Thu, 11 Dec 2003 11:14:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTSD-0007aa-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 11:14:17 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AUTSC-0007aX-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 11:14:16 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBBGDxI2004995; Thu, 11 Dec 2003 17:13:59 +0100 (MET) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7VT8LJ; Thu, 11 Dec 2003 17:13:58 +0100 Received: from EFT1701K2P109AD.ericsson.com (dhcp5-48.eed.ericsson.se [164.48.135.48]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id RAA28134; Thu, 11 Dec 2003 17:13:57 +0100 (MET) Message-Id: <5.2.0.9.0.20031211165134.02ba2d98@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 11 Dec 2003 17:13:57 +0100 To: mallman@icir.org, jon.peterson@neustar.biz From: Reiner Ludwig Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 Cc: tsvwg@ietf.org In-Reply-To: <20031211134058.BC06E77A6D4@guns.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Mark, thanks for your detailed review! All good points. A few comments to your comments below ... Jon, do you want me to submit a revised I-D, or is it OK to do the changes after we got feedback from the IESG? At 14:40 11.12.2003, Mark Allman wrote: >One thing I am sort of muddled on: > > - Section 4. [...] > - I do wonder, however, if it would be good to say something to > the effect that we expect such algorithms to be brought up in > the IETF. Does that make sense? I don't know since I don't know anybody at the moment who would like to pick this up. What if it never happens? As you say, we have it tightly scoped. So, maybe that's sufficient? > A less fundemental issue: You mention that RFC3517 is conservative > in that it has a dupthresh. But, some think that is a feature not a > bug (i.e., when we mentioned removing that from the draft of 3517 a > number of people yelled). We wrote: "However, in a more recent study [GL03], we found that the mentioned advanced loss recovery schemes are often too conservative to compete against TCP-Reno's blind go-back-N in terms of quickly recovering multiple losses after a spurious timeout." This is not saying that RFC3517's use of dupthresh is a bug. In fact, I also think it's a feature. It's just that in this particular situation, loss recovery after a spurious timeout, RFC3517 is often too slow to compete against Reno, and only in that situation do we suggest (in different words) to set dupthresh to one with RFC3517. >So, I'd like to see some words stating > the other side of the case (i.e., you have given one side, but I'd > like to see something that says triggering on one dup ack has its > own set of issues). Hmmm, I'm not yet convinced that such text should be added. I think that the "other side of the case" would refer to setting dupthresh to one during "normal" fast recovery, i.e., not involving a spurious timeout. But, that's out of scope for this doc. Don't you agree? >Two things I think need attention: > > + In (STO.2) I think you should also include the bounds checks from > (2.4) & (2.5) of RFC2988. I.e., if the RTO becomes too big or too > small then it should be tweaked. (You don't have to include a huge > explanation. I think it'd be fine to note that RFC2988 includes > bounds checks that should be applied.) OK. > + In section 3.1 you note that the Eifel algorithm is used in response > to "loss recovery". I'd prefer to see the language in the paragraph > (second in 3.1) scrubbed to clearly indicate that you mean loss > recovery detected by the RTO. OK. This is a leftover from previous versions that also dealt with spurious fast retransmits. >And, then a few smaller comments that are not fundemental. I think they >should be made, but ultimately if they are not the document is still >OK and should move forward. [...] All good points. I will change the text accordingly. ///Reiner _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 11 11:59:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09671 for ; Thu, 11 Dec 2003 11:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUU9a-0004tx-Ja for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 11:59:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBGx6Pp018833 for tsvwg-archive@odin.ietf.org; Thu, 11 Dec 2003 11:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUU9V-0004sy-9e; Thu, 11 Dec 2003 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUU8f-0004pr-8f for tsvwg@optimus.ietf.org; Thu, 11 Dec 2003 11:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09612 for ; Thu, 11 Dec 2003 11:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUU8d-0000k1-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 11:58:07 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AUU8d-0000jd-00 for tsvwg@ietf.org; Thu, 11 Dec 2003 11:58:07 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id AA8BB77A6D4; Thu, 11 Dec 2003 11:57:26 -0500 (EST) To: Reiner Ludwig From: Mark Allman Reply-To: mallman@icir.org Cc: jon.peterson@neustar.biz, tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <5.2.0.9.0.20031211165134.02ba2d98@mailhost.eed.ericsson.se> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lift Me Up Date: Thu, 11 Dec 2003 11:57:26 -0500 Message-Id: <20031211165726.AA8BB77A6D4@guns.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: , Reiner- > > A less fundemental issue: You mention that RFC3517 is conservative > > in that it has a dupthresh. But, some think that is a feature not a > > bug (i.e., when we mentioned removing that from the draft of 3517 a > > number of people yelled). > > We wrote: > "However, in a more recent study [GL03], we found that the mentioned > advanced loss recovery schemes are often too conservative to compete > against TCP-Reno's blind go-back-N in terms of quickly recovering > multiple losses after a spurious timeout." > > This is not saying that RFC3517's use of dupthresh is a bug. In fact, > I also think it's a feature. It's just that in this particular > situation, loss recovery after a spurious timeout, RFC3517 is often > too slow to compete against Reno, and only in that situation do we > suggest (in different words) to set dupthresh to one with RFC3517. But, the document says that reno is twice as fast as it should be (i.e., violates packet conservation). So, is it fair to compare 3517 against reno in terms of performance? > >So, I'd like to see some words stating > > the other side of the case (i.e., you have given one side, but I'd > > like to see something that says triggering on one dup ack has its > > own set of issues). > > Hmmm, I'm not yet convinced that such text should be added. I think > that the "other side of the case" would refer to setting dupthresh to > one during "normal" fast recovery, i.e., not involving a spurious > timeout. But, that's out of scope for this doc. Don't you agree? Not what I meant. Sorry. The draft says the problem with 3517 "is that it waits for three SACKs before it retransmits a lost segment". And, in response to that I say, * Yes, but that makes it more robust to reordering (per the community's current consensus on that topic, I think). * And, if this is a "problem" after an Eifel response then why isn't this a "general problem"? Maybe I just don't understand. Maybe you just need some more words to indicate why this case is different from more routine cases of loss recovery and so why it needs treated differently. In thinking about this and looking back over the draft, I think for me the last sentence I wrote is key. I think you should have to say why this situation is different from usual loss recovery and therefore why TCPs should be allowed/encouraged do something different in their loss recovery than they would otherwise do. If you can't make a clear statement about that then perhaps none of this belongs in this draft (i.e., then its just about "loss recovery" and really has little to do with the Eifel response). If you can write that down and show this is the case then I very well might agree with you -- but, I do not yet understand the need. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 12 13:36:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19429 for ; Fri, 12 Dec 2003 13:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs90-0000Mp-8q for tsvwg-archive@odin.ietf.org; Fri, 12 Dec 2003 13:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCIa63N001407 for tsvwg-archive@odin.ietf.org; Fri, 12 Dec 2003 13:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs8v-0000Li-Mx; Fri, 12 Dec 2003 13:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUs8J-0000LB-0M for tsvwg@optimus.ietf.org; Fri, 12 Dec 2003 13:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19415; Fri, 12 Dec 2003 13:35:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUs8G-0003fn-00; Fri, 12 Dec 2003 13:35:20 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AUs8F-0003fk-00; Fri, 12 Dec 2003 13:35:20 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hBCIZJs03597; Fri, 12 Dec 2003 10:35:19 -0800 (PST) Message-Id: <200312121835.hBCIZJs03597@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: Fri, 12 Dec 2003 10:35:18 -0800 Subject: [Tsvwg] RFC 3649 on HighSpeed TCP for Large Congestion Windows 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 3649 Title: HighSpeed TCP for Large Congestion Windows Author(s): S. Floyd Status: Experimental Date: December 2003 Mailbox: floyd@acm.org Pages: 34 Characters: 79801 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-highspeed-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3649.txt The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community. This document is a product of the Transport Area Working Group Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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: <031212103334.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3649 --OtherAccess Content-Type: Message/External-body; name="rfc3649.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031212103334.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Dec 13 16:17:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13903 for ; Sat, 13 Dec 2003 16:17:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVH8L-0002Bd-Gg for tsvwg-archive@odin.ietf.org; Sat, 13 Dec 2003 16:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBDLH5WL008401 for tsvwg-archive@odin.ietf.org; Sat, 13 Dec 2003 16:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVH8G-0002BJ-Vm; Sat, 13 Dec 2003 16:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVH7l-0002Au-N6 for tsvwg@optimus.ietf.org; Sat, 13 Dec 2003 16:16:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13884 for ; Sat, 13 Dec 2003 16:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVH7j-0000cs-00 for tsvwg@ietf.org; Sat, 13 Dec 2003 16:16:27 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AVH7j-0000cp-00 for tsvwg@ietf.org; Sat, 13 Dec 2003 16:16:27 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBDLGK8K006525; Sat, 13 Dec 2003 22:16:20 +0100 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7W452A; Sat, 13 Dec 2003 22:16:19 +0100 Received: from EFT1701K2P109AD.ericsson.com (rac166pc.edd.ericsson.se [164.48.123.166]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id WAA04953; Sat, 13 Dec 2003 22:16:15 +0100 (MET) Message-Id: <5.2.0.9.0.20031213201125.00ab2978@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 13 Dec 2003 21:15:32 +0100 To: mallman@icir.org From: Reiner Ludwig Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 Cc: tsvwg@ietf.org In-Reply-To: <20031211165726.AA8BB77A6D4@guns.icir.org> References: <5.2.0.9.0.20031211165134.02ba2d98@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Mark, The thinking behind Section 4 is as follows: If you are concerned that spurious timeouts in TCP may be a problem in a certain network environment then you should find that the Eifel Detection & Response is an effective solution. Ideally, you should still think that it's an effective solution if you have an environment where the spurious timeouts often coincide with multiple losses from the same flight of packets. But that's the problem. In the latter environment you can be better off performance-wise with pure Reno, i.e., is such environments Reno often out-performs Reno-Eifel. Even worse in such environments pure Reno often even out-performs RFC3517 (with or without Eifel) and NewReno-Eifel. So, you might think: "why bother using Eifel?". [In fact, in such environments you might also think: "why bother using RFC3517?"] As we wrote in Section 4, the reason for this "advantage" is Reno's blind go-back-N phase after a spurious timeout during which it breaks 'packet conservation'. So, it's an unfair advantage. We want to remove Reno's unfair advantage by promoting non-conservative loss recovery *after spurious timeouts* as outlined in Section 4. Then the statement "Eifel is an effective solution in environments with frequent spurious timeouts" would hold in general, i.e., independent of whether the spurious timeouts often coincide with multiple losses, or not. Had we put into RFC3517: "you MAY set dupthresh to 1 during loss recovery after a spurious timeout" then there would be no reason to include Section 4 in draft-ietf-tsvwg-tcp-eifel-response. Does this make it clearer? If yes, what's missing in Section 4? Coming back to something you wrote in a previous mail: 'I always worry about documents that say "you can do X" without really specifying a way to do it.' We didn't think about it before, but maybe one way to go in this Section 4 is to promote the use of RFC3517 with the addition that "you MAY set dupthresh to 1 during loss recovery after a spurious timeout". What do you think? ///Reiner At 17:57 11.12.2003, Mark Allman wrote: >Reiner- > > > > A less fundemental issue: You mention that RFC3517 is conservative > > > in that it has a dupthresh. But, some think that is a feature not a > > > bug (i.e., when we mentioned removing that from the draft of 3517 a > > > number of people yelled). > > > > We wrote: > > "However, in a more recent study [GL03], we found that the mentioned > > advanced loss recovery schemes are often too conservative to compete > > against TCP-Reno's blind go-back-N in terms of quickly recovering > > multiple losses after a spurious timeout." > > > > This is not saying that RFC3517's use of dupthresh is a bug. In fact, > > I also think it's a feature. It's just that in this particular > > situation, loss recovery after a spurious timeout, RFC3517 is often > > too slow to compete against Reno, and only in that situation do we > > suggest (in different words) to set dupthresh to one with RFC3517. > >But, the document says that reno is twice as fast as it should be (i.e., >violates packet conservation). So, is it fair to compare 3517 against >reno in terms of performance? > > > >So, I'd like to see some words stating > > > the other side of the case (i.e., you have given one side, but I'd > > > like to see something that says triggering on one dup ack has its > > > own set of issues). > > > > Hmmm, I'm not yet convinced that such text should be added. I think > > that the "other side of the case" would refer to setting dupthresh to > > one during "normal" fast recovery, i.e., not involving a spurious > > timeout. But, that's out of scope for this doc. Don't you agree? > >Not what I meant. Sorry. > >The draft says the problem with 3517 "is that it waits for three SACKs >before it retransmits a lost segment". And, in response to that I say, > > * Yes, but that makes it more robust to reordering (per the > community's current consensus on that topic, I think). > > * And, if this is a "problem" after an Eifel response then why isn't > this a "general problem"? > >Maybe I just don't understand. Maybe you just need some more words to >indicate why this case is different from more routine cases of loss >recovery and so why it needs treated differently. > >In thinking about this and looking back over the draft, I think for me >the last sentence I wrote is key. I think you should have to say why >this situation is different from usual loss recovery and therefore why >TCPs should be allowed/encouraged do something different in their loss >recovery than they would otherwise do. If you can't make a clear >statement about that then perhaps none of this belongs in this draft >(i.e., then its just about "loss recovery" and really has little to do >with the Eifel response). > >If you can write that down and show this is the case then I very well >might agree with you -- but, I do not yet understand the need. > >Thanks! > >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 15 10:05:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11217 for ; Mon, 15 Dec 2003 10:05:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuHc-0007Ap-6u for tsvwg-archive@odin.ietf.org; Mon, 15 Dec 2003 10:05:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFF5GOC027569 for tsvwg-archive@odin.ietf.org; Mon, 15 Dec 2003 10:05:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuHP-00079d-BT; Mon, 15 Dec 2003 10:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuGz-00078i-In for tsvwg@optimus.ietf.org; Mon, 15 Dec 2003 10:04:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11177 for ; Mon, 15 Dec 2003 10:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuGx-0006Fm-00 for tsvwg@ietf.org; Mon, 15 Dec 2003 10:04:35 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AVuGw-0006Fi-00 for tsvwg@ietf.org; Mon, 15 Dec 2003 10:04:34 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 3C7E077A6F9; Mon, 15 Dec 2003 10:04:00 -0500 (EST) To: Reiner Ludwig , "Jon Peterson" , "Allison Mankin" From: Mark Allman Reply-To: mallman@icir.org Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <5.2.0.9.0.20031213201125.00ab2978@mailhost.eed.ericsson.se> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Glory Days Date: Mon, 15 Dec 2003 10:04:00 -0500 Message-Id: <20031215150400.3C7E077A6F9@guns.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: , Reiner, Jon- After re-reading Reiner's note, section 4 of the Eifel reponse draft and making a pass at [GL03] (Gurtov/Ludwig, Infocom 2003) my own opinion about the draft being forwarded is: I believe the actual Eifel response specified in the document is well done. I believe it is clear, well-motivated and safe. However, I do not feel that the loss recovery modifications presented in section 4 of the document are either in-scope for the Eifel response nor are they appropriate changes to TCP loss recovery. Therefore, my own preference is for the document to go forward without section 4 (and, with several other agreed upon tweaks that I sent last week). Having said that, a few more detailed responses/points. First, I find nothing fundementally different about loss recovery after a (detected) spurious timeout than at any other point in the connection. When I originally read the draft I thought that somehow the Eifel response had created a unique situation in TCP that would require (or at least make desireable) some different form of loss recovery. However, from deeper thinking and more reading I cannot actually see such a unique situation. So, my opinion is that the Eifel response should say nothing about loss recovery (i.e., changing loss recovery is out-of-scope). I am not saying that the Eifel response does not *impact* loss recovery. I.e., if you compare reno to reno-with-eifel to sack to sack-with-eifel you may see different performance. I agree. But, that by itself does not argue that some form of advanced loss recovery is more or less appropriate. > We didn't think about it before, but maybe one way to go in this > Section 4 is to promote the use of RFC3517 with the addition that "you > MAY set dupthresh to 1 during loss recovery after a spurious > timeout". What do you think? I do not agree with this. I thought of this little scenario: Let's assume that this document (as is) becomes standard TCP behavior. And, further, that a student comes to me and says "hey, why is the dupthresh 1 here and 3 there?". I don't have a good answer to that question. If there was some unique situation created by the Eifel response so that I could say "because the Eifel response forces X and to deal with that we change dupthresh to one and it's OK because of Y" then that might be OK. But, from just looking at such a TCP connection trace it would not seem evident that the dupthresh should be different at different places. So, to me that says it should not be. Yes, one could explain it with a history lesson. But, I am not sure that the punch-line of the history lesson about reno and go-back-n is that dupthresh should be one not three. That takes a leap I am not willing to make. (Basically, you have argued that reno got it wrong in a number of ways (blind retransmission/go-back-n and breaking packet conservation). I buy that assertion. But, given that it got it wrong I am not necessarily willing to believe that it is the blue-ribbon standard that we should be shooting at. That doesn't necessarily seem appropriate to me.) And, two practical (i.e., non-philosophical) points... * I do not really understand why RFC3517 is going to take a whole lot longer with a dupthresh of 3 as opposed to 1. In the worst case where there is a massive hole in the sequence space and only one SACK block above it then you will likely see worse performance with dupthresh=3 than with dupthresh=1 (because at a minimum you'll take two RTTs to determine a lot of loss happened; and in doing so a timeout may occur). But, I doubt this is the common case. And, the case can actually happen anytime -- and, it stinks no matter when it happens. Why is it different if it happens immediately after a detected spurious timeout? I can't figure out that it does. * What is not mentioned in the i-d is that a dupthresh of one makes TCP less robust to reordering. Not that TCP is wonderfully robust to reordering now. But, I think we formed consensus when we wrote 3517 that threshold retransmission was the way to go. Further, some of the studies of reordering in the wild (e.g., the Partridge, et.al. paper in ToN in Dec/1999) suggest that reordering and congestion are correlated. So, if you have loss you may be more likely to also have reordering. Hence, it might not be the time to reduce TCP's (limited) ability to cope with reordering. One could sketch a case with reordering during this phase of the connection that may well yield performance implications just as bad as the worst case from the above bullet, IMO. All things considered I just don't understand why this section should be included in the document to begin with. And, then I don't agree with the mechanism that is included. So, FWIW, I vote to remove section 4. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 18 08:31:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21042 for ; Thu, 18 Dec 2003 08:31:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyF8-0001hW-5m for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 08:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDV6RS006532 for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 08:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyF4-0001g9-07; Thu, 18 Dec 2003 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyEi-0001fW-1H for tsvwg@optimus.ietf.org; Thu, 18 Dec 2003 08:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20987 for ; Thu, 18 Dec 2003 08:30:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyEY-0000u3-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 08:30:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyE8-0000tN-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 08:30:05 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AWyE7-0000sL-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 08:30:04 -0500 Received: from barkargrund-1.cs.helsinki.fi (barkargrund-1.cs.helsinki.fi [::ffff:128.214.48.25]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 18 Dec 2003 15:29:37 +0200 Received: from cs.helsinki.fi (localhost [127.0.0.1]) by barkargrund-1.cs.helsinki.fi (8.12.8/8.12.8) with ESMTP id hBIDTXKS001952; Thu, 18 Dec 2003 15:29:34 +0200 Message-ID: <3FE1ABBD.4030800@cs.helsinki.fi> Date: Thu, 18 Dec 2003 15:29:33 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020705 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 References: <20031215150400.3C7E077A6F9@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Mark- Sorry for joining the discussion late, but I think that Section 4 should be kept in, perhaps in somewhat revised form. Reno+SACK+TS after a spurious timeout uses "informed" go-back-N, i.e. it retransmits outstanding packets using slow start while skipping those packets that were known to be received by the sender (at least from the point when ACKs for original segments stop arriving). This approach recovers without a genuine timeout even if all but the oldest outstanding segment are lost. With Reno+SACK+TS+Eifel the transmission is resumed from the top and the loss recovery is based on fast retransmit and fast recovery that are less robust than Sack go-back-N. In particular it's needed to get three DUPACKs (which even with LT may require waiting for 3 RTTs) and Reno-Sack is likely to experience a genuine timeout in fast recovery in the presence of a significant amount of losses. This makes Reno+SACK+TS+Eifel more succeptible to genuine timeouts than Reno+SACK+TS that motivates the need for more effective loss recovery with Eifel. "Effective" does not need to be reducing dupthresh to one, but using NewReno-SACK is a good approach based on our experiements. Another reason for effective loss recovery with Eifel is that if the retransmit timer is made more conservative to avoid future spurious timeouts, then genuine timeouts should be prevented as much as possible because they are very costly. Andrei Mark Allman wrote: > Reiner, Jon- > > After re-reading Reiner's note, section 4 of the Eifel reponse draft and > making a pass at [GL03] (Gurtov/Ludwig, Infocom 2003) my own opinion > about the draft being forwarded is: > > I believe the actual Eifel response specified in the document is > well done. I believe it is clear, well-motivated and safe. > However, I do not feel that the loss recovery modifications > presented in section 4 of the document are either in-scope for the > Eifel response nor are they appropriate changes to TCP loss > recovery. Therefore, my own preference is for the document to go > forward without section 4 (and, with several other agreed upon > tweaks that I sent last week). > > Having said that, a few more detailed responses/points. > > First, I find nothing fundementally different about loss recovery after > a (detected) spurious timeout than at any other point in the connection. > When I originally read the draft I thought that somehow the Eifel > response had created a unique situation in TCP that would require (or at > least make desireable) some different form of loss recovery. However, > from deeper thinking and more reading I cannot actually see such a > unique situation. So, my opinion is that the Eifel response should say > nothing about loss recovery (i.e., changing loss recovery is > out-of-scope). > > I am not saying that the Eifel response does not *impact* loss recovery. > I.e., if you compare reno to reno-with-eifel to sack to sack-with-eifel > you may see different performance. I agree. But, that by itself does > not argue that some form of advanced loss recovery is more or less > appropriate. > > >>We didn't think about it before, but maybe one way to go in this >>Section 4 is to promote the use of RFC3517 with the addition that "you >>MAY set dupthresh to 1 during loss recovery after a spurious >>timeout". What do you think? > > > I do not agree with this. > > I thought of this little scenario: Let's assume that this document (as > is) becomes standard TCP behavior. And, further, that a student comes > to me and says "hey, why is the dupthresh 1 here and 3 there?". I don't > have a good answer to that question. If there was some unique situation > created by the Eifel response so that I could say "because the Eifel > response forces X and to deal with that we change dupthresh to one and > it's OK because of Y" then that might be OK. But, from just looking at > such a TCP connection trace it would not seem evident that the dupthresh > should be different at different places. So, to me that says it should > not be. > > Yes, one could explain it with a history lesson. But, I am not sure > that the punch-line of the history lesson about reno and go-back-n is > that dupthresh should be one not three. That takes a leap I am not > willing to make. (Basically, you have argued that reno got it wrong in > a number of ways (blind retransmission/go-back-n and breaking packet > conservation). I buy that assertion. But, given that it got it wrong I > am not necessarily willing to believe that it is the blue-ribbon > standard that we should be shooting at. That doesn't necessarily seem > appropriate to me.) > > And, two practical (i.e., non-philosophical) points... > > * I do not really understand why RFC3517 is going to take a whole lot > longer with a dupthresh of 3 as opposed to 1. In the worst case > where there is a massive hole in the sequence space and only one > SACK block above it then you will likely see worse performance with > dupthresh=3 than with dupthresh=1 (because at a minimum you'll take > two RTTs to determine a lot of loss happened; and in doing so a > timeout may occur). But, I doubt this is the common case. And, the > case can actually happen anytime -- and, it stinks no matter when it > happens. Why is it different if it happens immediately after a > detected spurious timeout? I can't figure out that it does. > > * What is not mentioned in the i-d is that a dupthresh of one makes > TCP less robust to reordering. Not that TCP is wonderfully robust > to reordering now. But, I think we formed consensus when we wrote > 3517 that threshold retransmission was the way to go. Further, some > of the studies of reordering in the wild (e.g., the Partridge, > et.al. paper in ToN in Dec/1999) suggest that reordering and > congestion are correlated. So, if you have loss you may be more > likely to also have reordering. Hence, it might not be the time to > reduce TCP's (limited) ability to cope with reordering. One could > sketch a case with reordering during this phase of the connection > that may well yield performance implications just as bad as the > worst case from the above bullet, IMO. > > All things considered I just don't understand why this section should be > included in the document to begin with. And, then I don't agree with > the mechanism that is included. So, FWIW, I vote to remove section 4. > > Thanks! > > allman > > > -- > Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 18 10:48:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29976 for ; Thu, 18 Dec 2003 10:48:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Nh-0000cP-Jo for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 10:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIFm5OU002373 for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 10:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Nc-0000bR-Jt; Thu, 18 Dec 2003 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Na-0000bA-KN for tsvwg@optimus.ietf.org; Thu, 18 Dec 2003 10:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29969 for ; Thu, 18 Dec 2003 10:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0NW-0002RN-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 10:47:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0NV-0002RG-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 10:47:54 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0NV-0002Q3-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 10:47:53 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1B3BA77A6F4; Thu, 18 Dec 2003 10:47:22 -0500 (EST) To: Andrei Gurtov From: Mark Allman Reply-To: mallman@icir.org Cc: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <3FE1ABBD.4030800@cs.helsinki.fi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Into the Great Wide Open Date: Thu, 18 Dec 2003 10:47:22 -0500 Message-Id: <20031218154722.1B3BA77A6F4@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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- Thanks for the note. > I think that Section 4 should be kept in, perhaps in somewhat revised > form. What sort of revision would you suggest? I didn't see anything in your note that deviated from the draft so I am confused. > Reno+SACK+TS after a spurious timeout uses "informed" go-back-N, > > [...] > > With Reno+SACK+TS+Eifel the transmission is resumed from the top Right. That seems like the key difference to me. But, I don't understand why that means that a different loss recovery strategy is in order (see below). > In particular it's needed to get three DUPACKs (which even with LT may > require waiting for 3 RTTs) and Reno-Sack is likely to experience a > genuine timeout in fast recovery in the presence of a significant > amount of losses. This makes Reno+SACK+TS+Eifel more succeptible to > genuine timeouts than Reno+SACK+TS that motivates the need for more > effective loss recovery with Eifel. I don't believe this. Sending "from the top" should trigger duplicate ACKs, too. And, those ACKs will help loss recovery along just fine. The only cases when 1 dupack is better (by any significant amount) than 3 dupacks is (a) when the window is really small or (b) when a massive amount of the window (or the corresponding ACKs) is lost. But, both of these are general issues. The fact that the eifel response calls for sending off the top does not matter because these segments still trigger dupacks (/SACKs). I do not think that Eifel vs. non-Eifel makes any difference in what the appropriate loss recovery strategy should be. So, let me try to be very clear: It's not that I believe these general issues are not important. To the contrary I have assisted on limited transmit and early retransmit to combat these sorts of situations. It's just that I do not believe there is anything Eifel-specific in the issues and therefore I think they should be addressed in a general way and not in the back of the Eifel response document. > Another reason for effective loss recovery with Eifel is that if the > retransmit timer is made more conservative to avoid future spurious > timeouts, then genuine timeouts should be prevented as much as > possible because they are very costly. This seems backwards to me. I think of RTOs as costly in any situation and so they should be avoided as much as possible. I would not say that the Eifel response makes the RTO "more conservative". I would say that the Eifel response makes the RTO "appropriately conservative". In other words, the RTO pre-Eifel was not correct (too aggressive), the connection figured this out and reset the RTO to something that is more legitimate. So, I don't understand how this adjustment to make the RTO accurate again is a reason to be more aggressive in our attempt to avoid RTOs. (Put another way the new timer is only "more conservative" when looked at in relation to something that was provably busted. So, why is this busted RTO a valid point of comparison?) Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Thu Dec 18 17:12:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24521 for ; Thu, 18 Dec 2003 17:12:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6NN-0003ki-Hm for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 17:12:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIMC9Uf014420 for tsvwg-archive@odin.ietf.org; Thu, 18 Dec 2003 17:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6NF-0003kB-HE; Thu, 18 Dec 2003 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6MH-0003j2-76 for tsvwg@optimus.ietf.org; Thu, 18 Dec 2003 17:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24439 for ; Thu, 18 Dec 2003 17:10:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6MF-0005Zj-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 17:10:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6MD-0005Zc-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 17:10:58 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AX6MC-0005ZZ-00 for tsvwg@ietf.org; Thu, 18 Dec 2003 17:10:56 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX6Lx-0004Tm-A2; Thu, 18 Dec 2003 22:10:41 +0000 To: tsvwg@ietf.org Cc: mankin@psg.com, jon.peterson@neustar.biz Reply-To: mankin@psg.com Date: Thu, 18 Dec 2003 14:10:41 -0800 From: Allison Mankin Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,BIZ_TLD autolearn=no version=2.60 Subject: [Tsvwg] Draft tsvwg meeting minutes 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: , TSVWG folks, Gorry Fairhurst took very good minutes from the IETF 58, and here they are after a few Chair edits for a quick review before the IETF proceedings CD-ROM deadline tomorrow (updates can happen after that, just not for the disk). Everyone who did not send viewgraphs, please do now! thanks! Allison and Jon IETF 58 - Monday, November 10 at 0900-1130 ========================================== Transport Area WG (tsvwg) Meeting minutes CHAIRS: Allison Mankin, AM Jon Peterson, JP Note taker: Gorry Fairhurst (gorry@erg.abdn.ac.uk) ----------------------- Charter Discussion for TCP working group creation (TCPM) (Jon Peterson) JP talked about proposed new charter to allow bug fixes/minor extensions to TCP and shepherding advancement of TCP documents along standards track. tsvwg charter is unchanged by this, remains focussed on tactical, homeless work. Q: Is PRSCTP not on the tsvwg charter? Ans: No, because the new charters do not contain items in final review. Colin Perkins: Let's be careful the TCPM charter doesn't suck up all the new research student's papers! AM: Yes. Large scale issues and major changes (such as FAST) will remain with tsvwg, that is, where there are wide considerations. The fixes, etc will go to tcpm. ------------------------ "Packet Drop" chunk type (Randall Stewart) http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-00.txt Talk about packet loss for satellite link, using a link protocol. For SCTP, this allows the link to distinguish between packet link loss and congestion loss. Matt Mathis: How much does SACK change the results? Ans: It accounts for most of the difference between TCP and SCTP. AM: Why didn't you use SACK ? Ans: We used what we had to hand. SCTP also takes more CPU, but this was not an issue in the presented results (for 2 Mbps). JP: Comments to the list please. ------------------------ Newreno Update (Sally Floyd) http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-01.txt Sally Floyd: New Reno has just completed last call. It was now widely deployed, but still an Experimental STD, so this propose to bring it to Proposed STD. Added text on FR; Impatient & slow and steady variants; etc. Mark Allman responded to WG Last call, and this has been incorporated. ------------------------ Reorder/Channel Errors (Sally Floyd for Bhandarkar/Reddy) http://www.ietf.org/internet-drafts/draft-bhandarkar-tcp-dcr-00.txt Sally: This is suggested to come to the meeting for discussion as an experimental ID. Comment: There is also a buffering issue (more packets) at the receiver too. This needs to be taken into the discussion. Q: There is an issue in that if you are not sending at a high rate, this is not necessarily a good thing, since it adds delay. Sally Floyd: Yes and also takes the hit in cwnd reduction. Q: What's the worse case RTO? - Where is the breakpoint? At what point does the RTT rise too far, impacting performance? Ans: The most aggressive RTO is at least twice the PRTT. Q: Link retransmission can make PRTT become highly variable. How do you take this into account? Ans: refer to authors... John Bennet: If you are only looking at re-odering, this is likely to be on a timescale that is much less than PRTT. Sally Floyd: As soon as they see a culmulative ACK, they react to it. John Bennet: If you knew it was only 20ms of reordering, you may like to just use this time? Sally Floyd: There are many papers in this spectrum - this is just one extreme. ------------------------ FAST TCP (Cheng/Low) http://www.ietf.org/internet-drafts/draft-jin-wei-low-tcp-fast-01.txt Should Fast TCP be an IETF Standard (which would be royalty free) or should it be open to commercialisation? - There's an IPR statement issued . Scott Bradner: What does the IPR statement do for people who wish to implement the draft, before it is an IETF STD? How does the IPR work out? Standards track process is not clear, full standard, etc. Ans: I don't know the details and logistics of the legal position. The intention is clear. Randall Stewart: I work on SCTP, does the IPR also cover SCTP? Would using it in SCTP violate the patent? Ans: The current IPR statement applies to TCP. Scott Bradner: Can we tweak the wording to say all "IETF Congestion Control" protocols? This constrains it currently to several transport protocols specified by the IETF, and protects from other uses outside of this scope (e.g. for specific corporate applications). Q: If you publish an open Linux source, there are rules for GNU license that need to be considered. Ans: We plan to publish the code, the IPR and open source code issues are different. Q: In this graph did you look at any packet drops? Ans: Not here. Q: Do you plan to show a mixture of FAST sharing with Linux and other TCPs? Ans: We could show one slide at the end. Q: So you're saying FAST is not fair to Reno? Ans: No, we can design for any solution. ...The open issue is how to select the correct parameters to achieve fairness.... Fred Baker: The simple answer is that Reno will push harder than FAST because of where the knee is. So FAST gives way to Reno when there is congestion. AM: Do the graphs show that FAST is giving way to Reno? Ans: Not these slides, I do have 1 slide (to show at the end). Matt Mathis: You didn't say that these results are for a lightly loaded network, so these are places where Reno does bad for other reasons. Q: What was the other traffic in the "background traffic" in the production network results? Ans: They were likely loaded research networks, we didn't have control of this background traffic. JP, AM: Let's give this some discussion on the list. AM: Suggest on list/next time it would be key to show cases with competing FAST and other TCP. ------------------------ Link-Up Notification (Spencer Dawkins) http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-linkup-01.txt Origins of work in PILC WG, and discussion in TrigTran BoF. LinkUp is now a notification, not a trigger, and it comes from an end host, not a middlebox. This is now a tsvwg list item. Comments requested: Security and Safeness considerations in the draft? Implementable in TCP? Interest form other transports Matt Mathhis: I don't understand where you have a problem: Is this where an ACK was sent on a link that went down and then was resent? That is, a duplicate ACK coming back which was the same ACK being sent twice? Ans: Notification is when you've lost a link for long enough to be in RTO. Matt Mathhis: If this ACK is a duplicate of an already received ACK, then the sender RTO timer is not going to be running. If the RTO timer is running - there's outstanding data in flight. So there's not a problem. Ans: The situation I'm addressing is relevant to long-latency networks like GPRS, where a sender can send a fair number of packets that are still queued for a link when it went down - hence the RTO with a lengthy backoff. Mark: Let's talk about this afterwards. Ans: OK, Q: Is there an assumption that the link symmetrically goes up and down? Ans: Either the links go up and down symmetrically, or it's harder to send an ACK than a data segment, as in GPRS.. Q: Can you have links that revert to half duplex, when they fail? Ans: Not in the environments I've been working in, but we haven't considered all environments. This is one of the reasons to ask for input in TSVWG. Joe Touch: How long can you hold onto the packet? One router holds it - another path becomes available, data is exchanged, then the link is restored and trigger acts. What happens? Ans: The proposal does not address this question in this version of the draft. Joe Touch: we need also to consider possible insertion of data into the TCP stream at the wrong point (i.,e. data packets delayed more than one MSL could be spliced incorrectly into the receive data). Ans: Some cellular modems have been known to come up after days and send out queued packets, allsorts of things could happen. Ans: Some cellular modems have been known to come up after days and send out queued packets. The proposal does not address this question beyond current TCP. Joe Touch: Packets longer than a MSL should be dropped... Can we specify these devices MUST NOT hold onto packet state for more than the MSL? Ans: Makes sense, and will be included in the next version of the draft. Q: Can we get a sense of the applications where this is useful Ans: We've not characterised all types of links. AM: Is this TCP-specific really, does it apply to SCTP? Ans: SCTP seems to be most interested in link-down rather than link-up, because they have alternate paths that they can use, should a link fail. But this is our understanding of SCTP from a couple of IETFs back - we're still interested in hearing if this has changed. AM: Do we finish this here in tsvwg? Should it be in the new TCPM WG? Is it ready to be engineered? What other transports is this relevant to? Mark Handley: DCCP is also interested in link-triggers! It helps to try to design for the future, not just today's protocols. Ans: Agree. Chou: The same issue should also apply to SCTP. AM: There has been a fair amount of discussion at the IETF. Should this be a WG item (towards Experimental)? ------------------------ Early Retransmit (Mark Allman) http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-02.txt ------------------------ IPMP (Matthew Luckie) http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-02.txt Scott Bradner: This sounds like OAM for TCP? Ans: Not really,. Scott Bradner: I was not meaning to be derogatory, I think OAM can be useful. Ans: IPMP is different to the tunnel tracing protocols, for instance. Scott Bradner: OAM is about finding out what your customers are seeing. You have similar facilities for the TCP sender (rather than the carrier). It may be worth looking at the other view, there seems to be so much interest in OAM these days! AM: Can people read this ID and send their comments to the list? Comment: There is some relevant discussions on the IRTF measurements list. AM: That is an open list, anyone can see it. Do go to the IRTF list and look. ------------------------ RFC1323bis (David Borman) http://www.ietf.org/internet-drafts/draft-jacobson-tsvwg-1323bis-00.txt This document is well overdue for updating. Important issues need to be addressed. Sally Floyd: A non-issue that arises for large windows + timestamps that arises from the historical way we did things. There's going to be problems if you don't change the RTO value calculation which was traditionally (BSD) measured once per PRTT. You can end up using an RTO calculated only on the last few measurements. A simple fix is to change the RTO calculation to take it to account the more frequent information that is available with RTTM. Ans: Yes, this is a good thing to change, we'll add this to the list. Chair note: this work would go to the proposed new TCP working group. ------------------------ Priority Promotion Scheme (Naotaka MORITA) http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt Q: How is feedback provided on packet drops? Ans: In the work we use RTCP feedback (based on packet loss). Q: Looking at Security: how do you prevent a sender from just using a high priority? Ans: We use two boxes that monitor the correct behaviour of senders, and take action. JP: Can we take a hum on whether there is general interest in doing this in tsvwg. JP: There seems to be rough consensus on doing this in tsvwg. ------------------------ SCTP Chunk Authentication (Michael Tuexen) http://www.ietf.org/internet-drafts/draft-tuexen-sctp-auth-chunk-00.txt Q: Your bullet says an IPsec channel may be used to authenticate control chunks. Quite what do you mean by this? Michael Tuexen: I can authenticate an IP packet using IPsec - either all the packet contents or none of it...However, SCTP packets are made up of a sequence of packets or chunks. To use IPSEC needs me to look for a specific packet chunk in the payload. Is this possible? Can IPSEC look inside a packet? Comment: This is not possible, now. Q; Looking at the list of work (replay protection, specs, key negociation), a lot of this has been done in IPsec. If you use IPsec, you do have to secure every packet - that's good anyway. So what's the problem? Comment : There's a reliance on IP address for IPsec - it's better to fix IPsec than do something new. Michael Tuexen: If you do this, you need rekeying. Comment: Ideally you would split the IP address from the SPI values. If you know the ID of the sender then this is fine. Is this function used to add an address? - We don't want a user to see a leaked address and then be given the ability to hijack the session. Ans: Yes, that's the case. Q: How do we then rekey? Ans: This amounts to lots of work for TLS.... David Black: Extending IPsec is the best action, it makes the work more worthwhile. We should have a better way to setup the keys. there is a limit to the volume of information that you can send with one (manually configured) key, before it becomes a vulnerability Ans: Yes - let's not replicate work items... AM: This is a very lively discussion, but we have no time. This should be taken on the mailing list. Let's take this to the list and discuss the architecture and issues. It could be exciting. - ----------------------- De-correlated Loss Recovery (Yogesh Prem Swami) http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-02.txt http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-01.txt - ----------------------- Multi-link Transport (Hosei Matsuoka) http://www.ietf.org/internet-drafts/draft-matsuoka-multilink-transport-00.txt Randal Stewart: In SCTP, we looked into two networks using two (parallel) paths for SCTP. There are some very difficult scenarios, have you thought about the effect of where the bottlenecks may be in the network? Ans: The last hop link is not optimal. Signaling in the wireless link is helpful. Randal Stewart: That's just at the edge. What happens if we have a core network that adds a bottleneck in the centre of the network? - The potential scenarios become very significant... JP: This is really interesting, but we need to take it to the list, we are out of time. ------------------------ 11:38 Close of meeting _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------- End of Forwarded Message _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 09:38:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10418 for ; Fri, 19 Dec 2003 09:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLlU-000354-4I for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 09:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEc3Zm011823 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 09:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLlQ-00033o-RM; Fri, 19 Dec 2003 09:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLkd-0002nf-Sc for tsvwg@optimus.ietf.org; Fri, 19 Dec 2003 09:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10333 for ; Fri, 19 Dec 2003 09:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLkR-0004oZ-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 09:36:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLk1-0004oH-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 09:36:34 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AXLk1-0004nG-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 09:36:33 -0500 Received: from barkargrund-1.cs.helsinki.fi (barkargrund-1.cs.helsinki.fi [::ffff:128.214.48.25]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 19 Dec 2003 16:36:05 +0200 Received: from cs.helsinki.fi (localhost [127.0.0.1]) by barkargrund-1.cs.helsinki.fi (8.12.8/8.12.8) with ESMTP id hBJEa1gZ001745; Fri, 19 Dec 2003 16:36:01 +0200 Message-ID: <3FE30CD1.4070809@cs.helsinki.fi> Date: Fri, 19 Dec 2003 16:36:01 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020705 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 References: <20031218154722.1B3BA77A6F4@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 >>I think that Section 4 should be kept in, perhaps in somewhat revised >>form. > > > What sort of revision would you suggest? I didn't see anything in your > note that deviated from the draft so I am confused. Actually I'm happy with the present form. I just wanted to say that we are open minded about making a change if you think it's necessary. >>Reno+SACK+TS after a spurious timeout uses "informed" go-back-N, >> >>[...] >> >>With Reno+SACK+TS+Eifel the transmission is resumed from the top > > > Right. That seems like the key difference to me. But, I don't > understand why that means that a different loss recovery strategy is > in order (see below). Eifel is meant as a peformance enhancment, but if it's enabled with a Sack TCP connection running over a path with delay and losses it could actually *decrease* TCP throughput and goodput. Therefore I think it's reasonable to mention this problem in the document and recommend use of more effective error recovery strategies that allows Eifel to *improve* performance (to a greater extent than just the use of those recovery strategies alone would do). >>In particular it's needed to get three DUPACKs (which even with LT may >>require waiting for 3 RTTs) and Reno-Sack is likely to experience a >>genuine timeout in fast recovery in the presence of a significant >>amount of losses. This makes Reno+SACK+TS+Eifel more succeptible to >>genuine timeouts than Reno+SACK+TS that motivates the need for more >>effective loss recovery with Eifel. > > > I don't believe this. Sending "from the top" should trigger duplicate > ACKs, too. And, those ACKs will help loss recovery along just fine. True, but the problem with conservative Sack is that it often gets a genuine timeout on the first partial ACK because it assumes that lost segments are still in the network and the sender cannot retransmit packets. > The only cases when 1 dupack is better (by any significant amount) than > 3 dupacks is (a) when the window is really small or (b) when a massive > amount of the window (or the corresponding ACKs) is lost. But, both of > these are general issues. The fact that the eifel response calls for > sending off the top does not matter because these segments still trigger > dupacks (/SACKs). I do not think that Eifel vs. non-Eifel makes any > difference in what the appropriate loss recovery strategy should be. While it doesn't make difference in the *type* of appropriate loss recovery it does make difference on its *level* of importance. As a hypothetical example, consider that Sack TCP gets x kbps throughput, Sack+Eifel gets x-30% throughput, NR-Sack gets x+10% kbps and NR-Sack+Eifel gets x+100% kbps. Wouldn't it be wrong not to tell people that they *really* consider use of something else than Sack with Eifel because it makes a big difference in performance, although you are right that it might be a useful mechanism on its own? > So, let me try to be very clear: It's not that I believe these general > issues are not important. To the contrary I have assisted on limited > transmit and early retransmit to combat these sorts of situations. It's > just that I do not believe there is anything Eifel-specific in the > issues and therefore I think they should be addressed in a general way > and not in the back of the Eifel response document. But those "general issues" happen much more often with Eifel because it relies on fast transmit-derived recovery while standard Sack relies on "informed" go-back-N. I do believe that effective loss recovery is in a way *required* with Eifel. While we don't go in great detail of describing it in the document, we just mention the problem and suggest possible solutions. >>Another reason for effective loss recovery with Eifel is that if the >>retransmit timer is made more conservative to avoid future spurious >>timeouts, then genuine timeouts should be prevented as much as >>possible because they are very costly. > > > This seems backwards to me. I think of RTOs as costly in any situation > and so they should be avoided as much as possible. I would not say that > the Eifel response makes the RTO "more conservative". I would say that > the Eifel response makes the RTO "appropriately conservative". In other > words, the RTO pre-Eifel was not correct (too aggressive), the > connection figured this out and reset the RTO to something that is more > legitimate. So, I don't understand how this adjustment to make the RTO > accurate again is a reason to be more aggressive in our attempt to avoid > RTOs. (Put another way the new timer is only "more conservative" when > looked at in relation to something that was provably busted. So, why is > this busted RTO a valid point of comparison?) How about if link RTT is 1 second and the there are ocassional delay spikes of 10 s. Let's say the min RTO value is adapted to 10 s after a spurious timeout with Eifel. Then, any loss recovery through timeouts would be very inefficient (because "legitimate" RTO should be still 1 s in most of the time) and this is why a specific recommendation for use of effective loss recovery I believe is needed in the document. Without Eifel, a Sack TCP would be fine because it uses go-back-N and doesn't adapt the timer so it better avoids genuine timeouts *and* they are less costly than for Eifel. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 10:49:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13797 for ; Fri, 19 Dec 2003 10:49:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMsD-00065I-GN for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 10:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJFn5g0023366 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 10:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMsA-00064l-K2; Fri, 19 Dec 2003 10:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXMre-00064I-F6 for tsvwg@optimus.ietf.org; Fri, 19 Dec 2003 10:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13783 for ; Fri, 19 Dec 2003 10:48:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXMrc-00070G-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 10:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXMra-000709-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 10:48:27 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AXMra-0006zP-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 10:48:26 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1660377A6F7; Fri, 19 Dec 2003 10:47:55 -0500 (EST) To: Andrei Gurtov From: Mark Allman Reply-To: mallman@icir.org Cc: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <3FE30CD1.4070809@cs.helsinki.fi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Other Side Date: Fri, 19 Dec 2003 10:47:55 -0500 Message-Id: <20031219154755.1660377A6F7@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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- Thanks for the note. I think we have two different points of view here that are fundementally different and will prevent us from converging. You seem to be interested only in improving performance over current TCP. I agree that undo-ing sub-optimal performance caused by spurious timeouts is a good goal - even the primary goal. But, if there are cases when we do the Right Thing to the "detriment" of performance that seems fine, too. To be clear we're not talking about all of Eifel here. If Eifel always degraded performance than maybe there would be no reason for it (or, maybe there would be ... we could debate that, but it is academic at this point). We're only talking about Eifel when spurious timeouts and loss are mixed together. My fundemental problem with this entire line of thinking is my read of your comments and your draft as conflicting. On the one hand, you note that TCP's behavior is inappropriate after a spurious timeout (by using go-back-n to needlessly retransmit and by using slow start which piles too much into the network). Meanwhile, on the other hand, you are using the current (broken) TCP as the blue-ribbon standard and saying that we **need** performance that is at least as good if not better than current TCP. I cannot make those two lines of thinking converge in my head. It is a fine goal to improve performance. But, it is also a fine goal to transmit appropriately. If you can improve performance while being appropriate in your behavior then that's wonderful (e.g., the case of a spurious timeout, Eifel and no loss). But, if you can't improve performance in all cases then I don't think that means Eifel is a failure. I.e., we should not measure the goodness of things solely in terms of performance gain or loss. There are other metrics that are important, as well. Put another way, if I defined a scheme (call it Appalachian - doesn't roll off the tongue quite as well as Eifel, but the spirit is there ...) that said: If you see a spurious timeout: + immediately bump your cwnd & ssthresh back to what they were before this unneeded timeout + run go-back-n just in case there were losses + all the while increase cwnd per congestion avoidance Well, I'd say Appalachian would be a performance win over current TCP. Would that be OK? I hope we can agree that it would not be. And, it's not OK because performance is not the only metric we care about. > True, but the problem with conservative Sack is that it often gets a > genuine timeout on the first partial ACK because it assumes that lost > segments are still in the network and the sender cannot retransmit > packets. RFC3517 is quite aggressive about declaring things to have left the network within the confines of threshold retransmission (mostly) -- which is what I believe the community consensus was and is. I would be a little surprised (although not completely shocked) if you found a case when RFC3517's notion of the data still in the network is badly broken. And, furthermore, even if a TCP cannot retransmit because of threshold retransmission it can still send new data (and, if it can't send new data then threshold retransmission can be turned off). So, the connection is still making progress. I keep coming back to RFC3517 because Reiner offered that maybe your draft should say "use RFC3517 with a dupthresh of 1" (para-phrasing my impression of what Reiner said; I am too lazy to look up the exact words). Maybe that is not your opinion. But, I really don't understand what the practical difference between dupthresh=1 and dupthresh=3 is in terms of RFC3517 performance (except when faced with reordering). Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 11:09:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14311 for ; Fri, 19 Dec 2003 11:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNBY-0006yj-3p for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 11:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJG94YS026802 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 11:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNBV-0006xV-OE; Fri, 19 Dec 2003 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNBJ-0006xC-Lm for tsvwg@optimus.ietf.org; Fri, 19 Dec 2003 11:08:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14300 for ; Fri, 19 Dec 2003 11:08:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXNBH-0007Te-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:08:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXNBF-0007TX-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:08:46 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AXNBF-0007TU-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:08:45 -0500 Received: from barkargrund-1.cs.helsinki.fi (barkargrund-1.cs.helsinki.fi [::ffff:128.214.48.25]) (IDENT: root, AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 19 Dec 2003 18:08:44 +0200 Received: from cs.helsinki.fi (localhost [127.0.0.1]) by barkargrund-1.cs.helsinki.fi (8.12.8/8.12.8) with ESMTP id hBJG8hgZ001862; Fri, 19 Dec 2003 18:08:43 +0200 Message-ID: <3FE3228B.70409@cs.helsinki.fi> Date: Fri, 19 Dec 2003 18:08:43 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020705 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org CC: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 References: <20031219154755.1660377A6F7@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 > I think we have two different points of view here that are fundementally > different and will prevent us from converging. You seem to be > interested only in improving performance over current TCP. I agree that > undo-ing sub-optimal performance caused by spurious timeouts is a good > goal - even the primary goal. But, if there are cases when we do the > Right Thing to the "detriment" of performance that seems fine, too. To > be clear we're not talking about all of Eifel here. If Eifel always > degraded performance than maybe there would be no reason for it (or, > maybe there would be ... we could debate that, but it is academic at > this point). We're only talking about Eifel when spurious timeouts and > loss are mixed together. > > My fundemental problem with this entire line of thinking is my read of > your comments and your draft as conflicting. On the one hand, you note > that TCP's behavior is inappropriate after a spurious timeout (by using > go-back-n to needlessly retransmit and by using slow start which piles > too much into the network). Meanwhile, on the other hand, you are using > the current (broken) TCP as the blue-ribbon standard and saying that we > **need** performance that is at least as good if not better than current > TCP. I cannot make those two lines of thinking converge in my head. It > is a fine goal to improve performance. But, it is also a fine goal to > transmit appropriately. If you can improve performance while being > appropriate in your behavior then that's wonderful (e.g., the case of a > spurious timeout, Eifel and no loss). But, if you can't improve > performance in all cases then I don't think that means Eifel is a > failure. I.e., we should not measure the goodness of things solely in > terms of performance gain or loss. There are other metrics that are > important, as well. It appears the performance in this content refers to throughput. In our simulations using Eifel *with* effective loss recovery improved both throughput *and* goodput of TCP. Better goodput means that less segments are required to complete a connection = less load on the network. In the opposite, without effective loss recovery throughput *and* goodput are reduced. > Put another way, if I defined a scheme (call it Appalachian - doesn't > roll off the tongue quite as well as Eifel, but the spirit is there ...) > that said: > > If you see a spurious timeout: > + immediately bump your cwnd & ssthresh back to what they were > before this unneeded timeout > + run go-back-n just in case there were losses > + all the while increase cwnd per congestion avoidance > > Well, I'd say Appalachian would be a performance win over current TCP. > Would that be OK? I hope we can agree that it would not be. And, it's > not OK because performance is not the only metric we care about. That's certainly not what we want. Another extreme case would be just to use stop-and-wait by sending a single packet at a time and waiting for ack before transmitting a new one. > RFC3517 is quite aggressive about declaring things to have left the > network within the confines of threshold retransmission (mostly) -- > which is what I believe the community consensus was and is. I would be > a little surprised (although not completely shocked) if you found a case > when RFC3517's notion of the data still in the network is badly broken. > And, furthermore, even if a TCP cannot retransmit because of threshold > retransmission it can still send new data (and, if it can't send new > data then threshold retransmission can be turned off). So, the > connection is still making progress. I think RFC3517 makes conservative assumptions which is fine, but it's really useful to relax them for error recovery after a spurious timeout with Eifel. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 11:20:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14611 for ; Fri, 19 Dec 2003 11:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNMF-0007M2-Pb for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 11:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJGK741028227 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 11:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNMB-0007Jk-Rq; Fri, 19 Dec 2003 11:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNLj-0007Il-T1 for tsvwg@optimus.ietf.org; Fri, 19 Dec 2003 11:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14511 for ; Fri, 19 Dec 2003 11:19:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXNLi-0007fO-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:19:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXNLi-0007fH-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:19:34 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AXNLh-0007eq-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 11:19:34 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 2212277A6F7; Fri, 19 Dec 2003 11:19:03 -0500 (EST) To: Andrei Gurtov From: Mark Allman Reply-To: mallman@icir.org Cc: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <3FE3228B.70409@cs.helsinki.fi> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Other Side Date: Fri, 19 Dec 2003 11:19:03 -0500 Message-Id: <20031219161903.2212277A6F7@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , > It appears the performance in this content refers to throughput. In > our simulations using Eifel *with* effective loss recovery improved > both throughput *and* goodput of TCP. Better goodput means that less > segments are required to complete a connection = less load on the > network. In the opposite, without effective loss recovery throughput > *and* goodput are reduced. I'd rather not get into this, but the simulations of yours that I have read about do not include reordering -- which is what using a larger dupthresh buys you protection against. > I think RFC3517 makes conservative assumptions which is fine, but it's > really useful to relax them for error recovery after a spurious > timeout with Eifel. And, I don't think your simulations backup that statement because I don't think you used RFC3517. That is not to say: + That your simulations are junk. All simulations lack realism in some way or another. But, your simulations do not (IMO) speak to my point that threshold retrannsmission buys us something. + That is not to say that RFC3517 is mandatory. Or, that there are not other schemes that might be better or worse or perform differently in this case. But, trying to discuss them has a certain amount of fuzziness to it because they are not well specified, while RFC3517 is. + Reiner brough up the possibility of explicitly saying RFC3517 with dupthresh=1. And, so I am working off that and trying to understand what that might buy us -- and, from what I can see it would be very little. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 17:38:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00776 for ; Fri, 19 Dec 2003 17:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXTG3-0007bh-5Y for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 17:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJMc73e029238 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 17:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXTFw-0007Zy-PQ; Fri, 19 Dec 2003 17:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWdgJ-0006ei-Av for tsvwg@optimus.ietf.org; Wed, 17 Dec 2003 10:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14327 for ; Wed, 17 Dec 2003 10:33:43 -0500 (EST) From: Mikael.Latvala@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWdgG-0000pA-00 for tsvwg@ietf.org; Wed, 17 Dec 2003 10:33:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWdfz-0000nF-00 for tsvwg@ietf.org; Wed, 17 Dec 2003 10:33:43 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWdfy-0000n1-00 for tsvwg@ietf.org; Wed, 17 Dec 2003 10:33:26 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHFXO610408 for ; Wed, 17 Dec 2003 17:33:24 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 17 Dec 2003 17:33:20 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 17:33:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2003 17:33:19 +0200 Message-ID: <9B2635C00D654F4CA36B89C22364F0C30154B98E@esebe008.ntc.nokia.com> Thread-Topic: Establishment of SCTP association Thread-Index: AcPEsxj7vuBgDW6xRTKKeHDQ7ZBHTA== To: X-OriginalArrivalTime: 17 Dec 2003 15:33:19.0652 (UTC) FILETIME=[19248640:01C3C4B3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Tsvwg] Establishment of SCTP association Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, We noticed an interesting behaviour in Linux SCTP implementation.=20 1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source IP = address and IPb as a destination IP address 2. Endpoint B returns INIT ACK to endpoint A using IPc as a source IP = address and IPa as a destination IP address. IPb is included in INIT ACK = as an address parameter. 3. A and B finish the association negotiation, endpoint A using IPb as = its primary IP address and endpoint B using IPc as a source address when = it sends data chunks to endpoint A.=20 My question is: although RFRC2960 does not explicitly deny the use of = IPc as a source IP address in INIT ACK, when implementation does so, = doesn't this present a security hole in the association setup procedure? = Therefore such behaviour should not be allowed. For example, in a man-in-the-middle attack hostile node could highjack = the association by responding to INIT, which endpoint A sent, faster = than endpoint B, using hostile node's own IP address IPz as a source IP = address. Obviously this attack assumes that the endpoint A selects the = source IP address IPz as its primary IP address. /Mikael _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Fri Dec 19 19:24:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05580 for ; Fri, 19 Dec 2003 19:24:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXUub-0002SN-4y for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 19:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBK0O5T8009437 for tsvwg-archive@odin.ietf.org; Fri, 19 Dec 2003 19:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXUuX-0002R8-8r; Fri, 19 Dec 2003 19:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXUtq-0002Pn-5k for tsvwg@optimus.ietf.org; Fri, 19 Dec 2003 19:23:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05519 for ; Fri, 19 Dec 2003 19:23:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXUto-0001bF-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 19:23:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXUtn-0001b8-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 19:23:16 -0500 Received: from gw.openss7.com ([142.179.199.224] ident=[9cybYPQHgCFCfsEOheqk0MTRUDn8xjpW]) by ietf-mx with esmtp (Exim 4.12) id 1AXUtn-0001b0-00 for tsvwg@ietf.org; Fri, 19 Dec 2003 19:23:15 -0500 Received: from ns.pigworks.openss7.net (IDENT:tyRI1NFJeeqFM5njyqeq+2viSHuE4z0u@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id hBK0NEI25324; Fri, 19 Dec 2003 17:23:14 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id hBK0NEG10558; Fri, 19 Dec 2003 17:23:14 -0700 Date: Fri, 19 Dec 2003 17:23:13 -0700 From: "Brian F. G. Bidulock" To: Mikael.Latvala@nokia.com Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Establishment of SCTP association Message-ID: <20031219172313.B9619@openss7.org> Reply-To: bidulock@openss7.org References: <9B2635C00D654F4CA36B89C22364F0C30154B98E@esebe008.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B98E@esebe008.ntc.nokia.com>; from Mikael.Latvala@nokia.com on Wed, Dec 17, 2003 at 05:33:19PM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id hBK0NEI25324 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mikael.Latvala, I don't know about lksctp implementation, but we pretty much hashed out and plugged all those security holes in the Implementor's Guide. This behaviour is safe as long as the correct rules are followed with regard to handling of initialization procedures, cookies and tie tags. --brian On Wed, 17 Dec 2003, Mikael.Latvala@nokia.com wrote: > Hello, >=20 > We noticed an interesting behaviour in Linux SCTP implementation.=20 >=20 > 1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source I= P > address and IPb as a destination IP address >=20 > 2. Endpoint B returns INIT ACK to endpoint A using IPc as a source IP > address and IPa as a destination IP address. IPb is included in INIT AC= K as > an address parameter. >=20 > 3. A and B finish the association negotiation, endpoint A using IPb as = its > primary IP address and endpoint B using IPc as a source address when it > sends data chunks to endpoint A.=20 >=20 > My question is: although RFRC2960 does not explicitly deny the use of I= Pc as > a source IP address in INIT ACK, when implementation does so, doesn't t= his > present a security hole in the association setup procedure? Therefore s= uch > behaviour should not be allowed. >=20 > For example, in a man-in-the-middle attack hostile node could highjack = the > association by responding to INIT, which endpoint A sent, faster than > endpoint B, using hostile node's own IP address IPz as a source IP addr= ess. > Obviously this attack assumes that the endpoint A selects the source IP > address IPz as its primary IP address. >=20 > /Mikael >=20 > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Dec 20 07:05:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06565 for ; Sat, 20 Dec 2003 07:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXfr0-0001N6-0l for tsvwg-archive@odin.ietf.org; Sat, 20 Dec 2003 07:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKC55QP005268 for tsvwg-archive@odin.ietf.org; Sat, 20 Dec 2003 07:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXfqw-0001Lr-0b; Sat, 20 Dec 2003 07:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXfqK-0001LE-0e for tsvwg@optimus.ietf.org; Sat, 20 Dec 2003 07:04:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06533 for ; Sat, 20 Dec 2003 07:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXfqF-0006IA-00 for tsvwg@ietf.org; Sat, 20 Dec 2003 07:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXfqE-0006I2-00 for tsvwg@ietf.org; Sat, 20 Dec 2003 07:04:19 -0500 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AXfqE-0006Hz-00 for tsvwg@ietf.org; Sat, 20 Dec 2003 07:04:18 -0500 Received: from [10.0.1.2] (pD9FF1F2A.dip.t-dialin.net [217.255.31.42]) by mail-n.franken.de (Postfix) with ESMTP id 21C3B245C7; Sat, 20 Dec 2003 13:04:18 +0100 (CET) In-Reply-To: <9B2635C00D654F4CA36B89C22364F0C30154B98E@esebe008.ntc.nokia.com> References: <9B2635C00D654F4CA36B89C22364F0C30154B98E@esebe008.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AC45C76-32E4-11D8-83D7-000A95C37894@lurchi.franken.de> Content-Transfer-Encoding: 7bit Cc: From: Michael Tuexen Subject: Re: [Tsvwg] Establishment of SCTP association Date: Sat, 20 Dec 2003 13:03:10 +0100 To: Mikael.Latvala@nokia.com X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Mikael, a true man-in-middle can do everything: insert ABORTs when he wants and so on. And not allowing that the other IP address is used as a source address does not hel you. The true man in the middle can intercept the packet and return the INIT-ACK with B's address as a source address. In general: a true man-in-the-middle can do everything and there is not much a transport layer can do. You must have some mechanism to identify your peer not based on the IP address. Possibilities include IPSec or TLS. Best regards Michael On 17. Dec 2003, at 16:33 Uhr, Mikael.Latvala@nokia.com wrote: > Hello, > > We noticed an interesting behaviour in Linux SCTP implementation. > > 1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source > IP address and IPb as a destination IP address > > 2. Endpoint B returns INIT ACK to endpoint A using IPc as a source IP > address and IPa as a destination IP address. IPb is included in INIT > ACK as an address parameter. > > 3. A and B finish the association negotiation, endpoint A using IPb as > its primary IP address and endpoint B using IPc as a source address > when it sends data chunks to endpoint A. > > My question is: although RFRC2960 does not explicitly deny the use of > IPc as a source IP address in INIT ACK, when implementation does so, > doesn't this present a security hole in the association setup > procedure? Therefore such behaviour should not be allowed. > > For example, in a man-in-the-middle attack hostile node could highjack > the association by responding to INIT, which endpoint A sent, faster > than endpoint B, using hostile node's own IP address IPz as a source > IP address. Obviously this attack assumes that the endpoint A selects > the source IP address IPz as its primary IP address. > > /Mikael > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 22 10:15:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20565 for ; Mon, 22 Dec 2003 10:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRlz-0004ip-71 for tsvwg-archive@odin.ietf.org; Mon, 22 Dec 2003 10:15:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMFF7t2018147 for tsvwg-archive@odin.ietf.org; Mon, 22 Dec 2003 10:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRlv-0004hJ-La; Mon, 22 Dec 2003 10:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRlS-0004gA-MA for tsvwg@optimus.ietf.org; Mon, 22 Dec 2003 10:14:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20438 for ; Mon, 22 Dec 2003 10:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRlQ-0006Ee-00 for tsvwg@ietf.org; Mon, 22 Dec 2003 10:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRlP-0006EX-00 for tsvwg@ietf.org; Mon, 22 Dec 2003 10:14:31 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AYRlO-0006Dl-00 for tsvwg@ietf.org; Mon, 22 Dec 2003 10:14:31 -0500 Received: from BARKARGRUND1 (barkargrund-1.cs.helsinki.fi [::ffff:128.214.48.25]) by mail.cs.helsinki.fi with esmtp; Mon, 22 Dec 2003 17:14:13 +0200 Message-ID: <002901c3c89e$42a71520$1930d680@CSWin.cs.Helsinki.FI> From: "Andrei Gurtov" To: mallman@icir.org Cc: "Reiner Ludwig" , "Jon Peterson" , "Allison Mankin" , tsvwg@ietf.org References: <20031219161903.2212277A6F7@guns.icir.org> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 Date: Mon, 22 Dec 2003 17:14:14 +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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > It appears the performance in this content refers to throughput. In > > our simulations using Eifel *with* effective loss recovery improved > > both throughput *and* goodput of TCP. Better goodput means that less > > segments are required to complete a connection = less load on the > > network. In the opposite, without effective loss recovery throughput > > *and* goodput are reduced. > > I'd rather not get into this, but the simulations of yours that I have > read about do not include reordering -- which is what using a larger > dupthresh buys you protection against. It seems that having delays, losses *and* reordering at the same time may not be a common case. Furthermore, Linux TCP (that uses FACK by default) falls back to conservative SACK if any reordering is detected on a given TCP connection. If NewReno-SACK that is recommended by us has any trouble with reordering (I'm not sure it does) then it could do the same. > > I think RFC3517 makes conservative assumptions which is fine, but it's > > really useful to relax them for error recovery after a spurious > > timeout with Eifel. > > And, I don't think your simulations backup that statement because I > don't think you used RFC3517. We've used SACK from ns2 which is fairly close to RFC3517. Presumably, it's the responsibilty of RFC authors to keep the ns2 implementation up to date. I feel that arguments provided so far fairly well motivate the need of effective loss recovery with Eifel. So it looks to me as though there is lobbying against mentioning anything else but conservative SACK in RFCs. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Mon Dec 22 18:07:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15397 for ; Mon, 22 Dec 2003 18:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ8i-0005Me-Tg for tsvwg-archive@odin.ietf.org; Mon, 22 Dec 2003 18:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMN7474020603 for tsvwg-archive@odin.ietf.org; Mon, 22 Dec 2003 18:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ8e-0005Ks-TJ; Mon, 22 Dec 2003 18:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ8P-0005Ie-I2 for tsvwg@optimus.ietf.org; Mon, 22 Dec 2003 18:06:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15090 for ; Mon, 22 Dec 2003 18:06:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZ8M-0004kJ-01 for tsvwg@ietf.org; Mon, 22 Dec 2003 18:06:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZ7y-0004k8-00 for tsvwg@ietf.org; Mon, 22 Dec 2003 18:06:18 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AYZ7x-0004jn-00 for tsvwg@ietf.org; Mon, 22 Dec 2003 18:06:17 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 16A7677A70F; Mon, 22 Dec 2003 18:05:46 -0500 (EST) To: "Andrei Gurtov" From: Mark Allman Reply-To: mallman@icir.org Cc: "Reiner Ludwig" , "Jon Peterson" , "Allison Mankin" , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 In-Reply-To: <002901c3c89e$42a71520$1930d680@CSWin.cs.Helsinki.FI> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie Date: Mon, 22 Dec 2003 18:05:45 -0500 Message-Id: <20031222230546.16A7677A70F@guns.icir.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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- > We've used SACK from ns2 which is fairly close to RFC3517. Actually, it is not. They are similar in spirit, but not in some of the fundemental details --- which causes quite different behavior. For instance, you can see a section towards the end of the following paper to see a difference (it is only marginally related to this discussion, but the point is that the two algorithms are, in fact, quantitativly different and behaviorly different). Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates With TCP. ACM Performance Evaluation Review, 31(3), December 2003. http://www.icir.org/mallman/papers/least-per-dec2003.ps > Presumably, it's the responsibilty of RFC authors to keep the ns2 > implementation up to date. Hm. I was not aware of this requirement on RFC authors. > I feel that arguments provided so far fairly well motivate the need of > effective loss recovery with Eifel. I believe it is incumbant on the proposer of a special case in TCP to clearly motivate the need for the special case. My opinion is that section 4 of the draft in question does not fulfill that requirement. Further, I have talked to several others in the hopes that they might shed some light on blind spots in my thinking -- but, to my chagrin they have found section 4 confusing, as well (and, so (to their credit) they would not weigh in on whether they thought I was right or wrong about the need for a special case). (It would, BTW, be nice if others could voice their opinions on this since my comment here is just hersay.) So, I think ***at a minimum*** the draft needs to be updated in such a way that very clearly motivates the need (or desire) for a special case loss recovery after a spurious timeout has been detected. I.e., what sort of new dynamic does Eifel cause that warrents a special case? (If you can write such an explanation that'd be wonderful. Nothing in our exchange thus far has swayed me that there is an argument for a special case. That might actually be just faulty thinking on my part. If someone can clearly explain that Eifel causes some dynamic that needs compensated for then I may well be fine with an exception. It just has not yet happened. I've been dense before, though.) > So it looks to me as though there is lobbying against mentioning > anything else but conservative SACK in RFCs. I am not lobbying against any alternate loss recovery. I am lobbying against ***special case loss recovery***. There is a difference. The last thing we need to do is to be adding special cases all over the place. TCP is hard enough to get right. I am focused on RFC3517 because: (a) it is something that is specified and nailed down and can easily be discussed in concrete terms (unlike "FACK" or "SACK-NewReno" or "conservative SACK" which are all documented to some degree in papers or wherever, but are not rigorously outlined --- and mean different things inside different people's heads) (b) Reiner offered that RFC3517 with a dupthresh of 1 in loss following the Eifel response would be fine If the draft says "use of X general loss recovery technique (throughout the entire connection) works best with the Eifel response" then maybe that is OK (although, since that X will not be RFC3517 I am sure, that might get into a "normative reference" sort of issue). My heartburn is with the notion that we need to use different loss recovery at different times. That seems less than desireable -- and in need of clear and solid motivation. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From exim@www1.ietf.org Sat Dec 27 09:42:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12074 for ; Sat, 27 Dec 2003 09:42:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaFdn-0003Un-3d for tsvwg-archive@odin.ietf.org; Sat, 27 Dec 2003 09:42:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBREg7eC013434 for tsvwg-archive@odin.ietf.org; Sat, 27 Dec 2003 09:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaFdh-0003UP-00; Sat, 27 Dec 2003 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaFco-0003Rn-HO for tsvwg@optimus.ietf.org; Sat, 27 Dec 2003 09:41:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12052 for ; Sat, 27 Dec 2003 09:41:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaFcm-0007O8-00 for tsvwg@ietf.org; Sat, 27 Dec 2003 09:41:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaFav-0007Kt-00 for tsvwg@ietf.org; Sat, 27 Dec 2003 09:39:10 -0500 Received: from smtp.inet.fi ([192.89.123.192]) by ietf-mx with esmtp (Exim 4.12) id 1AaFZU-0007IJ-00 for tsvwg@ietf.org; Sat, 27 Dec 2003 09:37:40 -0500 Received: from cs.helsinki.fi (hoas-50dd0849.hoasnet.inet.fi [80.221.8.73]) by smtp.inet.fi (Postfix) with ESMTP id 888D55A3AA; Sat, 27 Dec 2003 16:37:37 +0200 (EET) Message-ID: <3FED9930.3090402@cs.helsinki.fi> Date: Sat, 27 Dec 2003 16:37:36 +0200 From: Andrei Gurtov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Cc: Reiner Ludwig , Jon Peterson , Allison Mankin , tsvwg@ietf.org Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04 References: <20031222230546.16A7677A70F@guns.icir.org> In-Reply-To: <20031222230546.16A7677A70F@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Mark- >>We've used SACK from ns2 which is fairly close to RFC3517. >> >> > >Actually, it is not. They are similar in spirit, but not in some of the >fundemental details --- which causes quite different behavior. For >instance, you can see a section towards the end of the following paper >to see a difference (it is only marginally related to this discussion, >but the point is that the two algorithms are, in fact, quantitativly >different and behaviorly different). > > Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates > With TCP. ACM Performance Evaluation Review, 31(3), December 2003. > http://www.icir.org/mallman/papers/least-per-dec2003.ps > > > >>Presumably, it's the responsibilty of RFC authors to keep the ns2 >>implementation up to date. >> >> > >Hm. I was not aware of this requirement on RFC authors. > > Are you saying that RFC3517 went to proposed standard without even an existing implemenation? Presumably extensive simulations of different possibilities are required before creating this "reference" version. It's surpising you did that without having an ns2 implementation. I think you are more demanding on our draft what is going to *experimental* than you were on PS RFC3517. >I think ***at a minimum*** the draft needs to be updated in such a way >that very clearly motivates the need (or desire) for a special case loss >recovery after a spurious timeout has been detected. I.e., what sort of >new dynamic does Eifel cause that warrents a special case? > > I can write a paragraph that would repeat the reasons that I've already given 1) reliance of Eifel on fast retransmit/fast recovery rather than "informed" go-back-N 2) frequent genuine timeouts for conservative SACK 3) need for making the retransmit timer more conservative with Eifel to avoid spurious timeouts 4) simulation results that show that effective error recovery improves throughput and goodput. I can rerun simulation tests using the exact RFC3517 SACK if an ns2 implemenation for it would be available. >I am not lobbying against any alternate loss recovery. I am lobbying >against ***special case loss recovery***. There is a difference. The >last thing we need to do is to be adding special cases all over the >place. TCP is hard enough to get right. I am focused on RFC3517 >because: > > IMHO it's a lot of debates that make it look complex. Adding NewReno-SACK to ns2 just took few lines of code. >(a) it is something that is specified and nailed down and can easily be > discussed in concrete terms (unlike "FACK" or "SACK-NewReno" or > "conservative SACK" which are all documented to some degree in > papers or wherever, but are not rigorously outlined --- and mean > different things inside different people's heads) > > We can add a strict definition of NewReno-SACK into the draft, but to me just a note looks sufficent saying that use of effective loss recovery is advantageous with Eifel. E.g. RFC3168 on AQM does not specifty anything exactly, but just discusses related issues. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg