RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
Janet Gunn <jgunn@ix.netcom.com> Tue, 03 February 2004 20:51 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00530 for <ieprep-archive@odin.ietf.org>; Tue, 3 Feb 2004 15:51:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7VG-0000O6-JB for ieprep-archive@odin.ietf.org; Tue, 03 Feb 2004 15:50:38 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KocLJ001486 for ieprep-archive@odin.ietf.org; Tue, 3 Feb 2004 15:50:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7VG-0000Nt-BC for ieprep-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:50: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 PAA00486 for <ieprep-web-archive@ietf.org>; Tue, 3 Feb 2004 15:50:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7VE-0001tA-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7UJ-0001ny-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:49:40 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Th-0001ip-00 for ieprep-web-archive@ietf.org; Tue, 03 Feb 2004 15:49:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Tg-0008TS-SW; Tue, 03 Feb 2004 15:49:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7TH-0008SR-PA for ieprep@optimus.ietf.org; Tue, 03 Feb 2004 15:48: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 PAA00331 for <ieprep@ietf.org>; Tue, 3 Feb 2004 15:48:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7TG-0001hP-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:48:34 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7SH-0001b5-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:47:34 -0500
Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7RN-0001Uu-00 for ieprep@ietf.org; Tue, 03 Feb 2004 15:46:37 -0500
Received: from huey.psp.pas.earthlink.net ([207.217.78.220]) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ao7R7-0004mu-00; Tue, 03 Feb 2004 12:46:21 -0800
Message-ID: <28213461.1075841181503.JavaMail.root@huey.psp.pas.earthlink.net>
Date: Tue, 03 Feb 2004 15:46:03 -0500
From: Janet Gunn <jgunn@ix.netcom.com>
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
To: steve.norreys@bt.com, jgunn6@csc.com
Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
Cc: ieprep@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
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
Content-Transfer-Encoding: 7bit
Steve, I completely agree that pre-emption has no role in ETS voice applications. In addition to (or perhaps in part because of) your points, anything resembling pre-emption on a service connected with the US PSTN is a political/legal non-starter. Even if the governement wanted it (which they don't) the provider's lawyers would soon put a stop to it. I was/am simply trying to extract anything that may be useful in the voice ETS domain from the discussion of MLPP over IP. HOWEVER- In a circuit switched network, if a link or node (switch) goes down, all calls using the node or link are lost. But in an IP network, if a link or switch goes down, it is possible to reroute the calls on the fly. If there is sufficient capacity, all is well, and all calls remain up, and intelligible. But if there is insufficient capacity available after rerouting, you have (at least) 3 choices 1) leave all the calls up, each one will have a significant drop rate, resulting in poor intelligibility. Hope that some of the calls will hang up and try again, leaving additional capacity for the calls that didn't hang up (the most stubborn users win). 2) randomly "shut down" affected calls, until the remaining calls have enough capacity to be intelligible. 3) use some sort of priority scheme to determine which calls to shut down and which to leave up. I don't think I would call any of those three options "pre-emption". Janet -----Original Message----- From: steve.norreys@bt.com Sent: Feb 3, 2004 10:42 AM To: jgunn6@csc.com Cc: ieprep@ietf.org Subject: RE: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Janet and all I have been biting my tongue (ops fingers) for some time now with regards to the MLPP service for supporting ETS in IP networks. As this service has a potential problem as shown by the following scenario: If a call/session is in progress between a non authorised ETS user and a emergency service then this should never be subject to pre-emption by a authorised ETS user, it could have fatal consequences. This by extension could be applied to a call/session in progress between non authorised ETS users, as this contact could be the only point of hope for someone in trouble. In other words the only justification for a pre-emption by a authorised ETS user is that it is only applied to call/session if both the content and context have been analysed. This seems to be a lot of work in a congested network. I have no problems with multiple precedence's or priorities if they are required but I only see the need for two a 'normal' call/session and a 'ETS' call/session. This shows that there maybe a need to take into account the consequences of the requirement to support MLPP especially in regard to pre-emption. Regards Steve Norreys Signalling and Protocols Tel: +441277323220 email steve.norreys@bt.com -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf Of Janet P Gunn Sent: 02 February 2004 22:13 To: Fred Baker Cc: ieprep@ietf.org Subject: References to MLPP that works Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Comments in line. ------------------------------------------------------------------------ ---------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ------------------------------------------------------------------------ ---------------- Fred Baker <fred @cisco.com> To: Janet P Gunn <jgunn6@csc.com> cc: ieprep@ietf.org 01/27/2004 09:35 Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt PM At 12:32 PM 1/27/2004, Janet P Gunn wrote: >As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call >admission is working properly, traffic marking is not needed in normal >operations. lest I be misunderstood, let me restate that. What I wrote was: One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. In retrospect, I wonder what the vice traffic would be :^) [jpg] Maybe all that "organ enlargement" spam? This is not to be understood as saying "no traffic marking is required"; one still needs RFC 3246. But if bandwidth admission is operating correctly, having N different marks will be operationally indistinguishable from having a single EF mark, as the total number of bytes on the wire will be the same. jpg], I did understand that. I was oversimplifying to make my point. >It is in this context that ETS calls must be given a high probability >of meeting the QoS criteria, even when network congestion and or damage >are severe. I wonder if we are communicating here. RFC 3246 is designed to operate in a congested network, and to operate in a network in which routing may change. The comment in the mlpp-that-works draft - which if it is giving cause for confusion I will happily remove - is basically me bending over backwards to be intellectually honest and see if I can find a case where CAC may be insufficient. [jpg] And I was blatantly taking advantage of your "bending over backwards" - to identify a case where CAC may not be sufficient for the ETS Voice application. Think about this for a moment: the argument being placed for MLEF is that even in the presence of some loss, voice is intelligible. If that is true, then just after a route change, during the brief interval between the data flow being switched to a new path and the CAC following that and either OKing the flow or deciding to shut down the call, when there may be some loss, voice should be equally intelligible, no? Or does the argument that voice is able to work around a modest level of loss only work when it comes from the proponents of multiple code points? [jpg] In the ETS voice scenario, I am NOT trying to say that "voice is able to work around a modest level of loss". I am taking the highly elitist position that, if there is a situation where SOME "calls" are going to have to lose packets, I want it to be the non-ETS calls (whether or not the non-ETS calls remain intelligible or not) that lose packets, and not the ETS calls. [jpg] I further agree that, in any situation where "calls" are losing packets, it is highly desirable to "do something" so that you have some calls that remain up and intelligible, and so that other calls go away, rather than using up bandwidth sending packets that are not "useful" from the end user's perspective. And whatever that "something" is, I want it to be able (assuming the appropriate business agreements are in place) to slant the odds in favor of the ETS calls being the ones that stay up and intelligible. Janet << Attachment Removed : C.DTF >> _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- References to MLPP that works Re: [Ieprep] I-D AC… Janet P Gunn
- RE: References to MLPP that works Re: [Ieprep] I-… steve.norreys
- RE: References to MLPP that works Re: [Ieprep] I-… Janet Gunn
- Re: References to MLPP that works Re: [Ieprep] I-… Fred Baker
- RE: References to MLPP that works Re: [Ieprep] I-… Ken Carlberg