Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

Fred Baker <fred@cisco.com> Wed, 28 January 2004 18:12 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17866 for <ieprep-archive@odin.ietf.org>; Wed, 28 Jan 2004 13:12:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluAM-0004GW-Bj for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:11:54 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIBsaH016390 for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:11:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluAM-0004GH-7f for ieprep-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:11:54 -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 NAA17863 for <ieprep-web-archive@ietf.org>; Wed, 28 Jan 2004 13:11:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluAK-00007L-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:11:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu9M-00000O-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:10:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alu8b-0007ih-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:10:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu8Z-00047P-9z; Wed, 28 Jan 2004 13:10:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu8C-00046F-OP for ieprep@optimus.ietf.org; Wed, 28 Jan 2004 13:09:40 -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 NAA17703 for <ieprep@ietf.org>; Wed, 28 Jan 2004 13:09:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu8A-0007f6-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:09:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu7C-0007Ub-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:08:39 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Alu6E-0007Fm-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:07:38 -0500
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2004 10:07:10 -0800
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SI74nI017937; Wed, 28 Jan 2004 10:07:07 -0800 (PST)
Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-604.cisco.com [10.21.66.92]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APS34422; Wed, 28 Jan 2004 10:06:47 -0800 (PST)
Message-Id: <6.0.1.1.2.20040127162316.048affd8@mira-sjc5-b.cisco.com>
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Date: Tue, 27 Jan 2004 16:35:49 -1000
To: Janet P Gunn <jgunn6@csc.com>
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
Cc: ieprep@ietf.org
In-Reply-To: <OFA4765B92.6CB64591-ON85256E28.001064C9-85256E28.007BD447@ csc.com>
References: <OFA4765B92.6CB64591-ON85256E28.001064C9-85256E28.007BD447@csc.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="-==-=-=-=======-=----===---=--=--=-=-==-===--=-="; protocol="application/pgp-signature"; micalg="pgp-sha1"
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=3.9 required=5.0 tests=AWL,DATE_IN_PAST_12_24, FORGED_MUA_EUDORA,INVALID_MSGID autolearn=no version=2.60

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 :^)

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.

>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.

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?