From exim@www1.ietf.org  Sun Nov  2 19:45:29 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01583
	for <ieprep-archive@odin.ietf.org>; Sun, 2 Nov 2003 19:45: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 1AGSqD-0003zD-7w
	for ieprep-archive@odin.ietf.org; Sun, 02 Nov 2003 19:45:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA30j9EP015319
	for ieprep-archive@odin.ietf.org; Sun, 2 Nov 2003 19:45:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSqD-0003z0-3X
	for ieprep-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 19:45: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 TAA01577
	for <ieprep-web-archive@ietf.org>; Sun, 2 Nov 2003 19:44:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSqB-00055V-00
	for ieprep-web-archive@ietf.org; Sun, 02 Nov 2003 19:45:07 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSqA-00055Q-00
	for ieprep-web-archive@ietf.org; Sun, 02 Nov 2003 19:45:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSq6-0003y6-F6; Sun, 02 Nov 2003 19:45:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSpC-0003x4-PX
	for ieprep@optimus.ietf.org; Sun, 02 Nov 2003 19:44:06 -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 TAA01559
	for <ieprep@ietf.org>; Sun, 2 Nov 2003 19:43:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSpA-00053X-00
	for ieprep@ietf.org; Sun, 02 Nov 2003 19:44:04 -0500
Received: from web11208.mail.yahoo.com ([216.136.131.190])
	by ietf-mx with smtp (Exim 4.12)
	id 1AGSpA-00053U-00
	for ieprep@ietf.org; Sun, 02 Nov 2003 19:44:04 -0500
Message-ID: <20031103004404.53969.qmail@web11208.mail.yahoo.com>
Received: from [66.142.54.110] by web11208.mail.yahoo.com via HTTP; Sun, 02 Nov 2003 16:44:04 PST
Date: Sun, 2 Nov 2003 16:44:04 -0800 (PST)
From: rohini rao <rohini517@yahoo.com>
To: ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1794199538-1067820244=:53716"
Subject: [Ieprep] (no subject)
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>

--0-1794199538-1067820244=:53716
Content-Type: text/plain; charset=us-ascii

hi
I would like to join in ieprep group.
thank you,
rohini,


---------------------------------
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
--0-1794199538-1067820244=:53716
Content-Type: text/html; charset=us-ascii

<DIV>hi</DIV>
<DIV>I would like to join in ieprep group.</DIV>
<DIV>thank you,</DIV>
<DIV>rohini,</DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
Exclusive Video Premiere - <a href="http://launch.yahoo.com/video/?1093432&fs=1&redirectURL=http://launch.yahoo.com/promos/britneyspears/">Britney Spears</a>
--0-1794199538-1067820244=:53716--

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



From exim@www1.ietf.org  Sun Nov  2 19:46:26 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01638
	for <ieprep-archive@odin.ietf.org>; Sun, 2 Nov 2003 19:46: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 1AGSr8-000462-4W
	for ieprep-archive@odin.ietf.org; Sun, 02 Nov 2003 19:46:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA30k6Ec015740
	for ieprep-archive@odin.ietf.org; Sun, 2 Nov 2003 19:46:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSr8-00045n-0K
	for ieprep-web-archive@optimus.ietf.org; Sun, 02 Nov 2003 19:46:06 -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 TAA01616
	for <ieprep-web-archive@ietf.org>; Sun, 2 Nov 2003 19:45:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSr2-00056I-00
	for ieprep-web-archive@ietf.org; Sun, 02 Nov 2003 19:46:01 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSr2-00056F-00
	for ieprep-web-archive@ietf.org; Sun, 02 Nov 2003 19:46:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSr3-00042b-A3; Sun, 02 Nov 2003 19:46:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AGSq9-0003yO-7P
	for ieprep@optimus.ietf.org; Sun, 02 Nov 2003 19:45:05 -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 TAA01571
	for <ieprep@ietf.org>; Sun, 2 Nov 2003 19:44:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AGSq7-00055M-00
	for ieprep@ietf.org; Sun, 02 Nov 2003 19:45:03 -0500
Received: from web11208.mail.yahoo.com ([216.136.131.190])
	by ietf-mx with smtp (Exim 4.12)
	id 1AGSq6-00055J-00
	for ieprep@ietf.org; Sun, 02 Nov 2003 19:45:02 -0500
Message-ID: <20031103004502.54108.qmail@web11208.mail.yahoo.com>
Received: from [66.142.54.110] by web11208.mail.yahoo.com via HTTP; Sun, 02 Nov 2003 16:45:02 PST
Date: Sun, 2 Nov 2003 16:45:02 -0800 (PST)
From: rohini rao <rohini517@yahoo.com>
To: ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1084853168-1067820302=:50833"
Subject: [Ieprep] like to join in ieprep group
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>

--0-1084853168-1067820302=:50833
Content-Type: text/plain; charset=us-ascii

hi
I would like to join in ieprep group.
thank you,
rohini,



---------------------------------
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
--0-1084853168-1067820302=:50833
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>hi</DIV>
<DIV>I would like to join in ieprep group.</DIV>
<DIV>thank you,</DIV>
<DIV>rohini,</DIV></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
Exclusive Video Premiere - <a href="http://launch.yahoo.com/video/?1093432&fs=1&redirectURL=http://launch.yahoo.com/promos/britneyspears/">Britney Spears</a>
--0-1084853168-1067820302=:50833--

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



From exim@www1.ietf.org  Wed Nov  5 00:56:23 2003
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24763
	for <ieprep-archive@odin.ietf.org>; Wed, 5 Nov 2003 00: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 1AHGeE-0005Wb-HG
	for ieprep-archive@odin.ietf.org; Wed, 05 Nov 2003 00:56:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA55u6wp021236
	for ieprep-archive@odin.ietf.org; Wed, 5 Nov 2003 00:56:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHGeE-0005WR-Az
	for ieprep-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 00:56:06 -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 AAA24757
	for <ieprep-web-archive@ietf.org>; Wed, 5 Nov 2003 00:55:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHGeB-0004rT-00
	for ieprep-web-archive@ietf.org; Wed, 05 Nov 2003 00:56:03 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHGeB-0004rP-00
	for ieprep-web-archive@ietf.org; Wed, 05 Nov 2003 00:56:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHGe9-0005Ve-R6; Wed, 05 Nov 2003 00: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 1AHGdU-0005Tk-OW
	for ieprep@optimus.ietf.org; Wed, 05 Nov 2003 00:55:20 -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 AAA24748
	for <ieprep@ietf.org>; Wed, 5 Nov 2003 00:55:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHGdR-0004r5-00
	for ieprep@ietf.org; Wed, 05 Nov 2003 00:55:17 -0500
Received: from sonnet1.is.dyncorp.com ([131.131.11.68])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHGdR-0004r2-00
	for ieprep@ietf.org; Wed, 05 Nov 2003 00:55:17 -0500
Received: from chntex04.is.dyncorp.com (chntex04.is.dyncorp.com [131.131.133.214])
	by sonnet1.is.dyncorp.com (8.12.8/8.12.8) with ESMTP id hA55tU81013830
	for <ieprep@ietf.org>; Wed, 5 Nov 2003 00:55:30 -0500 (EST)
Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2657.72)
	id <W1A0C2BR>; Wed, 5 Nov 2003 00:53:20 -0500
Message-ID: <5EA16A28B747E34FB90B578E6C5DDE890283B68F@chntex04.is.dyncorp.com>
From: "Gunn, Janet" <Janet.Gunn@DynCorp.com>
To: ieprep@ietf.org
Date: Wed, 5 Nov 2003 00:53:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Ieprep] New document on gap analysis for single "bridging" domain
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>

We have been working on a requirements/gap analysis for the same scenario
(Single telephony focused domain, with IP-bridging) as the paper I presented
at Vienna.  While we missed the deadline for IETF submission before the
Minneapolis meeting, we have posted it on our web site
https://gets-ic-pmo.dyncsc.com/ietf/formatted_draft-v1-gunn-ieprep-ip-teleph
ony-gap-00.doc

In particular, it describes some requirements that are specific to the
single domain scenario, and identifies gaps in MPLS and Diffserv to meeting
those requirements.

I am looking forward to your comments.

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



From exim@www1.ietf.org  Thu Nov  6 15:37:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29104
	for <ieprep-archive@odin.ietf.org>; Thu, 6 Nov 2003 15:37:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHqsd-0001YN-0N
	for ieprep-archive@odin.ietf.org; Thu, 06 Nov 2003 15:37:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6KbMtI005958
	for ieprep-archive@odin.ietf.org; Thu, 6 Nov 2003 15:37:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHqsc-0001Xn-7W
	for ieprep-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 15:37:22 -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 PAA29078
	for <ieprep-web-archive@ietf.org>; Thu, 6 Nov 2003 15:37:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHqsa-0007bg-00
	for ieprep-web-archive@ietf.org; Thu, 06 Nov 2003 15:37:20 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHqsW-0007bN-00
	for ieprep-web-archive@ietf.org; Thu, 06 Nov 2003 15:37:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHqsH-0001RD-5j; Thu, 06 Nov 2003 15:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHqrl-0001Mz-1p
	for ieprep@optimus.ietf.org; Thu, 06 Nov 2003 15:36: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 PAA28999
	for <ieprep@ietf.org>; Thu, 6 Nov 2003 15:36:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHqrj-0007aT-00
	for ieprep@ietf.org; Thu, 06 Nov 2003 15:36:27 -0500
Received: from mtassp3.ncr.disa.mil ([164.117.82.26] helo=pfwssp1.ncr.disa.mil)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHqrf-0007Zh-00
	for ieprep@ietf.org; Thu, 06 Nov 2003 15:36:23 -0500
Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 6 Nov 2003 15:34:34 -0500
Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19)
	id <WJ4AJM0B>; Thu, 6 Nov 2003 15:35:52 -0500
Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D07650FE8@emshqs1.ncr.disa.mil>
From: "Nguyen, An" <nguyena@ncs.gov>
To: ieprep@ietf.org
Date: Thu, 6 Nov 2003 15:35:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [Ieprep] Priority Promotion Scheme (PPS)
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>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Priority Promotion Scheme (PPS) may be of interest.=20

An

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

Abstract
   =20
   The Priority Promotion Scheme (PPS) is a new scheme for traffic=20
   control; more specifically, PPS involves applying a kind of =
admission=20
   control to achieve end-to-end QoS for a series of packets on a=20
   packet-based network.  The main targets are interactive multimedia=20
   services such as VoIP, video chat, and video conferencing.  The=20
   scheme is based on end-to-end measurement of network resources by =
end=20
   systems.  Before a session is established or even during a session,=20
   the source end system senses, measures, or probes the availability =
of=20
   network resources by sending out packets with priority one level=20
   lower than that of normal packets.  The result is modification of =
the=20
   DiffServ Code Point (DSCP) value of the succeeding IP packets: the=20
   priority is raised or promoted to firmly establish the session,=20
   lowered to leave resources with existing sessions, or otherwise=20
   adjusted so that the amount of packets does not exceed the available =

   capacity.  The network, i.e., output links of the routers or L2=20
   switches is only assumed to support the per-class form of priority=20
=20

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: Tuesday, November 04, 2003 10:08 AM
To: morita.naotaka@lab.ntt.co.jp
Cc: tsvwg@ietf.org
Subject: [Tsvwg] Comments on draft-morita-tsvwg-pps-01


Hello Naotaka,

your revised and new PPS related draft are marked=20
as TSV WG, but haven't been announced yet (at least I=20
couldn't find an announcement in the archive). After=20
reading both, I'm having some remarks, following below.

http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt

Remarks related to morita-tsvwg-pps-01:

While the draft is focused on terminals sending with=20
variable rates, the edge traffic control seems to assume=20
the peak rate as only parameter characterising the=20
controlled traffic. Further, section 8.4 demands=20
continuous sending of packets. Does that mean that=20
terminals sending with variable rates are expected=20
to continuosly create traffic at their peak rate if=20
they desire to use PPS?

Your third draft "Measurable Forwarding: A New per-Hop=20
Behavior (PHB)" wasn't listed in the "individual=20
submissions" section. If IETF didn't accept it this time,=20
a url to it would be useful as I think it helps=20
understanding pps operation.

The framework could put more emphasis on the "stateless=20
core" operation. This feature is a clear and very desirable=20
benefit of PPS against other signaling modes. It is=20
mentioned only once in section 4.2 so far.

I'll stop here and save minor and editorial comments for=20
a time when there's a clearer view on the future of PPS=20
within IETF.

Regards, R=FCdiger


R=FCdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com
=20

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



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



From exim@www1.ietf.org  Thu Nov  6 19:11:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09635
	for <ieprep-archive@odin.ietf.org>; Thu, 6 Nov 2003 19:11: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 1AHuDU-00084M-4L
	for ieprep-archive@odin.ietf.org; Thu, 06 Nov 2003 19:11:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hA70B8ZH031012
	for ieprep-archive@odin.ietf.org; Thu, 6 Nov 2003 19:11:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHuDU-000847-0x
	for ieprep-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 19:11: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 TAA09612
	for <ieprep-web-archive@ietf.org>; Thu, 6 Nov 2003 19:10:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHuDQ-0003IA-00
	for ieprep-web-archive@ietf.org; Thu, 06 Nov 2003 19:11:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHuDQ-0003I6-00
	for ieprep-web-archive@ietf.org; Thu, 06 Nov 2003 19:11:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHuDO-00082Z-H7; Thu, 06 Nov 2003 19:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AHuD6-00082A-QZ
	for ieprep@optimus.ietf.org; Thu, 06 Nov 2003 19:10:44 -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 TAA09605
	for <ieprep@ietf.org>; Thu, 6 Nov 2003 19:10:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHuD3-0003Hu-00
	for ieprep@ietf.org; Thu, 06 Nov 2003 19:10:41 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AHuD2-0003Hr-00
	for ieprep@ietf.org; Thu, 06 Nov 2003 19:10:40 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70AOUC014054;
	Fri, 7 Nov 2003 09:10:25 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70AOpo020057;
	Fri, 7 Nov 2003 09:10:24 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA70AO8H008473;
	Fri, 7 Nov 2003 09:10:24 +0900 (JST)
Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA13112;
	Fri, 7 Nov 2003 09:10:23 +0900 (JST)
Received: from morita-vaiodtop.lab.ntt.co.jp
	by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA06639;
	Fri, 7 Nov 2003 09:10:23 +0900 (JST)
Message-Id: <5.1.1.11.2.20031107090958.0455ae68@imj.m.ecl.ntt.co.jp>
X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5
Date: Fri, 07 Nov 2003 09:10:12 +0900
To: "Nguyen, An" <nguyena@ncs.gov>, ieprep@ietf.org
From: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Subject: Re: [Ieprep] Priority Promotion Scheme (PPS)
In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D07650FE8@emshqs1.ncr.disa.
 mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id hA70AOUC014054
Content-Transfer-Encoding: quoted-printable
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>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Thank you for your reference, An.

The following three documents are relevant to PPS.
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt

I am going to make a presentation on Monday morning at TSV WG.

Naotaka

At 15:35 03/11/06 -0500, Nguyen, An wrote:
 >Priority Promotion Scheme (PPS) may be of interest.
 >
 >An
 >
 >----------------------------------------------
 >
 >Abstract
 >
 >   The Priority Promotion Scheme (PPS) is a new scheme for traffic
 >   control; more specifically, PPS involves applying a kind of admissio=
n
 >   control to achieve end-to-end QoS for a series of packets on a
 >   packet-based network.  The main targets are interactive multimedia
 >   services such as VoIP, video chat, and video conferencing.  The
 >   scheme is based on end-to-end measurement of network resources by en=
d
 >   systems.  Before a session is established or even during a session,
 >   the source end system senses, measures, or probes the availability o=
f
 >   network resources by sending out packets with priority one level
 >   lower than that of normal packets.  The result is modification of th=
e
 >   DiffServ Code Point (DSCP) value of the succeeding IP packets: the
 >   priority is raised or promoted to firmly establish the session,
 >   lowered to leave resources with existing sessions, or otherwise
 >   adjusted so that the amount of packets does not exceed the available
 >   capacity.  The network, i.e., output links of the routers or L2
 >   switches is only assumed to support the per-class form of priority
 >
 >
 >-----Original Message-----
 >From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
 >Sent: Tuesday, November 04, 2003 10:08 AM
 >To: morita.naotaka@lab.ntt.co.jp
 >Cc: tsvwg@ietf.org
 >Subject: [Tsvwg] Comments on draft-morita-tsvwg-pps-01
 >
 >
 >Hello Naotaka,
 >
 >your revised and new PPS related draft are marked
 >as TSV WG, but haven't been announced yet (at least I
 >couldn't find an announcement in the archive). After
 >reading both, I'm having some remarks, following below.
 >
 >http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt
 >http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt
 >
 >Remarks related to morita-tsvwg-pps-01:
 >
 >While the draft is focused on terminals sending with
 >variable rates, the edge traffic control seems to assume
 >the peak rate as only parameter characterising the
 >controlled traffic. Further, section 8.4 demands
 >continuous sending of packets. Does that mean that
 >terminals sending with variable rates are expected
 >to continuosly create traffic at their peak rate if
 >they desire to use PPS?
 >
 >Your third draft "Measurable Forwarding: A New per-Hop
 >Behavior (PHB)" wasn't listed in the "individual
 >submissions" section. If IETF didn't accept it this time,
 >a url to it would be useful as I think it helps
 >understanding pps operation.
 >
 >The framework could put more emphasis on the "stateless
 >core" operation. This feature is a clear and very desirable
 >benefit of PPS against other signaling modes. It is
 >mentioned only once in section 4.2 so far.
 >
 >I'll stop here and save minor and editorial comments for
 >a time when there's a clearer view on the future of PPS
 >within IETF.
 >
 >Regards, R=1B$B=97E=1B(Biger
 >
 >
 >R=1B$B=97E=1B(Biger Geib
 >T-Systems
 >Systems Integration
 >Senior Expert, Technologiezentrum
 >Am Kavalleriesand 3, 64295 Darmstadt
 >Germany
 >Fon: +49 6151 832138
 >http://www.t-systems.com
 >
 >
 >_______________________________________________
 >tsvwg mailing list
 >tsvwg@ietf.org
 >https://www1.ietf.org/mailman/listinfo/tsvwg
 >
 >
 >
 >_______________________________________________
 >Ieprep mailing list
 >Ieprep@ietf.org
 >https://www1.ietf.org/mailman/listinfo/ieprep

----------------------------------
Naotaka MORITA, Senior Research Engineer, Supervisor
Network Service Systems Laboratories
Information Sharing Laboratory Group
NTT
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012
E-mail: morita.naotaka@lab.ntt.co.jp
MSN messenger: moritanaotaka@hotmail.com
NTT home page: http://www.ntt.co.jp/about/e/index.html=20



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



From exim@www1.ietf.org  Mon Nov 17 08:32:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11158
	for <ieprep-archive@odin.ietf.org>; Mon, 17 Nov 2003 08:32: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 1ALjU9-0006Yc-3C
	for ieprep-archive@odin.ietf.org; Mon, 17 Nov 2003 08:32:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDW9XM025200
	for ieprep-archive@odin.ietf.org; Mon, 17 Nov 2003 08:32:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALjU8-0006YN-Uc
	for ieprep-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 08:32: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 IAA11139
	for <ieprep-web-archive@ietf.org>; Mon, 17 Nov 2003 08:31:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALjU6-0006XQ-00
	for ieprep-web-archive@ietf.org; Mon, 17 Nov 2003 08:32:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALjU5-0006XK-00
	for ieprep-web-archive@ietf.org; Mon, 17 Nov 2003 08:32:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALjU1-0006Xb-4z; Mon, 17 Nov 2003 08:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ALjTH-0006Wx-Qb
	for ieprep@optimus.ietf.org; Mon, 17 Nov 2003 08:31:15 -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 IAA11106
	for <ieprep@ietf.org>; Mon, 17 Nov 2003 08:31:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALjTG-0006Wj-00
	for ieprep@ietf.org; Mon, 17 Nov 2003 08:31:14 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ALjTG-0006Wg-00
	for ieprep@ietf.org; Mon, 17 Nov 2003 08:31:14 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Mon, 17 Nov 2003 08:31:07 -0500
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003111708310715861
 for <ieprep@ietf.org>; Mon, 17 Nov 2003 08:31:07 -0500
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <W8X15XGH>; Mon, 17 Nov 2003 08:31:07 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D52006@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "Ieprep (E-mail)" <ieprep@ietf.org>
Date: Mon, 17 Nov 2003 08:31:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Ieprep] Measuring the 4:11 Effect: The Power Failure and the Internet
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>

FYI

http://www.computer.org/security/v1n5/j5mcg.htm



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



From exim@www1.ietf.org  Tue Nov 18 09:27:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21949
	for <ieprep-archive@odin.ietf.org>; Tue, 18 Nov 2003 09:27: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 1AM6os-0007bW-Hk
	for ieprep-archive@odin.ietf.org; Tue, 18 Nov 2003 09:27:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIER662029226
	for ieprep-archive@odin.ietf.org; Tue, 18 Nov 2003 09:27:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM6os-0007bJ-Ef
	for ieprep-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 09:27:06 -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 JAA21929
	for <ieprep-web-archive@ietf.org>; Tue, 18 Nov 2003 09:26:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM6oq-0005tL-00
	for ieprep-web-archive@ietf.org; Tue, 18 Nov 2003 09:27:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM6oq-0005tH-00
	for ieprep-web-archive@ietf.org; Tue, 18 Nov 2003 09:27:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM6on-0007aD-GJ; Tue, 18 Nov 2003 09:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM6nz-0007ZL-53
	for ieprep@optimus.ietf.org; Tue, 18 Nov 2003 09:26:15 -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 JAA21891
	for <ieprep@ietf.org>; Tue, 18 Nov 2003 09:25:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM6nx-0005sE-00
	for ieprep@ietf.org; Tue, 18 Nov 2003 09:26:09 -0500
Received: from mailgw1a.lmco.com ([192.31.106.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM6ns-0005sB-00
	for ieprep@ietf.org; Tue, 18 Nov 2003 09:26:04 -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 hAIEQ3oj002251
	for <ieprep@ietf.org>; Tue, 18 Nov 2003 07:26:03 -0700 (MST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HOJ00E01XFFKS@lmco.com> for ieprep@ietf.org;
 Tue, 18 Nov 2003 07:26:03 -0700 (MST)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760)
 with ESMTP id <0HOJ00LPQXFBN8@lmco.com> for ieprep@ietf.org; Tue, 18 Nov 2003 07:26:02 -0700 (MST)
Date: Tue, 18 Nov 2003 09:25:54 -0500
From: "Eagan, Christopher" <christopher.eagan@lmco.com>
To: ieprep@ietf.org
Message-id: <3F2F205501D3D411878C0008C7E6459410CFEC8C@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: MLPPoIP effort?
thread-index: AcOt4AjWwlMDZHdjTjGc9N8RhoZ0Gw==
Content-Class: urn:content-classes:message
Content-Transfer-Encoding: 7BIT
Subject: [Ieprep] MLPPoIP effort?
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>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Hello all,

I am just wondering about the group's interest in working on some specific MLPP over IP problems.  Obvisouly, the major push is the US and NATO's desire to use VoIP and their requirements of MLPP.  Besides this alone constituting a significant market for VoIP products, however, the fruits of such work could be a long term benefit to many other emergency communications areas such as local police, fire and rescue communications systems, and more general 911/999 systems.

Possible products of an MLPP over IP work:

- Requirements Document for MLPP over IP
- Identification of technologies to be used or any necessary protocol extensions
- Specification of protocols to use in MLPPoIP
- Specification of gateways between MLPP IP netwowks and other MLPP networks

There are several documents in the IETF related to various issues important to MLPP, but there does not seem to be a visible effort on building the 'whole system'.  Is there a possibility of unifying or co-parenting some of these efforts under the IEPREP umbrella?

Any thoughts, comments, and/or contstructive outrages are greatly appreciated.

Christopher Eagan
Software Engineer
Lockheed Martin
(301) 240 - 6328
christopher.eagan@lmco.com

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



From exim@www1.ietf.org  Tue Nov 18 10:51:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26753
	for <ieprep-archive@odin.ietf.org>; Tue, 18 Nov 2003 10:51:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM888-0003dO-VA
	for ieprep-archive@odin.ietf.org; Tue, 18 Nov 2003 10:51:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIFp4hG013964
	for ieprep-archive@odin.ietf.org; Tue, 18 Nov 2003 10:51:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM888-0003cP-QA
	for ieprep-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 10:51: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 KAA26734
	for <ieprep-web-archive@ietf.org>; Tue, 18 Nov 2003 10:50:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM883-0007Ga-00
	for ieprep-web-archive@ietf.org; Tue, 18 Nov 2003 10:50:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM883-0007GX-00
	for ieprep-web-archive@ietf.org; Tue, 18 Nov 2003 10:50:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AM884-0003bg-0H; Tue, 18 Nov 2003 10: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 1AM87L-0003Ze-MO
	for ieprep@optimus.ietf.org; Tue, 18 Nov 2003 10:50:15 -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 KAA26692
	for <ieprep@ietf.org>; Tue, 18 Nov 2003 10:50:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AM87J-0007FN-00
	for ieprep@ietf.org; Tue, 18 Nov 2003 10:50:13 -0500
Received: from phobos.simply.net ([81.3.64.11])
	by ietf-mx with smtp (Exim 4.12)
	id 1AM87I-0007Ei-00
	for ieprep@ietf.org; Tue, 18 Nov 2003 10:50:12 -0500
Received: (qmail 30567 invoked from network); 18 Nov 2003 15:49:35 -0000
Received: from pool-151-196-188-154.balt.east.verizon.net (HELO albers) (151.196.188.154)
  by phobos.simply.net with SMTP; 18 Nov 2003 15:49:35 -0000
From: "Ken Carlberg" <carlberg@g11.org.uk>
To: "'Eagan, Christopher'" <christopher.eagan@lmco.com>, <ieprep@ietf.org>
Subject: RE: [Ieprep] MLPPoIP effort?
Date: Tue, 18 Nov 2003 10:49:22 -0500
Message-ID: <000201c3adeb$8997e9a0$7301a8c0@albers>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <3F2F205501D3D411878C0008C7E6459410CFEC8C@emss09m06.ems.lmco.com>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

 
> There are several documents in the IETF related to various issues
> important to MLPP, but there does not seem to be a visible effort on
> building the 'whole system'.  Is there a possibility of unifying or
co-
> parenting some of these efforts under the IEPREP umbrella?

I assume you've read the following drafts.  These are individual
contributions, but they provide a starting point for what you may be
looking for.  The drafts will have the author's address, so feel free to
contact them directly.

	draft-pierce-ieprep-assured-service-req-01.txt
	draft-pierce-ieprep-assured-service-arch-01.txt
	draft-pierce-ieprep-pref-treat-examples-01.txt
	draft-polk-sipping-mlpp-reqs-01.txt

Of the items you mentioned below...

	- Requirements Document for MLPP over IP
	- Identification of technologies to be used or any necessary 
	  protocol extensions
	- Specification of protocols to use in MLPPoIP
	- Specification of gateways between MLPP IP netwowks and other 
	  MLPP networks

...the first two would seem to fall within the current the current
charter of IEPREP -- however, the ieprep chairs are a more definitive
authority on that issue.  For the last two, if by "specification" you
mean the definition of new protocols, then that would be out of the
current IEPREP charter and I would suggest speaking with an Area
Director for further advice.

My personal view is that if there is something specific that you feel is
missing or not addressed, its very helpful to put things in writing and
in the form of a draft-rfc.  That provides a tangible point for others
to examine and comment on (if they feel so inclined :-).  Note that
comments can be quite blunt and they generally arise on 3 occasions: the
introduction of a new draft, the request to make an individual
contribution into a working group item, and last call.  Its usually the
latter two that wake people up.

Regards,

-ken



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



From exim@www1.ietf.org  Wed Nov 19 09:56:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18903
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 09:56: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 1AMTkT-0006xO-C9
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 09:56:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEu5uL026738
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 09:56:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMTkT-0006xB-90
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:56:05 -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 JAA18894
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 09:55:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTkR-0000RP-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 09:56:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTkQ-0000RL-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 09:56:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMTkP-0006w3-3X; Wed, 19 Nov 2003 09: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 1AMTjl-0006vJ-Fm
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 09:55: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 JAA18869
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 09:55:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTjj-0000Qm-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 09:55:19 -0500
Received: from mailgw1a.lmco.com ([192.31.106.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMTjj-0000Qi-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 09:55: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 hAJEtHNK021438
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 07:55:17 -0700 (MST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HOL00J01TG4T4@lmco.com> for ieprep@ietf.org;
 Wed, 19 Nov 2003 07:55:16 -0700 (MST)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760)
 with ESMTP id <0HOL0002ZTFK7W@lmco.com> for ieprep@ietf.org; Wed, 19 Nov 2003 07:55:12 -0700 (MST)
Date: Wed, 19 Nov 2003 09:54:48 -0500
From: "Eagan, Christopher" <christopher.eagan@lmco.com>
Subject: [Ieprep] MLPPoIP effort?
To: ieprep@ietf.org
Message-id: <3F2F205501D3D411878C0008C7E6459410CFEC94@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: [Ieprep] MLPPoIP effort?
thread-index: AcOt6+utRKxPfadiTu+shCy3RRWsXgAve0ig
Content-Class: urn:content-classes:message
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>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Thanks Ken,

Yes, those are some of the drafts I was thinking of.  In addition, there is the traits-based-authorization* effort in the sipping wg and the mlef phb** draft that are applicable.  I guess the issue is, can we somehow unify, and invigorate some of these efforts under a common goal of MLPPoIP?  Is IEPREP the place to do it or should it be an additional working group?  The reason I wonder about a separate working group is that it appears IEPREP is focused on the Internet whereas the private networks deal with a more configurable environment (chairs?).

When I said "specification of protocols for MLPPoIP" I meant specifying a required behavior using existing protocols where possible, and specifying required extensions to protocols if necessary.

Chris

*http://www.ietf.org/internet-drafts/draft-peterson-sipping-role-authz-01.txt

**http://www.ietf.org/internet-drafts/draft-silverman-diffserv-mlefphb-02.txt

> -----Original Message-----
> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of
> Ken Carlberg
> Sent: Tuesday, November 18, 2003 10:49 AM
> To: Eagan, Christopher; ieprep@ietf.org
> Subject: RE: [Ieprep] MLPPoIP effort?
> 
> 
>  
> > There are several documents in the IETF related to various issues
> > important to MLPP, but there does not seem to be a visible effort on
> > building the 'whole system'.  Is there a possibility of unifying or
> co-
> > parenting some of these efforts under the IEPREP umbrella?
> 
> I assume you've read the following drafts.  These are individual
> contributions, but they provide a starting point for what you may be
> looking for.  The drafts will have the author's address, so 
> feel free to
> contact them directly.
> 
> 	draft-pierce-ieprep-assured-service-req-01.txt
> 	draft-pierce-ieprep-assured-service-arch-01.txt
> 	draft-pierce-ieprep-pref-treat-examples-01.txt
> 	draft-polk-sipping-mlpp-reqs-01.txt
> 
> Of the items you mentioned below...
> 
> 	- Requirements Document for MLPP over IP
> 	- Identification of technologies to be used or any necessary 
> 	  protocol extensions
> 	- Specification of protocols to use in MLPPoIP
> 	- Specification of gateways between MLPP IP netwowks and other 
> 	  MLPP networks
> 
> ...the first two would seem to fall within the current the current
> charter of IEPREP -- however, the ieprep chairs are a more definitive
> authority on that issue.  For the last two, if by "specification" you
> mean the definition of new protocols, then that would be out of the
> current IEPREP charter and I would suggest speaking with an Area
> Director for further advice.
> 
> My personal view is that if there is something specific that 
> you feel is
> missing or not addressed, its very helpful to put things in 
> writing and
> in the form of a draft-rfc.  That provides a tangible point for others
> to examine and comment on (if they feel so inclined :-).  Note that
> comments can be quite blunt and they generally arise on 3 
> occasions: the
> introduction of a new draft, the request to make an individual
> contribution into a working group item, and last call.  Its 
> usually the
> latter two that wake people up.
> 
> Regards,
> 
> -ken
> 
> 
> 
> _______________________________________________
> 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



From exim@www1.ietf.org  Wed Nov 19 10:40:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22526
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 10:40: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 1AMURD-00024o-SY
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:40:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFeFSF007837
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:40:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUR5-00022J-CJ
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:40: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 KAA22492
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 10:39:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUR2-0001Mw-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:40:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUR2-0001Mt-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:40:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUR2-00021c-Gg; Wed, 19 Nov 2003 10:40:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUQu-00020j-BV
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 10:39: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 KAA22483
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 10:39:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUQr-0001Mi-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:39:53 -0500
Received: from phobos.simply.net ([81.3.64.11])
	by ietf-mx with smtp (Exim 4.12)
	id 1AMUQr-0001MX-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:39:53 -0500
Received: (qmail 19608 invoked from network); 19 Nov 2003 15:39:21 -0000
Received: from pool-151-196-38-245.balt.east.verizon.net (HELO albers) (151.196.38.245)
  by phobos.simply.net with SMTP; 19 Nov 2003 15:39:21 -0000
From: "Ken Carlberg" <carlberg@g11.org.uk>
To: "'Eagan, Christopher'" <christopher.eagan@lmco.com>, <ieprep@ietf.org>
Subject: RE: [Ieprep] MLPPoIP effort?
Date: Wed, 19 Nov 2003 10:39:12 -0500
Message-ID: <000101c3aeb3$48616fb0$7301a8c0@albers>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3F2F205501D3D411878C0008C7E6459410CFEC94@emss09m06.ems.lmco.com>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I guess the issue is, can we somehow
> unify, and invigorate some of these efforts under a common goal of
> MLPPoIP?  Is IEPREP the place to do it or should it be an additional
> working group?  The reason I wonder about a separate working group is
that
> it appears IEPREP is focused on the Internet whereas the private
networks
> deal with a more configurable environment (chairs?).

personally, I'm not thrilled about the formation of another somewhat
related working group if a significant measure of its work involves
requirements.  Charters of existing working groups can be modified
within reason to take on new and related work, and I'd have a preference
for you trying to pursue that direction first with IEPREP and seeing the
reaction.  The decision on that request is predominantly one advocated
by the group as a whole, and the worst thing that happens is that the
answer is no.

However, the group (and I assume ADs as well) will find it very
difficult to make a decision without a draft-RFC to look at.  So I'll
just reiterate the request for you to put together a draft.  Drafts can
be quite informal, so perhaps you may want to add a temporary annex that
states where other drafts are a bit lacking.

> When I said "specification of protocols for MLPPoIP" I meant
specifying a
> required behavior using existing protocols where possible, and
specifying
> required extensions to protocols if necessary.

Its that latter item that will probably receive a lot of pushback within
IEPREP.  So if you want to add an extension to SIP, as an example,
you'll be redirected to take that to the SIPPING/SIP working group.

my 2 cents,

-ken



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



From exim@www1.ietf.org  Wed Nov 19 10:42:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22663
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 10:42: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 1AMUSw-0002B4-Ce
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:42:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFg2DP008364
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUSw-0002Ap-7C
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:42:02 -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 KAA22621
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 10:41:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUSt-0001Pw-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:41:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUSt-0001Ps-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:41:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUSu-00027i-IV; Wed, 19 Nov 2003 10:42:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUSc-000271-DD
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 10:41:42 -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 KAA22599
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 10:41:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUSZ-0001PO-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:41:39 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUSZ-0001PL-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:41:39 -0500
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu)
	by manatick with esmtp (Exim 4.24)
	id 1AMUSZ-0005t0-Nz
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:41:39 -0500
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id E97847F7B6; Wed, 19 Nov 2003 10:41:03 -0500 (EST)
To: christopher.eagan@lmco.com, ieprep@ietf.org
Subject: Re: [Ieprep] MLPPoIP effort?
In-Reply-To: <3F2F205501D3D411878C0008C7E6459410CFEC94@emss09m06.ems.lmco.com>
Message-Id: <20031119154103.E97847F7B6@newdev.harvard.edu>
Date: Wed, 19 Nov 2003 10:41:03 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
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>

> The reason I wonder about a separate working group is that it
> appears IEPREP is focused on the Internet whereas the private networks deal
> with a more configurable environment

it is a different environment, though I would not agree that it is 
"more configurable"

in any case - the ieprep WG decided to work on within-enterprise
ieprep (i.e. not between enterprise ) issues ("enterprice" includes ISP)
so the basic topic seems reasonable to think about in ieprep but we
need to look at the charter to see if such work is already in-charter
or if we need to talk to the ADs about changing the charter if the
WG thinks this is useful work

Scott (chair hat on)

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



From exim@www1.ietf.org  Wed Nov 19 10:57:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23087
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 10:57: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 1AMUhS-00032u-WB
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:57:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJFv2n9011706
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 10:57:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUhS-00032j-SD
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 10:57:02 -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 KAA23064
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 10:56:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUhQ-0001eF-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:57:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUhP-0001eC-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 10:56:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUhR-00031r-9a; Wed, 19 Nov 2003 10:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMUgZ-0002zw-3J
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 10:56: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 KAA23045
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 10:55:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUgW-0001dg-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:56:04 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMUgV-0001dd-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 10:56:03 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Wed, 19 Nov 2003 10:55:55 -0500
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003111910555411179
 ; Wed, 19 Nov 2003 10:55:54 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XCSYT85Z>; Wed, 19 Nov 2003 10:55:54 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D52012@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "'Eagan, Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org
Subject: RE: [IEPREP] MLPPoIP effort?
Date: Wed, 19 Nov 2003 10:55:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
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>


>it appears IEPREP is focused on the Internet 
> whereas the private networks deal with a more configurable 
> environment (chairs?).

IEPREP is also talking about access networks (some use the term stub
domains) that provide a "more configurable environment" for behavior within
that network alone but may still be part of the Internet. 

> I guess the issue is, can we somehow unify, and invigorate 
> some of these efforts under a common goal of MLPPoIP?  Is 
> IEPREP the place to do it or should it be an additional 
> working group? 

With respect to MLPPoIP (a.k.a. Assured Service--MLPP was the name of the
particular solution within a circuit-switched environment to the general
requirement of Assured Service).  What does the working group think of
IEPREP describing requirements for MLPP services explicitly? 

The charter says "Quick response for recovery
operations requires immediate access to any public telecommunications
capabilities at hand. " and we agreed access networks that were part of the
Internet may be part of public telecommunications.  Does MLPP fit the
charter?  So, I like Ken's suggestion of a draft that is more explicit about
what is being sought.

Kimberly

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



From exim@www1.ietf.org  Wed Nov 19 15:54:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11316
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 15:54: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 1AMZL0-0007p1-3d
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 15:54:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKsAca030064
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 15:54:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMZKz-0007op-8u
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:54: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 PAA11303
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 15:53:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMZKu-00021K-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 15:54:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMZKu-00021H-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 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 1AMZKq-0007nL-N5; Wed, 19 Nov 2003 15:54:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMZKj-0007n7-1A
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 15:53:53 -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 PAA11299
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 15:53:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMZKh-00021D-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 15:53:51 -0500
Received: from kc-msxproto2.kc.umkc.edu ([134.193.143.155])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMZKg-000219-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 15:53:50 -0500
Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 19 Nov 2003 14:53:49 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
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, 19 Nov 2003 14:53:48 -0600
Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108171@KC-MAIL4.kc.umkc.edu>
Thread-Topic: MLPPoIP effort?
Thread-Index: AcOu3zqUbhGSdSxHRHm/eO/cQCMBuw==
From: "Ayyasamy, Senthilkumar  \(UMKC-Student\)" <saq66@umkc.edu>
To: <ieprep@ietf.org>
Cc: <fred@cisco.com>
X-OriginalArrivalTime: 19 Nov 2003 20:53:49.0057 (UTC) FILETIME=[3B31DF10:01C3AEDF]
Content-Transfer-Encoding: quoted-printable
Subject: [Ieprep] RE:MLPPoIP effort?
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>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

> In addition, there is the traits-based-authorization* effort in the=20
> sipping wg and the mlef phb** draft that are applicable. =20
[...]
> ** =
http://www.ietf.org/internet-drafts/draft-silverman-diffserv-mlefphb-02.t=
xt =
<http://www.ietf.org/internet-drafts/draft-silverman-diffserv-mlefphb-02.=
txt>=20
=20
I read the above draft and it says,
=20
   This draft extends the EF PHB based on the concepts of AF to
   provide a single class (queue) but with multiple drop treatments.

This will have poor effect on the lower precendence class of mlef=20
(as your not preempting but just reducing the quality of lower=20
precendence calls to leave way for the higher precendence calls.)=20
Do you have any performance results to show that mlef doesn't=20
aggravate congestion(given this is suggested for voice calls)?
=20
I have a general diffserv doubt. Is the above configuration (AF class
within EF)-a workable model? (possibly, fred can help me understand...)

> The reason I wonder about a separate working group is that it appears=20
> IEPREP is focused on the Internet whereas the private networks deal=20
> with a more configurable environment=20
=20
I presume, the *I* in IETF stands for Internet. I don't think one needs=20
IETF ratification for stuff related to private network (unless, it has=20
effect on the Internet like the private address space leakage.)

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



From exim@www1.ietf.org  Wed Nov 19 17:49:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19815
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 17:49: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 1AMb8C-0004gG-JS
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 17:49:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJMn4oC017988
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 17:49:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMb8C-0004g3-GO
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 17:49: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 RAA19792
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 17:48:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMb89-0005Lb-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 17:49:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMb89-0005LY-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 17: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 1AMb89-0004fM-MW; Wed, 19 Nov 2003 17:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMb7h-0004ex-Ao
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 17:48: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 RAA19788
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 17:48:18 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMb7e-0005LA-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 17:48:30 -0500
Received: from imo-m01.mx.aol.com ([64.12.136.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMb7e-0005KQ-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 17:48:30 -0500
Received: from Mpierce1@aol.com
	by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id f.141.1cef23af (4116);
	Wed, 19 Nov 2003 17:47:50 -0500 (EST)
Message-ID: <141.1cef23af.2ced4d16@aol.com>
Date: Wed, 19 Nov 2003 17:47:50 EST
Subject: Re: [Ieprep] RE:MLPPoIP effort?
To: saq66@umkc.edu, ieprep@ietf.org
CC: fred@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_141.1cef23af.2ced4d16_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_141.1cef23af.2ced4d16_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/19/2003 3:57:45 PM Eastern Standard Time, 
saq66@umkc.edu writes:


> This will have poor effect on the lower precendence class of mlef 
> (as your not preempting but just reducing the quality of lower 
> precendence calls to leave way for the higher precendence calls.) 
> Do you have any performance results to show that mlef doesn't 
> aggravate congestion(given this is suggested for voice calls)?
> 


Yes, congestion would have an effect on lower precedence calls by dropping 
packets. This is considered as being better that having an effect on all calls 
(including the high precedence ones). The effect is temporary, until some 
existing calls release and as CAC kicks in and prevents new calls from being 
established.

Take a typical example: At the moment congestion hits and some high 
precedence calls exist, lets say there are 100 calls, 95 low precedence and 5 high. If 
the congestion is such that 1% of the packets are being discarded (EF says you 
must discard something), then every call gets the effect of 1% packet loss 
(without MLEF). With MLEF, the 5 high precedence calls are essentially exempt 
from having their packets discarded. The other 95 get 1.05% packet loss, hardly 
a big difference. With normal holding times of 3 minutes, it will take less 
than 10 seconds for 5 of those 95 low precedence calls to release, ending the 
need to drop any packets.

MLEF can't aggravate congestion, since all it is doing is deciding which 
packets to discard, where such discard is already required by EF. Remember, this 
also requires effective CAC, which is required even without MLEF.

Simple preemption of the lower precedence calls would be preferable, but it 
appears that there is no sure-fire way to do that. I'm hoping that someone can 
describe one.

Mike Pierce


--part1_141.1cef23af.2ced4d16_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/19/=
2003 3:57:45 PM Eastern Standard Time, saq66@umkc.edu writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">This will have poor effect=20=
on the lower precendence class of mlef=20
<BR>(as your not preempting but just reducing the quality of lower=20
<BR>precendence calls to leave way for the higher precendence calls.)=20
<BR>Do you have any performance results to show that mlef doesn't=20
<BR>aggravate congestion(given this is suggested for voice calls)?
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>
<BR>Yes, congestion would have an effect on lower precedence calls by droppi=
ng packets. This is considered as being better that having an effect on all=20=
calls (including the high precedence ones). The effect is temporary, until s=
ome existing calls release and as CAC kicks in and prevents new calls from b=
eing established.
<BR>
<BR>Take a typical example: At the moment congestion hits and some high prec=
edence calls exist, lets say there are 100 calls, 95 low precedence and 5 hi=
gh. If the congestion is such that 1% of the packets are being discarded (EF=
 says you must discard something), then every call gets the effect of 1% pac=
ket loss (without MLEF). With MLEF, the 5 high precedence calls are essentia=
lly exempt from having their packets discarded. The other 95 get 1.05% packe=
t loss, hardly a big difference. With normal holding times of 3 minutes, it=20=
will take less than 10 seconds for 5 of those 95 low precedence calls to rel=
ease, ending the need to drop any packets.
<BR>
<BR>MLEF can't aggravate congestion, since all it is doing is deciding which=
 packets to discard, where such discard is already required by EF. Remember,=
 this also requires effective CAC, which is required even without MLEF.
<BR>
<BR>Simple preemption of the lower precedence calls would be preferable, but=
 it appears that there is no sure-fire way to do that. I'm hoping that someo=
ne can describe one.
<BR>
<BR>Mike Pierce
<BR></FONT></HTML>

--part1_141.1cef23af.2ced4d16_boundary--

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



From exim@www1.ietf.org  Wed Nov 19 19:58:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27264
	for <ieprep-archive@odin.ietf.org>; Wed, 19 Nov 2003 19:58: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 1AMd98-000237-Ti
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 19:58:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK0wAuS007873
	for ieprep-archive@odin.ietf.org; Wed, 19 Nov 2003 19:58:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMd98-00022u-Q1
	for ieprep-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 19:58:10 -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 TAA27257
	for <ieprep-web-archive@ietf.org>; Wed, 19 Nov 2003 19:57:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMd96-0000HJ-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 19:58:08 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMd96-0000HE-00
	for ieprep-web-archive@ietf.org; Wed, 19 Nov 2003 19:58:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMd8z-000208-6k; Wed, 19 Nov 2003 19:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMd8d-0001zm-Pj
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 19:57:39 -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 TAA27252
	for <ieprep@ietf.org>; Wed, 19 Nov 2003 19:57:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMd8b-0000H5-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 19:57:37 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMd8b-0000Fx-00
	for ieprep@ietf.org; Wed, 19 Nov 2003 19:57:37 -0500
Received: from Steve (ha24s474.d.shentel.net [204.111.29.218])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAK0re401123;
	Wed, 19 Nov 2003 19:53:40 -0500
From: "Steve Silverman" <steves@shentel.net>
To: <Mpierce1@aol.com>, <saq66@umkc.edu>, <ieprep@ietf.org>
Cc: <fred@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Wed, 19 Nov 2003 19:53:46 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBAEINDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0015_01C3AED6.D7A428C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <141.1cef23af.2ced4d16@aol.com>
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C3AED6.D7A428C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.
This is essentially a major extrapolation  of  Van Jacobsen (dropped
pkts --> less offered load) for the voice application.



I believe that one reason for the success of
the Internet (adaptability to surges) is the fact that congestion leads
to lowered terminal transmission (VJ, and when surfing becomes slow, some
people quit.)
If  VoIP is to become a significant part of the total Internet traffic, some
sort of feedback needs to be incorporated.


Obviously, the behavior above  would only help if a significant fraction of
the terminals on the network used it.
For the MLPPoIP community (if this exists) this might be practical.

Steve Silverman



  -----Original Message-----
  From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of
Mpierce1@aol.com
  Sent: Wednesday, November 19, 2003 5:48 PM
  To: saq66@umkc.edu; ieprep@ietf.org
  Cc: fred@cisco.com
  Subject: Re: [Ieprep] RE:MLPPoIP effort?


  In a message dated 11/19/2003 3:57:45 PM Eastern Standard Time,
saq66@umkc.edu writes:



    This will have poor effect on the lower precendence class of mlef
    (as your not preempting but just reducing the quality of lower
    precendence calls to leave way for the higher precendence calls.)
    Do you have any performance results to show that mlef doesn't
    aggravate congestion(given this is suggested for voice calls)?




  Yes, congestion would have an effect on lower precedence calls by dropping
packets. This is considered as being better that having an effect on all
calls (including the high precedence ones). The effect is temporary, until
some existing calls release and as CAC kicks in and prevents new calls from
being established.

  Take a typical example: At the moment congestion hits and some high
precedence calls exist, lets say there are 100 calls, 95 low precedence and
5 high. If the congestion is such that 1% of the packets are being discarded
(EF says you must discard something), then every call gets the effect of 1%
packet loss (without MLEF). With MLEF, the 5 high precedence calls are
essentially exempt from having their packets discarded. The other 95 get
1.05% packet loss, hardly a big difference. With normal holding times of 3
minutes, it will take less than 10 seconds for 5 of those 95 low precedence
calls to release, ending the need to drop any packets.

  MLEF can't aggravate congestion, since all it is doing is deciding which
packets to discard, where such discard is already required by EF. Remember,
this also requires effective CAC, which is required even without MLEF.

  Simple preemption of the lower precedence calls would be preferable, but
it appears that there is no sure-fire way to do that. I'm hoping that
someone can describe one.

  Mike Pierce

------=_NextPart_000_0015_01C3AED6.D7A428C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003>One&nbsp;possible solution for the lower =
priority calls=20
would be a terminal behaviour such that if a certain&nbsp;percentage=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>(or=20
number)&nbsp;of packets are lost in a certain amount of time,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>the terminal=20
issues a congestion notice to the other party and either the call is =
suspended=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>for a short=20
period of time or terminated.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>This is=20
</SPAN></FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D607240000-20112003><FONT size=3D3>essentially a major=20
extrapolation&nbsp;&nbsp;of &nbsp;Van Jacobsen (dropped pkts&nbsp;--&gt; =
less=20
offered load) for the voice =
application.</FONT>&nbsp;&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>I believe=20
that one reason for the success of </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>the Internet=20
(adaptability to surges) is the fact that congestion leads =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>to lowered=20
terminal transmission (VJ,&nbsp;and when surfing becomes slow, some =
people=20
</SPAN></FONT><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003>quit.)&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>If&nbsp; VoIP=20
is </SPAN></FONT><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003>to become a significant part of the total =
Internet=20
traffic, some sort of feedback needs to be incorporated.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003>Obviously,&nbsp;the behavior above =
&nbsp;would only=20
help if a significant fraction of the terminals on the network used =
it.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>For the=20
MLPPoIP community (if this exists) this might be practical.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D607240000-20112003>Steve=20
Silverman</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D607240000-20112003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D607240000-20112003>&nbsp;=20
</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
ieprep-admin@ietf.org=20
  [mailto:ieprep-admin@ietf.org]<B>On Behalf Of=20
  </B>Mpierce1@aol.com<BR><B>Sent:</B> Wednesday, November 19, 2003 5:48 =

  PM<BR><B>To:</B> saq66@umkc.edu; ieprep@ietf.org<BR><B>Cc:</B>=20
  fred@cisco.com<BR><B>Subject:</B> Re: [Ieprep] RE:MLPPoIP=20
  effort?<BR><BR></FONT></DIV><FONT face=3Darial,helvetica><FONT =
size=3D2>In a=20
  message dated 11/19/2003 3:57:45 PM Eastern Standard Time, =
saq66@umkc.edu=20
  writes: <BR><BR><BR>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"=20
  TYPE=3D"CITE">This will have poor effect on the lower precendence =
class of=20
    mlef <BR>(as your not preempting but just reducing the quality of =
lower=20
    <BR>precendence calls to leave way for the higher precendence =
calls.) <BR>Do=20
    you have any performance results to show that mlef doesn't =
<BR>aggravate=20
    congestion(given this is suggested for voice calls)? =
<BR></FONT><FONT lang=3D0=20
    face=3DArial color=3D#000000 size=3D3=20
  FAMILY=3D"SANSSERIF"></BLOCKQUOTE><BR></FONT><FONT lang=3D0 =
face=3DArial=20
  color=3D#000000 size=3D2 FAMILY=3D"SANSSERIF"><BR><BR>Yes, congestion =
would have an=20
  effect on lower precedence calls by dropping packets. This is =
considered as=20
  being better that having an effect on all calls (including the high =
precedence=20
  ones). The effect is temporary, until some existing calls release and =
as CAC=20
  kicks in and prevents new calls from being established. <BR><BR>Take a =
typical=20
  example: At the moment congestion hits and some high precedence calls =
exist,=20
  lets say there are 100 calls, 95 low precedence and 5 high. If the =
congestion=20
  is such that 1% of the packets are being discarded (EF says you must =
discard=20
  something), then every call gets the effect of 1% packet loss (without =
MLEF).=20
  With MLEF, the 5 high precedence calls are essentially exempt from =
having=20
  their packets discarded. The other 95 get 1.05% packet loss, hardly a =
big=20
  difference. With normal holding times of 3 minutes, it will take less =
than 10=20
  seconds for 5 of those 95 low precedence calls to release, ending the =
need to=20
  drop any packets. <BR><BR>MLEF can't aggravate congestion, since all =
it is=20
  doing is deciding which packets to discard, where such discard is =
already=20
  required by EF. Remember, this also requires effective CAC, which is =
required=20
  even without MLEF. <BR><BR>Simple preemption of the lower precedence =
calls=20
  would be preferable, but it appears that there is no sure-fire way to =
do that.=20
  I'm hoping that someone can describe one. <BR><BR>Mike Pierce=20
<BR></BLOCKQUOTE></FONT></FONT></BODY></HTML>

------=_NextPart_000_0015_01C3AED6.D7A428C0--



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



From exim@www1.ietf.org  Thu Nov 20 09:31:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05988
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 09:31: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 1AMppv-0005W7-H1
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 09:31:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEVBud021206
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 09:31:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMppv-0005Vx-DW
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:31:11 -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 JAA05951
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 09:30:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMppt-0003nC-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 09:31:09 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMppt-0003n9-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 09:31:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMppn-0005U4-Is; Thu, 20 Nov 2003 09:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMpp2-0005NK-MH
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 09:30:16 -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 JAA05886
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 09:30:03 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMpp0-0003mH-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 09:30:14 -0500
Received: from imo-r08.mx.aol.com ([152.163.225.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMpp0-0003lk-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 09:30:14 -0500
Received: from Mpierce1@aol.com
	by imo-r08.mx.aol.com (mail_out_v36_r1.1.) id p.38.3f14c123 (4320);
	Thu, 20 Nov 2003 09:29:34 -0500 (EST)
Message-ID: <38.3f14c123.2cee29ce@aol.com>
Date: Thu, 20 Nov 2003 09:29:34 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: steves@shentel.net, saq66@umkc.edu, ieprep@ietf.org
CC: fred@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_38.3f14c123.2cee29ce_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_38.3f14c123.2cee29ce_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/19/2003 7:57:47 PM Eastern Standard Time, 
steves@shentel.net writes:


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



Yes, I believe this has been suggested. The obvious problem is trying to 
define an algorithm that would allow a terminal to distinguish between packet loss 
from congestion that isn't going to go away, and packet loss that is going to 
go away rather quickly anyway (as in my example), and packet loss due to 
something other than congestion. I tend to think that this is not possible.

Suspending a call for a short period sounds worse than the random packet loss.

Mike Pierce

--part1_38.3f14c123.2cee29ce_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/19/=
2003 7:57:47 PM Eastern Standard Time, steves@shentel.net writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">One possible solution for t=
he lower priority calls would be a terminal behaviour such that if a certain=
 percentage=20
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">(or number) of packets are lost in a certain amount of time,=
 </FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Arial=
" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">the terminal issues a congestion notice to the other party a=
nd either the call is suspended </FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAM=
ILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">for a short period of time or terminated. &nbsp;</FONT><FONT=
  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">
<BR></BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>Yes, I believe this has been suggested. The obvious problem is trying to=
 define an algorithm that would allow a terminal to distinguish between pack=
et loss from congestion that isn't going to go away, and packet loss that is=
 going to go away rather quickly anyway (as in my example), and packet loss=20=
due to something other than congestion. I tend to think that this is not pos=
sible.
<BR>
<BR>Suspending a call for a short period sounds worse than the random packet=
 loss.
<BR>
<BR>Mike Pierce</FONT></HTML>

--part1_38.3f14c123.2cee29ce_boundary--

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



From exim@www1.ietf.org  Thu Nov 20 14:41:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20443
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 14:41:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMufp-0004Ao-SA
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 14:41:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKJf59Z016041
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 14:41:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMufp-0004Ae-LM
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 14:41:05 -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 OAA20378
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 14:40:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMufm-00011C-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 14:41:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMufm-000118-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 14:41:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMufk-00049V-Qs; Thu, 20 Nov 2003 14:41:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMuf1-000483-Nv
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 14:40:15 -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 OAA20344
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 14:39:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMueu-0000zx-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 14:40:08 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMuet-0000zb-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 14:40:07 -0500
Received: from Steve (ha30s116.d.shentel.net [204.111.23.116])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAKJdD424813;
	Thu, 20 Nov 2003 14:39:13 -0500
From: "Steve Silverman" <steves@shentel.net>
To: <Mpierce1@aol.com>, <saq66@umkc.edu>, <ieprep@ietf.org>
Cc: <fred@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Thu, 20 Nov 2003 14:39:22 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBEEJHDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01C3AF74.16623D70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <38.3f14c123.2cee29ce@aol.com>
Importance: Normal
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C3AF74.16623D70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Responses below.

It seems to me that if bandwidth is scarce, silence suppression is a major
benefit. Typical users only speak for one third of the time.  But the CAC
simply reserves enough bandwidth in each direction for continuous speech -
A factor of 3 in actual utilization.  Does this seem a reasonable approach
to anyone?   One key question is how the the MLPP crowd intends to do voice.
Do they intend to use silence suppression?
 How serious are they about MLPP?   Since I am now unemployed, I don't have
much access to current thinking.

In addition, for large networks with low bandwidth trunks, it may be
difficult to build a CAC that can handle the network.  Has anyone
done a CAC to handle the DOD forces in the Middle East?   I would assume we
don't have much fiber there.  Can anyone supply the relevant facts or are
they classified?

Steve
  -----Original Message-----
  From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
  Sent: Thursday, November 20, 2003 9:30 AM
  To: steves@shentel.net; saq66@umkc.edu; ieprep@ietf.org
  Cc: fred@cisco.com
  Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls


  In a message dated 11/19/2003 7:57:47 PM Eastern Standard Time,
steves@shentel.net writes:



    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.





  Yes, I believe this has been suggested. The obvious problem is trying to
define an algorithm that would allow a terminal to distinguish between
packet loss from congestion that isn't going to go away, and packet loss
that is going to go away rather quickly anyway (as in my example), and
packet loss due to something other than congestion. I tend to think that
this is not possible.


  SS:
  It seems to me that counting pkt losses per time period is easy.  The
question is whether it is useful.  If calls were suspended for perhaps 10
seconds
  with a message indicating that this was being done, that might be more
acceptable than disconnection.  Currently in the CS environment, preempted
calls
  are simply given a tone and terminated.  I would think that this would be
preferable. If the congestion lasted more than the 10 seconds,
  then the call would be terminated.  It would be nice if a practical  CAC
were implemented but I am skeptical about that.


  Suspending a call for a short period sounds worse than the random packet
loss.

  SS:  I'd like to try this on some people and see which they prefer.  But
it seems to me that disconnecting 5% of the routine calls is preferable to
having 50% of the calls continue unintelligibly.  That appears to me to be a
major waste of bandwidth not to mention the time and frustration of the
actual people involved.




  Mike Pierce

------=_NextPart_000_0012_01C3AF74.16623D70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>Responses=20
below.</FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>It seems to=20
me that if bandwidth is scarce, silence suppression is a major benefit. =
Typical=20
users only speak for one third of the time.&nbsp; But the=20
CAC</FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>simply=20
reserves enough bandwidth in each direction for continuous speech =
-&nbsp; A=20
factor of 3 in actual utilization.&nbsp; Does this seem a reasonable =
approach=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>to=20
anyone?&nbsp;&nbsp; One key question is&nbsp;how the the MLPP crowd =
intends to=20
do voice.&nbsp;Do they intend to use silence=20
suppression?&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>&nbsp;How=20
serious are they about MLPP?&nbsp; &nbsp;Since I am now unemployed, I =
don't have=20
much access to current thinking. </FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>In addition,=20
for large networks with low bandwidth trunks, it may be difficult to =
build a CAC=20
that can handle the network.&nbsp; Has anyone </FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial =
color=3D#0000ff>done a CAC to=20
handle the DOD forces in the Middle East?&nbsp;&nbsp; I would assume we =
don't=20
have much fiber there.&nbsp; Can anyone supply the relevant facts or are =
they=20
classified?&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D595041519-20112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Steve</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Mpierce1@aol.com=20
  [mailto:Mpierce1@aol.com]<BR><B>Sent:</B> Thursday, November 20, 2003 =
9:30=20
  AM<BR><B>To:</B> steves@shentel.net; saq66@umkc.edu;=20
  ieprep@ietf.org<BR><B>Cc:</B> fred@cisco.com<BR><B>Subject:</B> Re: =
[Ieprep]=20
  RE:MLPPoIP - Preemption of low priority =
calls<BR><BR></FONT></DIV><FONT=20
  size=3D2><FONT face=3DArial>In a message dated 11/19/2003 7:57:47 PM =
Eastern=20
  Standard Time, steves@shentel.net writes: <BR><BR><BR></FONT>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"=20
  TYPE=3D"CITE"><FONT face=3DArial>One possible solution for the lower =
priority=20
    calls would be a terminal behaviour such that if a certain =
percentage=20
    <BR></FONT></FONT><FONT lang=3D0 face=3DArial color=3D#0000ff =
size=3D2=20
    FAMILY=3D"SANSSERIF">(or number) of packets are lost in a certain =
amount of=20
    time, </FONT><FONT lang=3D0 color=3D#000000 size=3D2=20
    FAMILY=3D"SANSSERIF"><BR></FONT><FONT lang=3D0 face=3DArial =
color=3D#0000ff size=3D2=20
    FAMILY=3D"SANSSERIF">the terminal issues a congestion notice to the =
other=20
    party and either the call is suspended </FONT><FONT lang=3D0 =
color=3D#000000=20
    size=3D2 FAMILY=3D"SANSSERIF"><BR></FONT><FONT lang=3D0 face=3DArial =
color=3D#0000ff=20
    size=3D2 FAMILY=3D"SANSSERIF">for a short period of time or =
terminated.=20
    &nbsp;</FONT><FONT lang=3D0 color=3D#000000 =
FAMILY=3D"SANSSERIF"><FONT face=3DArial=20
    size=3D2> <BR></FONT></BLOCKQUOTE>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT><BR><BR><BR><BR><FONT face=3DArial size=3D2>Yes, I =
believe this has=20
  been suggested. The obvious problem is trying to define an algorithm =
that=20
  would allow a terminal to distinguish between packet loss from =
congestion that=20
  isn't going to go away, and packet loss that is going to go away =
rather=20
  quickly anyway (as in my example), and packet loss due to something =
other than=20
  congestion. I tend to think that this is not possible.&nbsp;<SPAN=20
  class=3D595041519-20112003><FONT =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D595041519-20112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D595041519-20112003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D595041519-20112003>SS:&nbsp;=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D595041519-20112003>It seems to=20
  me that counting pkt losses per time period is easy.&nbsp; The =
question is=20
  whether it is useful.&nbsp; If calls were suspended for perhaps 10=20
  seconds</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D595041519-20112003>with a=20
  message indicating that this was being done, that might be more =
acceptable=20
  than disconnection.&nbsp; Currently in the CS environment, preempted =
calls=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D595041519-20112003>are simply=20
  given a tone and terminated.&nbsp; I would think that this would be=20
  preferable. If the congestion lasted more than the 10 seconds,=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D595041519-20112003>then the=20
  call would be terminated.&nbsp; It would be nice if a practical&nbsp; =
CAC were=20
  implemented but I am skeptical about that. </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D595041519-20112003></SPAN></FONT>&nbsp;</DIV><FONT><FONT=20
  face=3DArial><FONT size=3D2>
  <DIV><FONT color=3D#0000ff></FONT><FONT =
color=3D#0000ff></FONT><BR>Suspending a=20
  call for a short period sounds worse than the random packet=20
  loss.&nbsp;<BR><SPAN class=3D595041519-20112003><FONT=20
  color=3D#0000ff></FONT></SPAN></DIV>
  <DIV><SPAN class=3D595041519-20112003><FONT color=3D#0000ff =
size=3D3>SS:&nbsp; I'd=20
  like to try this on some people and see which they prefer.&nbsp; =
But&nbsp;it=20
  seems to me that disconnecting 5% of the&nbsp;routine calls is =
preferable=20
  to&nbsp;</FONT></SPAN><SPAN class=3D595041519-20112003><FONT =
size=3D3><FONT=20
  color=3D#0000ff>having 50% of the calls continue unintelligibly.&nbsp; =
That=20
  appears to me to be a major waste of bandwidth&nbsp;not to mention the =
time=20
  and frustration of the&nbsp;</FONT>&nbsp;</FONT></SPAN></FONT><SPAN=20
  class=3D595041519-20112003><FONT color=3D#0000ff size=3D3>actual =
people=20
  involved.&nbsp; </FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D595041519-20112003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D595041519-20112003>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT><FONT><SPAN class=3D595041519-20112003></SPAN><FONT =
face=3DArial><FONT=20
  size=3D2><SPAN class=3D595041519-20112003><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></FONT></FONT></DIV>
  <DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2><SPAN=20
  class=3D595041519-20112003>&nbsp;</SPAN><BR>Mike=20
  Pierce</FONT></FONT></FONT></FONT></FONT><FONT face=3DArial>=20
</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0012_01C3AF74.16623D70--



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



From exim@www1.ietf.org  Thu Nov 20 15:01:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21501
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 15:01: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 1AMuz9-0005tK-BD
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 15:01:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKK13oG022644
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 15:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMuz9-0005t9-7c
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:01:03 -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 PAA21472
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 15:00:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMuz5-0001Ol-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 15:00:59 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMuz5-0001Oi-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 15:00:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMuz6-0005rQ-PM; Thu, 20 Nov 2003 15:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMuyM-0005pO-3A
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 15:00:14 -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 OAA21399
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 14:59:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMuyH-0001Nv-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 15:00:09 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMuyH-0001N3-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 15:00:09 -0500
Received: from cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 20 Nov 2003 11:59:42 -0800
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAKJxbrX006102;
	Thu, 20 Nov 2003 11:59:37 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA11956; Thu, 20 Nov 2003 11:59:36 -0800 (PST)
Message-Id: <4.3.2.7.2.20031120134510.0295c818@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Nov 2003 13:59:38 -0600
To: <ieprep@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: <fred@cisco.com>
In-Reply-To: <CIEELMKPOOAMCIAKANLBEEJHDEAA.steves@shentel.net>
References: <38.3f14c123.2cee29ce@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 02:39 PM 11/20/2003 -0500, Steve Silverman wrote:
>Responses below.
>
>It seems to me that if bandwidth is scarce, silence suppression is a major 
>benefit. Typical users only speak for one third of the time.  But the CAC
>simply reserves enough bandwidth in each direction for continuous speech 
>-  A factor of 3 in actual utilization.  Does this seem a reasonable approach
>to anyone?

Are you suggesting the choice is no CAC or CAC that might waste 2/3rds of 
the BW for that session?

>One key question is how the the MLPP crowd intends to do voice. Do they 
>intend to use silence suppression?

I've not read yet that they do

>  How serious are they about MLPP?

very

>Since I am now unemployed, I don't have much access to current thinking.
>
>In addition, for large networks with low bandwidth trunks, it may be 
>difficult to build a CAC that can handle the network.

Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750, 2753, 2996, 3175 
and 3181. The first and last of this list are especially relevant to your 
environments

>Has anyone
>done a CAC to handle the DOD forces in the Middle East?   I would assume 
>we don't have much fiber there.

Connectivity and bandwidth awareness are the issue here, not whether there 
is fiber or not

>Can anyone supply the relevant facts or are they classified?

I believe testing and analysis should be done prior to proposing solutions 
to incomplete requirements

>
>Steve




cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Thu Nov 20 15:20:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23406
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 15:20:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMvHp-0007E6-GK
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 15:20:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKKJTD027757
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 15:20:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMvHa-0007Cm-6Q
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:20:06 -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 PAA23380
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 15:19:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMvHY-0001fl-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 15:20:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMvHY-0001fi-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 15:20:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMvHW-0007C0-HJ; Thu, 20 Nov 2003 15:20:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMvH5-0007BC-5B
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 15:19: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 PAA23348
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 15:19:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMvH3-0001f8-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 15:19:33 -0500
Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMvH3-0001ey-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 15:19:33 -0500
Received: from no.name.available by [140.32.132.66]
          via smtpd (for [132.151.6.1]) with ESMTP; Thu, 20 Nov 2003 12:16:22 -0800
Received: from [131.120.179.253] ([131.120.179.253]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 20 Nov 2003 12:19:27 -0800
Mime-Version: 1.0
X-Sender: budden@monterey.nps.navy.mil
Message-Id: <a06010203bbe2d04ff59f@[131.120.179.253]>
In-Reply-To: <CIEELMKPOOAMCIAKANLBEEJHDEAA.steves@shentel.net>
References: <CIEELMKPOOAMCIAKANLBEEJHDEAA.steves@shentel.net>
Date: Thu, 20 Nov 2003 12:19:25 -0800
To: "Steve Silverman" <steves@shentel.net>, <Mpierce1@aol.com>,
        <saq66@umkc.edu>, <ieprep@ietf.org>
From: Rex Buddenberg <budden@nps.navy.mil>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: <fred@cisco.com>
Content-Type: multipart/alternative; boundary="============_-1142762928==_ma============"
X-OriginalArrivalTime: 20 Nov 2003 20:19:27.0190 (UTC) FILETIME=[98A3AF60:01C3AFA3]
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>

--============_-1142762928==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Steve, there are a couple dimensions to the issue and we're right in 
the middle of them in some DoD programs now.

Your observation that a two-party (or even multiparty) conversation 
has a lot of dead time in it is correct.

 From that we have a couple derivatives:
	- a single end system (policeman, first responder on scene) 
will have both voice and non-voice IP applications (a position report 
from the radionav box that he carries, for example).
	- if you lash up a 2.4k pipe which was designed for 
circuit-switch voice, and pump IP datagrams over it, the end node is 
likely to be a single end system, not a router fronting for a bunch 
of stuff on the backside LAN.  This amplifies all of the shortcomings 
of a radio link -- low interactivity and such -- because you've lost 
the benefits of IP multiplexing.  Note that we've been here many 
times before in the Internet -- router-to-router, once it becomes 
reality, results in us consolidating the available bandwith into a 
smaller number of larger-sized pipes.
	- the first responder metaphor of a policeman with a handset 
in his fist is probably not the one we want to envision.  Rather, 
that policemen is sorta wearing a LAN with his VOIP end system, his 
position reporting box, his camera, etc all attached.


At 2:39 PM -0500 11/20/03, Steve Silverman wrote:
>Responses below.
>
>It seems to me that if bandwidth is scarce, silence suppression is a 
>major benefit. Typical users only speak for one third of the time. 
>But the CAC
>simply reserves enough bandwidth in each direction for continuous 
>speech -  A factor of 3 in actual utilization.  Does this seem a 
>reasonable approach
>to anyone?   One key question is how the the MLPP crowd intends to 
>do voice. Do they intend to use silence suppression? 
>  How serious are they about MLPP?   Since I am now unemployed, I 
>don't have much access to current thinking.
>
>In addition, for large networks with low bandwidth trunks, it may be 
>difficult to build a CAC that can handle the network.  Has anyone
>done a CAC to handle the DOD forces in the Middle East?   I would 
>assume we don't have much fiber there.  Can anyone supply the 
>relevant facts or are they classified? 
>
>Steve
>
>-----Original Message-----
>From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
>Sent: Thursday, November 20, 2003 9:30 AM
>To: steves@shentel.net; saq66@umkc.edu; ieprep@ietf.org
>Cc: fred@cisco.com
>Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>In a message dated 11/19/2003 7:57:47 PM Eastern Standard Time, 
>steves@shentel.net writes:
>
>>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.  
>>
>
>
>
>
>Yes, I believe this has been suggested. The obvious problem is 
>trying to define an algorithm that would allow a terminal to 
>distinguish between packet loss from congestion that isn't going to 
>go away, and packet loss that is going to go away rather quickly 
>anyway (as in my example), and packet loss due to something other 
>than congestion. I tend to think that this is not possible.  
>
>
>SS: 
>It seems to me that counting pkt losses per time period is easy. 
>The question is whether it is useful.  If calls were suspended for 
>perhaps 10 seconds
>with a message indicating that this was being done, that might be 
>more acceptable than disconnection.  Currently in the CS 
>environment, preempted calls
>are simply given a tone and terminated.  I would think that this 
>would be preferable. If the congestion lasted more than the 10 
>seconds,
>then the call would be terminated.  It would be nice if a practical 
>CAC were implemented but I am skeptical about that.
>
>
>Suspending a call for a short period sounds worse than the random 
>packet loss. 
>
>SS:  I'd like to try this on some people and see which they prefer. 
>But it seems to me that disconnecting 5% of the routine calls is 
>preferable to having 50% of the calls continue unintelligibly.  That 
>appears to me to be a major waste of bandwidth not to mention the 
>time and frustration of the  actual people involved. 
>
>
>
>
>Mike Pierce


-- 
b
--============_-1142762928==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [Ieprep] RE:MLPPoIP - Preemption of low
priority calls</title></head><body>
<div>Steve, there are a couple dimensions to the issue and we're right
in the middle of them in some DoD programs now.</div>
<div><br></div>
<div>Your observation that a two-party (or even multiparty)
conversation has a lot of dead time in it is correct.</div>
<div><br></div>
<div>From that we have a couple derivatives:</div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>- a
single end system (policeman, first responder on scene) will have both
voice and non-voice IP applications (a position report from the
radionav box that he carries, for example). </div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>- if
you lash up a 2.4k pipe which was designed for circuit-switch voice,
and pump IP datagrams over it, the end node is likely to be a single
end system, not a router fronting for a bunch of stuff on the backside
LAN.&nbsp; This amplifies all of the shortcomings of a radio link --
low interactivity and such -- because you've lost the benefits of IP
multiplexing.&nbsp; Note that we've been here many times before in the
Internet -- router-to-router, once it becomes reality, results in us
consolidating the available bandwith into a smaller number of
larger-sized pipes. </div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>- the
first responder metaphor of a policeman with a handset in his fist is
probably not the one we want to envision.&nbsp; Rather, that policemen
is sorta wearing a LAN with his VOIP end system, his position
reporting box, his camera, etc all attached. </div>
<div><br></div>
<div><br></div>
<div>At 2:39 PM -0500 11/20/03, Steve Silverman wrote:</div>
<blockquote type="cite" cite><font color="#0000FF">Responses
below.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font color="#0000FF">It seems to me that
if bandwidth is scarce, silence suppression is a major benefit.
Typical users only speak for one third of the time.&nbsp; But the
CAC</font></blockquote>
<blockquote type="cite" cite><font color="#0000FF">simply reserves
enough bandwidth in each direction for continuous speech -&nbsp; A
factor of 3 in actual utilization.&nbsp; Does this seem a reasonable
approach</font></blockquote>
<blockquote type="cite" cite><font color="#0000FF">to anyone?&nbsp;&nbsp;
One key question is&nbsp;how the the MLPP crowd intends to do
voice.&nbsp;Do they intend to use silence
suppression?&nbsp;</font></blockquote>
<blockquote type="cite" cite><font color="#0000FF">&nbsp;How serious
are they about MLPP?&nbsp; &nbsp;Since I am now unemployed, I don't
have much access to current thinking.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font color="#0000FF">In addition, for
large networks with low bandwidth trunks, it may be difficult to build
a CAC that can handle the network.&nbsp; Has
anyone</font></blockquote>
<blockquote type="cite" cite><font color="#0000FF">done a CAC to
handle the DOD forces in the Middle East?&nbsp;&nbsp; I would assume
we don't have much fiber there.&nbsp; Can anyone supply the relevant
facts or are they classified?&nbsp;</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font size="-1"
color="#0000FF">Steve</font><br>
<blockquote><font size="-1">-----Original Message-----<br>
<b>From:</b> Mpierce1@aol.com [mailto:Mpierce1@aol.com]<br>
<b>Sent:</b> Thursday, November 20, 2003 9:30 AM<br>
<b>To:</b> steves@shentel.net; saq66@umkc.edu; ieprep@ietf.org<br>
<b>Cc:</b> fred@cisco.com<br>
<b>Subject:</b> Re: [Ieprep] RE:MLPPoIP - Preemption of low priority
calls</font><br>
<font size="-1"></font></blockquote>
<blockquote><font size="-1">In a message dated 11/19/2003 7:57:47 PM
Eastern Standard Time, steves@shentel.net writes:<br>
</font>
<blockquote type="cite" cite><font size="-1">One possible solution for
the lower priority calls would be a terminal behaviour such that if a
certain percentage<br>
<font color="#0000FF">(or number) of packets are lost in a certain
amount of time,</font><font color="#000000"><br>
</font><font color="#0000FF">the terminal issues a congestion notice
to the other party and either the call is suspended</font><font
color="#000000"><br>
</font><font color="#0000FF">for a short period of time or terminated.
&nbsp;</font></font><br>
<font color="#000000"></font></blockquote>
</blockquote>
<blockquote><font size="-1"><br>
<br>
<br>
<br>
Yes, I believe this has been suggested. The obvious problem is trying
to define an algorithm that would allow a terminal to distinguish
between packet loss from congestion that isn't going to go away, and
packet loss that is going to go away rather quickly anyway (as in my
example), and packet loss due to something other than congestion. I
tend to think that this is not possible.&nbsp;<font
color="#0000FF">&nbsp;</font></font></blockquote>
<blockquote><font size="-1">&nbsp;</font></blockquote>
<blockquote><font size="-1">&nbsp;</font></blockquote>
<blockquote><font size="-1"
color="#0000FF">SS:&nbsp;</font></blockquote>
<blockquote><font size="-1" color="#0000FF">It seems to me that
counting pkt losses per time period is easy.&nbsp; The question is
whether it is useful.&nbsp; If calls were suspended for perhaps 10
seconds</font></blockquote>
<blockquote><font size="-1" color="#0000FF">with a message indicating
that this was being done, that might be more acceptable than
disconnection.&nbsp; Currently in the CS environment, preempted
calls</font></blockquote>
<blockquote><font size="-1" color="#0000FF">are simply given a tone
and terminated.&nbsp; I would think that this would be preferable. If
the congestion lasted more than the 10 seconds,</font></blockquote>
<blockquote><font size="-1" color="#0000FF">then the call would be
terminated.&nbsp; It would be nice if a practical&nbsp; CAC were
implemented but I am skeptical about that.</font></blockquote>
<blockquote><font size="-1">&nbsp;</font></blockquote>
<blockquote><font size="-1"><br>
Suspending a call for a short period sounds worse than the random
packet loss.&nbsp;</font></blockquote>
<blockquote><font size="-1"><br></font></blockquote>
<blockquote><font color="#0000FF">SS:&nbsp; I'd like to try this on
some people and see which they prefer.&nbsp; But&nbsp;it seems to me
that disconnecting 5% of the&nbsp;routine calls is preferable
to&nbsp;having 50% of the calls continue unintelligibly.&nbsp; That
appears to me to be a major waste of bandwidth&nbsp;not to mention the
time and frustration of the&nbsp;</font>&nbsp;<font
color="#0000FF">actual people involved.&nbsp;</font></blockquote>
<blockquote><font size="-1">&nbsp;</font></blockquote>
<blockquote><font size="-1">&nbsp;</font></blockquote>
<blockquote><font size="-1" color="#0000FF">&nbsp;</font></blockquote>
<blockquote><font size="-1">&nbsp;<br>
Mike Pierce</font></blockquote>
</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div>b</div>
</body>
</html>
--============_-1142762928==_ma============--

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



From exim@www1.ietf.org  Thu Nov 20 16:25:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28174
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 16:25:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwIW-0004pz-32
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 16:25:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLP8Rh018595
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 16:25:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwIV-0004pq-Un
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16:25: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 QAA28086
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 16:24:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwIT-0003Ra-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 16:25:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwIT-0003RT-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 16:25:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwIP-0004ol-HK; Thu, 20 Nov 2003 16:25:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwHd-0004n1-2o
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 16:24:13 -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 QAA27904
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 16:23:59 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwHb-0003NT-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 16:24:11 -0500
Received: from imo-m05.mx.aol.com ([64.12.136.8])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwHa-0003Lz-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 16:24:10 -0500
Received: from Mpierce1@aol.com
	by imo-m05.mx.aol.com (mail_out_v36_r1.1.) id p.146.1cf195c7 (25711);
	Thu, 20 Nov 2003 16:23:12 -0500 (EST)
Message-ID: <146.1cf195c7.2cee8abf@aol.com>
Date: Thu, 20 Nov 2003 16:23:11 EST
Subject: Re: [Ieprep] RE:MLPPoIP - (1) Preemption of low priority calls
To: steves@shentel.net, saq66@umkc.edu, ieprep@ietf.org
CC: fred@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_146.1cf195c7.2cee8abf_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_146.1cf195c7.2cee8abf_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/20/2003 2:42:10 PM Eastern Standard Time, 
steves@shentel.net writes:


> It seems to me that if bandwidth is scarce, silence suppression is a major 
> benefit. Typical users only speak for one third of the time.  But the CAC
> simply reserves enough bandwidth in each direction for continuous speech -  
> A factor of 3 in actual utilization.  Does this seem a reasonable approach 
> to anyone?
> 



I think you've identified one of the big issues in implementing an effective 
CAC at the same time that silence suppression is being used. Yes, silence 
suppresion can be used to reduce the overall bandwidth requirements, completely 
independent of there being multiple precedence levels. Without silence 
suppression, I suppose that one could say that CAC "reserves" enough bandwidth for 
continuous speech using the presumed codec. I would also presume that, if silence 
suppression is being used in a network, that CAC would know it and take that 
into consideration, only "reserving" maybe 1/3 as much bandwidth for each call. 
It can just view this as being a lower rate codec and depends on the 
aggregate of many such calls to even out any bursts of speech on one. Of course, the 
end result is a less exact limit on the total, causing more short periods 
during which a temporary overload exists and packets must be discarded. TASI 
systems used across the oceans have operated this way for decades to squeeze more 
calls onto a wire.

I believe this case is another strong argument for the need for a selective 
discard mechanism as defined in MLEF.

Mike Pierce


--part1_146.1cf195c7.2cee8abf_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/20/=
2003 2:42:10 PM Eastern Standard Time, steves@shentel.net writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">It seems to me that if band=
width is scarce, silence suppression is a major benefit. Typical users only=20=
speak for one third of the time. &nbsp;But the CAC
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">simply reserves enough bandwidth in each direction for conti=
nuous speech - &nbsp;A factor of 3 in actual utilization. &nbsp;Does this se=
em a reasonable approach </FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"=
SANSSERIF" FACE=3D"Arial" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">to anyone?</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=
=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">
<BR></BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>I think you've identified one of the big issues in implementing an effec=
tive CAC at the same time that silence suppression is being used. Yes, silen=
ce suppresion can be used to reduce the overall bandwidth requirements, comp=
letely independent of there being multiple precedence levels. Without silenc=
e suppression, I suppose that one could say that CAC "reserves" enough bandw=
idth for continuous speech using the presumed codec. I would also presume th=
at, if silence suppression is being used in a network, that CAC would know i=
t and take that into consideration, only "reserving" maybe 1/3 as much bandw=
idth for each call. It can just view this as being a lower rate codec and de=
pends on the aggregate of many such calls to even out any bursts of speech o=
n one. Of course, the end result is a less exact limit on the total, causing=
 more short periods during which a temporary overload exists and packets mus=
t be discarded. TASI systems used across the oceans have operated this way f=
or decades to squeeze more calls onto a wire.
<BR>
<BR>I believe this case is another strong argument for the need for a select=
ive discard mechanism as defined in MLEF.
<BR>
<BR>Mike Pierce
<BR></FONT></HTML>

--part1_146.1cf195c7.2cee8abf_boundary--

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



From exim@www1.ietf.org  Thu Nov 20 16:58:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01550
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 16:58: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 1AMwoR-000898-Dj
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 16:58:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKLw7F5031308
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 16:58:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwoR-00088t-A8
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 16: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 QAA01428
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 16:57:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwoO-0004Zm-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 16:58:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwoO-0004Zi-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 16:58:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwoL-00087y-9U; Thu, 20 Nov 2003 16:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMwnY-00085y-FV
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 16:57:12 -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 QAA01245
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 16:56:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwnW-0004WG-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 16:57:10 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMwnV-0004Uh-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 16:57:09 -0500
Received: from Steve (ha24s126.d.shentel.net [204.111.24.126])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAKLtJ415914;
	Thu, 20 Nov 2003 16:55:19 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "James M. Polk" <jmpolk@cisco.com>, <ieprep@ietf.org>
Cc: <fred@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Thu, 20 Nov 2003 16:55:26 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBEEJMDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <4.3.2.7.2.20031120134510.0295c818@localhost>
Importance: Normal
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org]On Behalf Of
> James M. Polk
> Sent: Thursday, November 20, 2003 3:00 PM
> To: ieprep@ietf.org
> Cc: fred@cisco.com
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
> At 02:39 PM 11/20/2003 -0500, Steve Silverman wrote:
> >Responses below.
> >
> >It seems to me that if bandwidth is scarce, silence
> suppression is a major
> >benefit. Typical users only speak for one third of the
> time.  But the CAC
> >simply reserves enough bandwidth in each direction for
> continuous speech
> >-  A factor of 3 in actual utilization.  Does this seem a
> reasonable approach
> >to anyone?
>
> Are you suggesting the choice is no CAC or CAC that might
> waste 2/3rds of
> the BW for that session?

No.  I am saying that if silence suppression is used (and I think it
should be used) the
 deterministic busy signal calculation of the Circuit Switched world
is impossible in a Packet Switched
world.  Consequently, to maximize the utility of limited bandwidth,
some prioritization is required
and mechanisms to work within this environment need to be addressed.


>
> Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750,
> 2753, 2996, 3175
> and 3181. The first and last of this list are especially
> relevant to your
> environments
>
> >Has anyone
> >done a CAC to handle the DOD forces in the Middle East?
> I would assume
> >we don't have much fiber there.
>
> Connectivity and bandwidth awareness are the issue here,
> not whether there
> is fiber or not

The only reason I mention fiber is that in general, fiber provides an
abundance
of bandwidth but here I am focused on the case where bandwidth is a
scarce resource.



>
> >Can anyone supply the relevant facts or are they classified?
>
> I believe testing and analysis should be done prior to
> proposing solutions
> to incomplete requirements
>

I fully agree.
We had been   analyzing and testing before our funds ran out.
Is anyone looking at these issues and running the
appropriate testing.  I hope that my current impression that
these issues are being ignored is incorrect.


Steve

>



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



From exim@www1.ietf.org  Thu Nov 20 18:58:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09116
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 18:58: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 1AMygW-0007Qk-Ao
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 18:58:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKNw47p028556
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 18:58:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMygW-0007QV-6j
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 18:58: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 SAA09109
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 18:57:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMygS-0007D6-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 18:58:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMygS-0007D3-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 18:58:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMygT-0007Pc-KF; Thu, 20 Nov 2003 18:58:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMygJ-0007PG-E9
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 18:57:51 -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 SAA09096
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 18:57:35 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMygG-0007Ci-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 18:57:48 -0500
Received: from imo-m04.mx.aol.com ([64.12.136.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMygF-0007CO-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 18:57:47 -0500
Received: from Mpierce1@aol.com
	by imo-m04.mx.aol.com (mail_out_v36_r1.1.) id p.19d.1d5d46a1 (4426);
	Thu, 20 Nov 2003 18:57:02 -0500 (EST)
Message-ID: <19d.1d5d46a1.2ceeaece@aol.com>
Date: Thu, 20 Nov 2003 18:57:02 EST
Subject: Re: [Ieprep] RE:MLPPoIP - (2) Preemption of low priority calls
To: steves@shentel.net, saq66@umkc.edu, ieprep@ietf.org
CC: fred@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_19d.1d5d46a1.2ceeaece_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_19d.1d5d46a1.2ceeaece_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/20/2003 2:42:10 PM Eastern Standard Time, 
steves@shentel.net writes:


> SS:  
> It seems to me that counting pkt losses per time period is easy.  The 
> question is whether it is useful.  If calls were suspended for perhaps 10 seconds
> with a message indicating that this was being done, that might be more 
> acceptable than disconnection.  Currently in the CS environment, preempted calls 
> are simply given a tone and terminated.  I would think that this would be 
> preferable. If the congestion lasted more than the 10 seconds, 
> then the call would be terminated.  It would be nice if a practical  CAC 
> were implemented but I am skeptical about that. 
> 


[MAP] Yes, counting pkt loss per time is easy. Just doesn't mean much for 
this purpose.


> Suspending a call for a short period sounds worse than the random packet 
> loss. 
> 
> SS:  I'd like to try this on some people and see which they prefer.  But it 
> seems to me that disconnecting 5% of the routine calls is preferable to 
> having 50% of the calls continue unintelligibly.  That appears to me to be a major 
> waste of bandwidth not to mention the time and frustration of the  actual 
> people involved.  
> 

I think we need to consider what scenarios need to be addressed. The example 
I gave was of 100 calls, with 95 of them low precendence and 5 high. I believe 
a fair example of what needs to be supported is more like the following 
scenario

1. A facility is carrying 100 low precedence calls, taking up the entire 
capacity, and being successfully limited to 100 calls by an effective CAC. (Let's 
ignore silence suppresssion for a moment.)
2. An emergency occurs and a whole lot of additional low precedence calls are 
attempted, but are all blocked by CAC.
3. 10 high precedence calls are attempted, 1 per second for the next 10 
seconds, and allowed by CAC which uses a higher limit for high precedence calls.
4. Each new high precedence call takes several seconds (at least 5) to get to 
the stage of media flowing.
5. With avarage holding times, the existing low precedence calls release 
about 1 every 2 seconds.
6. Presume that the CAC mechanism can respond quickly to lower the limit on 
low precedence calls to 90.

Analysis of the above shows that there is almost no significant packet loss, 
since low precedence calls release fast enough to make room for the new high 
precedence calls. Whatever loss does occur is put on the low precedence calls, 
which are already in progress, so unitelligible speech just results in someone 
repeating what they said. If unintelligible speech occured during the initial 
seconds of a high precedence call, it might result in the user hanging up to 
try again

The selective packet discard is really only needed to accomodate a less than 
instantaneous response by the CAC, and as you said, you're skeptical about 
that.

Mike Pierce


--part1_19d.1d5d46a1.2ceeaece_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/20/=
2003 2:42:10 PM Eastern Standard Time, steves@shentel.net writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">SS: &nbsp;
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">It seems to me that counting pkt losses per time period is e=
asy. &nbsp;The question is whether it is useful. &nbsp;If calls were suspend=
ed for perhaps 10 seconds</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"=
SANSSERIF" FACE=3D"Arial" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">with a message indicating that this was being done, that mig=
ht be more acceptable than disconnection. &nbsp;Currently in the CS environm=
ent, preempted calls </FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANS=
SERIF" FACE=3D"Arial" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">are simply given a tone and terminated. &nbsp;I would think=20=
that this would be preferable. If the congestion lasted more than the 10 sec=
onds, </FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"=
Arial" LANG=3D"0">
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">then the call would be terminated. &nbsp;It would be nice if=
 a practical &nbsp;CAC were implemented but I am skeptical about that. </FON=
T><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=
=3D"0">
<BR> </BLOCKQUOTE>
<BR>
<BR>
<BR>[MAP] Yes, counting pkt loss per time is easy. Just doesn't mean much fo=
r this purpose.
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Suspending a call for a sho=
rt period sounds worse than the random packet loss.=20
<BR>
<BR></FONT><FONT  COLOR=3D"#0000ff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">SS: &nbsp;I'd like to try this on some people and see which=20=
they prefer. &nbsp;But it seems to me that disconnecting 5% of the routine c=
alls is preferable to having 50% of the calls continue unintelligibly. &nbsp=
;That appears to me to be a major waste of bandwidth not to mention the time=
 and frustration of the </FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"S=
ANSSERIF" FACE=3D"Arial" LANG=3D"0">&nbsp;</FONT><FONT  COLOR=3D"#0000ff" SI=
ZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">actual people involved=
. &nbsp;</FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=
=3D"Arial" LANG=3D"0">
<BR></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>I think we need to consider what scenarios need to be addressed. The exa=
mple I gave was of 100 calls, with 95 of them low precendence and 5 high. I=20=
believe a fair example of what needs to be supported is more like the follow=
ing scenario
<BR>
<BR>1. A facility is carrying 100 low precedence calls, taking up the entire=
 capacity, and being successfully limited to 100 calls by an effective CAC.=20=
(Let's ignore silence suppresssion for a moment.)
<BR>2. An emergency occurs and a whole lot of additional low precedence call=
s are attempted, but are all blocked by CAC.
<BR>3. 10 high precedence calls are attempted, 1 per second for the next 10=20=
seconds, and allowed by CAC which uses a higher limit for high precedence ca=
lls.
<BR>4. Each new high precedence call takes several seconds (at least 5) to g=
et to the stage of media flowing.
<BR>5. With avarage holding times, the existing low precedence calls release=
 about 1 every 2 seconds.
<BR>6. Presume that the CAC mechanism can respond quickly to lower the limit=
 on low precedence calls to 90.
<BR>
<BR>Analysis of the above shows that there is almost no significant packet l=
oss, since low precedence calls release fast enough to make room for the new=
 high precedence calls. Whatever loss does occur is put on the low precedenc=
e calls, which are already in progress, so unitelligible speech just results=
 in someone repeating what they said. If unintelligible speech occured durin=
g the initial seconds of a high precedence call, it might result in the user=
 hanging up to try again
<BR>
<BR>The selective packet discard is really only needed to accomodate a less=20=
than instantaneous response by the CAC, and as you said, you're skeptical ab=
out that.
<BR>
<BR>Mike Pierce
<BR></FONT></HTML>

--part1_19d.1d5d46a1.2ceeaece_boundary--

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



From exim@www1.ietf.org  Thu Nov 20 21:08:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13781
	for <ieprep-archive@odin.ietf.org>; Thu, 20 Nov 2003 21:08:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AN0iO-0006YR-Jx
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 21:08:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL288Fa025189
	for ieprep-archive@odin.ietf.org; Thu, 20 Nov 2003 21:08:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AN0iO-0006YC-FA
	for ieprep-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 21:08: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 VAA13771
	for <ieprep-web-archive@ietf.org>; Thu, 20 Nov 2003 21:07:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AN0iL-0001U0-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 21:08:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AN0iL-0001Tx-00
	for ieprep-web-archive@ietf.org; Thu, 20 Nov 2003 21:08:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AN0iH-0006XH-I0; Thu, 20 Nov 2003 21:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AN0i8-0006Vm-J7
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 21:07:52 -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 VAA13761
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 21:07:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AN0i6-0001Tf-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 21:07:50 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AN0i5-0001TQ-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 21:07:49 -0500
Received: from Steve (ha96s129.d.shentel.net [204.111.96.129])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAL27D426712;
	Thu, 20 Nov 2003 21:07:13 -0500
From: "Steve Silverman" <steves@shentel.net>
To: <Mpierce1@aol.com>, <saq66@umkc.edu>, <ieprep@ietf.org>
Cc: <fred@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - (2) Preemption of low priority calls
Date: Thu, 20 Nov 2003 21:07:21 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBOEKCDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0009_01C3AFAA.49E37390"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <19d.1d5d46a1.2ceeaece@aol.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C3AFAA.49E37390
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Mike,

You have a great deal of  confidence in the CAC.  Do you have any real idea
how all of this
is going to work?   Does anyone claim to really understand the operation of
this all knowing CAC,
across a large network with congested trunks.

What I'm afraid of is the following scenario:

100 routine users filling the trunk.  Now an emergency occurs and 10 high
priority users call in (or some call out).
In the absence of a priority scheme at the packet level, 10% of each call's
packets are dropped.
All calls become unintelligible.  Everyone hopes the congestion is temporary
and holds on.  Nobody
can be understood.  Knowing that in previous congestion cases, redialing
never works, everyone holds on
since they really want to know what is going on and "their" call is
critical.  Normal call attrition rates go out the window (porthole).

I don't claim the CAC is impossible.  I hope it can be done and that would
solve a number of problems.  I just want some
strong arguments that it is possible before we invest a great deal of money
in systems that won't work very well without an unattainable technology.

Steve



  I think we need to consider what scenarios need to be addressed. The
example I gave was of 100 calls, with 95 of them low precendence and 5 high.
I believe a fair example of what needs to be supported is more like the
following scenario

  1. A facility is carrying 100 low precedence calls, taking up the entire
capacity, and being successfully limited to 100 calls by an effective CAC.
(Let's ignore silence suppresssion for a moment.)
  2. An emergency occurs and a whole lot of additional low precedence calls
are attempted, but are all blocked by CAC.
  3. 10 high precedence calls are attempted, 1 per second for the next 10
seconds, and allowed by CAC which uses a higher limit for high precedence
calls.
  4. Each new high precedence call takes several seconds (at least 5) to get
to the stage of media flowing.
  5. With avarage holding times, the existing low precedence calls release
about 1 every 2 seconds.
  6. Presume that the CAC mechanism can respond quickly to lower the limit
on low precedence calls to 90.

  Analysis of the above shows that there is almost no significant packet
loss, since low precedence calls release fast enough to make room for the
new high precedence calls. Whatever loss does occur is put on the low
precedence calls, which are already in progress, so unitelligible speech
just results in someone repeating what they said. If unintelligible speech
occured during the initial seconds of a high precedence call, it might
result in the user hanging up to try again

  The selective packet discard is really only needed to accomodate a less
than instantaneous response by the CAC, and as you said, you're skeptical
about that.

  Mike Pierce

------=_NextPart_000_0009_01C3AFAA.49E37390
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>Mike,=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
have a great deal of &nbsp;confidence in the CAC.&nbsp; Do you have any =
real=20
idea how all of this</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>is=20
going&nbsp;to work?&nbsp;&nbsp; Does anyone claim to really understand =
the=20
operation of&nbsp; this all knowing CAC,</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>across=20
a large network with congested trunks.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>What=20
I'm afraid of is the following scenario:</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>100=20
routine users filling the trunk.&nbsp; Now an emergency occurs&nbsp;and =
10 high=20
priority users call in (or some call out).&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>In the=20
absence of a priority scheme at the packet level, 10% of each call's =
packets are=20
dropped.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>All=20
calls become unintelligible.&nbsp; Everyone hopes the congestion is =
temporary=20
and holds on.&nbsp; Nobody </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>can be=20
understood.&nbsp; Knowing that in previous congestion cases, redialing =
never=20
works, everyone holds on </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>since=20
they really want to know what is going on and "their" call is =
critical.&nbsp;=20
Normal call attrition rates go out the window (porthole).&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't claim the CAC is impossible.&nbsp; I hope it can be done and that =
would=20
solve a number of problems.&nbsp; I just want some </FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =
size=3D2>strong=20
arguments that it is possible before we invest a great deal of money in =
systems=20
that won't work very well without&nbsp;an unattainable&nbsp;technology.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2>Steve</FONT></SPAN></DIV>
<DIV><SPAN class=3D201372601-21112003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3Darial,helvetica>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"=20
  TYPE=3D"CITE"><FONT lang=3D0 face=3DArial color=3D#000000 size=3D3=20
  FAMILY=3D"SANSSERIF"></BLOCKQUOTE><FONT color=3D#0000ff=20
  size=3D2></FONT><BR></FONT><FONT lang=3D0 face=3DArial color=3D#000000 =
size=3D2=20
  FAMILY=3D"SANSSERIF"><BR>I think we need to consider what scenarios =
need to be=20
  addressed. The example I gave was of 100 calls, with 95 of them low=20
  precendence and 5 high. I believe a fair example of what needs to be =
supported=20
  is more like the following scenario <BR><BR>1. A facility is carrying =
100 low=20
  precedence calls, taking up the entire capacity, and being =
successfully=20
  limited to 100 calls by an effective CAC. (Let's ignore silence =
suppresssion=20
  for a moment.) <BR>2. An emergency occurs and a whole lot of =
additional low=20
  precedence calls are attempted, but are all blocked by CAC. <BR>3. 10 =
high=20
  precedence calls are attempted, 1 per second for the next 10 seconds, =
and=20
  allowed by CAC which uses a higher limit for high precedence calls. =
<BR>4.=20
  Each new high precedence call takes several seconds (at least 5) to =
get to the=20
  stage of media flowing. <BR>5. With avarage holding times, the =
existing low=20
  precedence calls release about 1 every 2 seconds. <BR>6. Presume that =
the CAC=20
  mechanism can respond quickly to lower the limit on low precedence =
calls to=20
  90. <BR><BR>Analysis of the above shows that there is almost no =
significant=20
  packet loss, since low precedence calls release fast enough to make =
room for=20
  the new high precedence calls. Whatever loss does occur is put on the =
low=20
  precedence calls, which are already in progress, so unitelligible =
speech just=20
  results in someone repeating what they said. If unintelligible speech =
occured=20
  during the initial seconds of a high precedence call, it might result =
in the=20
  user hanging up to try again <BR><BR>The selective packet discard is =
really=20
  only needed to accomodate a less than instantaneous response by the =
CAC, and=20
  as you said, you're skeptical about that. <BR><BR>Mike Pierce=20
<BR></DIV></BLOCKQUOTE></FONT></FONT></BODY></HTML>

------=_NextPart_000_0009_01C3AFAA.49E37390--



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



From exim@www1.ietf.org  Fri Nov 21 09:41:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15010
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 09:41: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 1ANCT5-0003Jm-Ea
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 09:41:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALEf7ON012754
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 09:41:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANCT5-0003Jd-B1
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 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 JAA15003
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 09:40:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCT3-00031Z-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 09:41:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCT3-00031W-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 09:41:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANCT0-0003Ih-Di; Fri, 21 Nov 2003 09:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANCSK-0003HO-Py
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 09:40:20 -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 JAA14930
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 09:40:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCSI-000314-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 09:40:18 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANCSH-00030k-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 09:40:17 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 21 Nov 2003 09:39:24 -0500
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003112109392302517
 ; Fri, 21 Nov 2003 09:39:23 -0500
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XJP04GVA>; Fri, 21 Nov 2003 09:39:24 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D52026@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "'Steve Silverman '" <steves@shentel.net>,
        "'Mpierce1@aol.com '" <Mpierce1@aol.com>
Cc: "'ieprep@ietf.org '" <ieprep@ietf.org>
Date: Fri, 21 Nov 2003 09:39:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Ieprep] deja vu
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>

All,

I think the reason it is difficult to make definite statements about CAC
would work or not is tied to the fact that you don't have a fixed
architecture in mind.  (In fact, you haven't clearly defined the problem to
be solved.)

But, suppose I tell you this:

There is a core network that is super.  It has tons of capacity, extremely
low packet loss, low jitter and low delay.  We will engineer this network
such that if you never exceed amount X of type EF incoming the network from
each inbound link, and assuming some flexible traffic matrix, that these
packets are going to get great treatment 99.9% of the time.  That would
translate into great phone calls.

Now then I tell you this:

You have a bunch of feeder links into this network.  You have to limit the
amount of EF traffic you allow into the core network to be less than X per
link (I can be more general that this too).  You prefer to grant that EF
bandwidth to the most important calls so you install a local version of CAC
and tie it to the VoIP call signaling (either through an "IP PBX" or some
local QoS appliance box that sits at before the access link that does
stateful inspection of calls).  Your CAC can even preempt since it can be
stateful about what the MLPP level of on-going calls.

Okay.  Now, I'll bet this works pretty well, works with pretty much off the
shelf stuff, and so why not go and model it.  Furthermore, for the purpose
of this working group, somebody should really state (in a draft) the general
problem to be solved.  We can look at requirements and then analyze if there
is some gap in existing protocols.  

The question to ask is if it solves your problem, not if it solves it in the
exact same way as it was solved before.  

Kimberly

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



From exim@www1.ietf.org  Fri Nov 21 14:10:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27181
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 14:10:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGfM-00052K-He
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:10:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJA4HG019354
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGfM-000525-CP
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 14:10: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 OAA27169
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 14:09:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANGfJ-0007BL-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:10:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANGfJ-0007BI-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:10:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGfJ-00050f-Ej; Fri, 21 Nov 2003 14:10:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANGek-00050C-8f
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 14:09: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 OAA27155
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 14:09:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANGeh-0007Ar-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:09:23 -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 1ANGeh-0007AZ-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:09:23 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 21 Nov 2003 11:09:40 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALJ8pAt002770;
	Fri, 21 Nov 2003 11:08:51 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA25611; Fri, 21 Nov 2003 11:08:49 -0800 (PST)
Message-Id: <4.3.2.7.2.20031121130337.07988e00@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Nov 2003 13:08:52 -0600
To: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>,
        "'Steve Silverman '" <steves@shentel.net>,
        "'Mpierce1@aol.com '" <Mpierce1@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Ieprep] deja vu
Cc: "'ieprep@ietf.org '" <ieprep@ietf.org>
In-Reply-To: <D24D16A6707B0A4B9EF084299CE99B3906D52026@mcl-its-exs02.mai
 l.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Kimberly

One underlying assumption you are making about the CAC function below is 
that each knows where a destination endpoint is. You are not accounting for 
the mobility IP inherently brings to future networks.

At 09:39 AM 11/21/2003 -0500, King, Kimberly  S. wrote:
>All,
>
>I think the reason it is difficult to make definite statements about CAC
>would work or not is tied to the fact that you don't have a fixed
>architecture in mind.  (In fact, you haven't clearly defined the problem to
>be solved.)
>
>But, suppose I tell you this:
>
>There is a core network that is super.  It has tons of capacity, extremely
>low packet loss, low jitter and low delay.  We will engineer this network
>such that if you never exceed amount X of type EF incoming the network from
>each inbound link, and assuming some flexible traffic matrix, that these
>packets are going to get great treatment 99.9% of the time.  That would
>translate into great phone calls.
>
>Now then I tell you this:
>
>You have a bunch of feeder links into this network.  You have to limit the
>amount of EF traffic you allow into the core network to be less than X per
>link (I can be more general that this too).  You prefer to grant that EF
>bandwidth to the most important calls so you install a local version of CAC
>and tie it to the VoIP call signaling (either through an "IP PBX" or some
>local QoS appliance box that sits at before the access link that does
>stateful inspection of calls).  Your CAC can even preempt since it can be
>stateful about what the MLPP level of on-going calls.
>
>Okay.  Now, I'll bet this works pretty well, works with pretty much off the
>shelf stuff, and so why not go and model it.  Furthermore, for the purpose
>of this working group, somebody should really state (in a draft) the general
>problem to be solved.  We can look at requirements and then analyze if there
>is some gap in existing protocols.
>
>The question to ask is if it solves your problem, not if it solves it in the
>exact same way as it was solved before.
>
>Kimberly
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Fri Nov 21 14:36:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28142
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 14:36:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANH4X-0006sq-Jl
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:36:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJa5NJ026454
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:36:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANH4X-0006sa-CQ
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 14:36:05 -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 OAA28091
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 14:35:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANH4U-0007Wv-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:36:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANH4U-0007Wq-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:36:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANH4U-0006qn-NS; Fri, 21 Nov 2003 14:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANH3q-0006pG-4d
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 14:35:22 -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 OAA28052
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 14:35:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANH3n-0007Vy-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:35:19 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANH3m-0007Vv-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:35:18 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 21 Nov 2003 14:35:05 -0500
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003112114350424783
 ; Fri, 21 Nov 2003 14:35:04 -0500
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XJP04RHL>; Fri, 21 Nov 2003 14:35:04 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D5202D@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "'James M. Polk '" <jmpolk@cisco.com>,
        "'King, Kimberly  S. '" <KIMBERLY.S.KING@saic.com>,
        "''Steve Silverman ' '" <steves@shentel.net>,
        "''Mpierce1@aol.com ' '" <Mpierce1@aol.com>
Cc: "''ieprep@ietf.org ' '" <ieprep@ietf.org>
Subject: RE: [Ieprep] deja vu
Date: Fri, 21 Nov 2003 14:35:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Sender: jmpolk@localhost
X-Mailer: jmpolk@localhost
Content-Type: text/plain;
	charset="iso-8859-1"
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>

James,

>One underlying assumption you are making about the CAC 
>function below is
>that each knows where a destination endpoint is. 
>You are not accounting for 
>the mobility IP inherently brings to future networks.


I'll first make some assumption about what you might mean by mobility that
IP inherently brings to future networks.  If I guess wrong, then please
provide more specificity.

It appears you feel there is fault in my "solution".  I have assumed a
traffic matrix and so I'll surmise you find fault with the assumption that
such a matrix can exist accurately (due to mobility?).  

Question 1:  Have I guessed your concern?
Question 2:  If so, what does mobility have to do with it?  Please try to
explicitly write down what you are concerned about.

Kimberly





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



From exim@www1.ietf.org  Fri Nov 21 14:47:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28465
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 14:47: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 1ANHFA-0007ZH-VI
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:47:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALJl4Nk029085
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 14:47:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANHFA-0007Z2-Pm
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 14: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 OAA28456
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 14:46:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHF7-0007eQ-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:47:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHF7-0007eM-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 14:47:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANHF7-0007XQ-LY; Fri, 21 Nov 2003 14: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 1ANHEB-0007Wc-1U
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 14:46:03 -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 OAA28438
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 14:45:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHE8-0007cI-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:46:00 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHE7-0007cF-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 14:45:59 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 21 Nov 2003 14:45:50 -0500
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003112114454926847
 ; Fri, 21 Nov 2003 14:45:49 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XJQCQSXM>; Fri, 21 Nov 2003 14:45:49 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D5202F@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "''James M. Polk ' '" <jmpolk@cisco.com>,
        "'''Steve Silverman ' ' '" <steves@shentel.net>,
        "'''Mpierce1@aol.com ' ' '" <Mpierce1@aol.com>
Cc: "'''ieprep@ietf.org ' ' '" <ieprep@ietf.org>
Subject: RE: [Ieprep] deja vu
Date: Fri, 21 Nov 2003 14:45:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Mailer: jmpolk@localhost
X-Sender: jmpolk@localhost
Content-Type: text/plain;
	charset="iso-8859-1"
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>



James,

>One underlying assumption you are making about the CAC 
>function below is
>that each knows where a destination endpoint is. 
>You are not accounting for 
>the mobility IP inherently brings to future networks.

Another guess...you used the words "each knows where a destination endpoint
is".  Okay, I'll address that part more clearly.

One doesn't need to know where the endpoint is.  If Joe moves his IP phone
to another base, that's fine because the smart CAC and normal SIP address
resolution/IP routing will take care of the problem.

Why?

Because the CAC doesn't just control who gets to place outbound calls, it
also intercepts inbound SIP messages.  

Suppose we are at a LAN with a link into the core network that can support
24 quality VoIP calls.  Now suppose 24 are occurring and they are all
routine.  An important call request comes in over that link from somewhere
else.  CAC looks at the SIP message and the RP header says it's a priority
call request.  So, CAC kills one of the existing routine calls and allows
the priority one to setup.  We now have bandwidth on our access link (both
at origination and where it is accepted).  The core is fine.  Life is good.

I don't think this problem is that hard but it must be defined or people are
going to talk in circles.  I'm getting dizzy and I'm a levelheaded woman.
:-)

Kimberly

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



From exim@www1.ietf.org  Fri Nov 21 15:16:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00567
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 15:16: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 1ANHhD-0000vA-B5
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15:16:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALKG3YJ003509
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15:16:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANHhD-0000uW-2a
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 15:16:03 -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 PAA00487
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 15:15:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHhB-0000AK-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15:16:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHhB-0000AH-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15:16:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANHhB-0000tm-DR; Fri, 21 Nov 2003 15: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 1ANHgS-0000pg-Rn
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 15:15:16 -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 PAA00412
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 15:15:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANHgR-00009t-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:15:15 -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 1ANHgR-00009O-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:15:15 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 12:15:20 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hALKEhjq002609;
	Fri, 21 Nov 2003 12:14:43 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA06981; Fri, 21 Nov 2003 12:14:41 -0800 (PST)
Message-Id: <4.3.2.7.2.20031121140127.07a45e60@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Nov 2003 14:14:43 -0600
To: "'King, Kimberly  S. '" <KIMBERLY.S.KING@saic.com>,
        "''Steve Silverman ' '" <steves@shentel.net>,
        "''Mpierce1@aol.com ' '" <Mpierce1@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] deja vu
Cc: "''ieprep@ietf.org ' '" <ieprep@ietf.org>
In-Reply-To: <D24D16A6707B0A4B9EF084299CE99B3906D5202D@mcl-its-exs02.mai
 l.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 02:35 PM 11/21/2003 -0500, King, Kimberly  S. wrote:
>James,
>
> >One underlying assumption you are making about the CAC
> >function below is
> >that each knows where a destination endpoint is.
> >You are not accounting for
> >the mobility IP inherently brings to future networks.
>
>
>I'll first make some assumption about what you might mean by mobility that
>IP inherently brings to future networks.  If I guess wrong, then please
>provide more specificity.
>
>It appears you feel there is fault in my "solution".  I have assumed a
>traffic matrix and so I'll surmise you find fault with the assumption that
>such a matrix can exist accurately (due to mobility?).
>
>Question 1:  Have I guessed your concern?

yep

>Question 2:  If so, what does mobility have to do with it?

It means there isn't a deterministic outbound path of classifiable calls.

The IP PBX you mention - how does it know when a call is "not for this LAN"?

For example, is "capt.john.doe@usmc.mil" on this LAN, or another - and how 
would the IP PBX know this to know the layer 3 route the media will take?

I am assuming you are modeling the IP PBX to be aware of the separation of 
LAN to WAN (meaning everything not on this LAN); and that you are assuming 
the IP PBX will know when to invoke some CAC function on such call 
signaling when received.

In an all IP environment - you are assuming an application Server (the IP 
PBX) will be aware of outbound trunking utilization (for every outbound 
router interface, fairly real-time).

By what means are you to realize this "awareness"? COPS? SNMP? Or are you 
assuming/suggesting the IP PBX always keep track of all calls (counting the 
different BWs used by different codecs) in and out of a LAN to effectively 
understand when a particular router interface is reaching saturation levels 
of a particular traffic type?

>Please try to
>explicitly write down what you are concerned about.

I hope I have


>Kimberly


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Fri Nov 21 15:42:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01515
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 15:42: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 1ANI6P-0002Cm-CB
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15:42:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALKg5Sv008470
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15:42:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANI6P-0002CX-8O
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 15:42:05 -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 PAA01511
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 15:41:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANI6N-0000UZ-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15:42:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANI6N-0000UW-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15: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 1ANI6L-0002Ba-HH; Fri, 21 Nov 2003 15: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 1ANI5d-0002BF-R6
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 15:41: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 PAA01501
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 15:41:05 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANI5c-0000UH-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:41:16 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANI5b-0000U7-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:41:16 -0500
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hALKehw5016862;
	Fri, 21 Nov 2003 12:40:43 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA24953; Fri, 21 Nov 2003 12:40:41 -0800 (PST)
Message-Id: <4.3.2.7.2.20031121141637.028bc488@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Nov 2003 14:40:43 -0600
To: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>,
        "'''Steve Silverman ' ' '" <steves@shentel.net>,
        "'''Mpierce1@aol.com ' ' '" <Mpierce1@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] deja vu
Cc: "'''ieprep@ietf.org ' ' '" <ieprep@ietf.org>
In-Reply-To: <D24D16A6707B0A4B9EF084299CE99B3906D5202F@mcl-its-exs02.mai
 l.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 02:45 PM 11/21/2003 -0500, King, Kimberly  S. wrote:


>James,
>
> >One underlying assumption you are making about the CAC
> >function below is
> >that each knows where a destination endpoint is.
> >You are not accounting for
> >the mobility IP inherently brings to future networks.
>
>Another guess...you used the words "each knows where a destination endpoint
>is".  Okay, I'll address that part more clearly.
>
>One doesn't need to know where the endpoint is.  If Joe moves his IP phone
>to another base, that's fine because the smart CAC and normal SIP address
>resolution/IP routing will take care of the problem.
>
>Why?
>
>Because the CAC doesn't just control who gets to place outbound calls, it
>also intercepts inbound SIP messages.

Not necessarily.

If LAN A has a Proxy that knows the IP address of UA2 on LAN B, it sends 
the SIP INVITE directly to UA2's IP address. This will bypass the Proxy in 
LAN B where UA2 currently lives.


>Suppose we are at a LAN with a link into the core network that can support
>24 quality VoIP calls.  Now suppose 24 are occurring and they are all
>routine.  An important call request comes in over that link from somewhere
>else.  CAC looks at the SIP message and the RP header says it's a priority
>call request.

So.... the CAC knows exactly how many calls exist on a particular link, how 
very much like a Gatekeeper this is looking.

What are the codecs used on each of these calls?

Have any of the calls changed codecs, thus bandwidths, to affect how much 
bandwidth is available?

Does the CAC know this?

How does it know this?

Does the CAC in LAN A have to know the presence of the CAC on LAN B?

What about LAN C?

What about LAN AZ, or FZ?

Does this approach scale?

Does each CAC have to be configured with every other CAC (by IP address?

What about multiple links out of a LAN into this core network?


>  So, CAC kills one of the existing routine calls and allows
>the priority one to setup.

Please re-read
http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.txt
because SIP Servers are not envisioned to act this way.

>We now have bandwidth on our access link (both
>at origination and where it is accepted).  The core is fine.  Life is good.

Life is good if what you're proposing knows about all of it and is aware of 
all of it in real-time all of the time....


>I don't think this problem is that hard but it must be defined or people are
>going to talk in circles.

How don't RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750, 2753, 2996, 3175 
and 3181 address this without creating this real-time CAC IP PBX that can't 
scale to meet the requirements?

At the end of the day, you are suggesting using out of band signaling to 
control the number of sessions on the data path. Only in-data-path 
signaling can properly control data path sessions.

Remember the Flows ID.... this was the point made there

>I'm getting dizzy and I'm a levelheaded woman.

Hey.... you volunteered to be WG chair here....

>:-)
>
>Kimberly
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Fri Nov 21 15:52:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01746
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 15:52: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 1ANIG2-0002hx-Va
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15:52:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALKq24o010403
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 15: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 1ANIG2-0002hi-S5
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 15:52:02 -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 PAA01742
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 15:51:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIG1-0000bY-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15:52:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIG0-0000bV-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 15:52:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANIG1-0002f0-8q; Fri, 21 Nov 2003 15:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANIF3-0002Rm-EU
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 15:51: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 PAA01732
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 15:50:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIF1-0000b7-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:51:00 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIF1-0000b4-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 15:50:59 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 21 Nov 2003 15:50:54 -0500
Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003112115505305397
 ; Fri, 21 Nov 2003 15:50:53 -0500
Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XJP04TS8>; Fri, 21 Nov 2003 15:50:54 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D52030@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "'James M. Polk '" <jmpolk@cisco.com>,
        "''King, Kimberly  S. ' '" <KIMBERLY.S.KING@saic.com>,
        "'''Steve Silverman ' ' '" <steves@shentel.net>,
        "'''Mpierce1@aol.com ' ' '" <Mpierce1@aol.com>
Cc: "'''ieprep@ietf.org ' ' '" <ieprep@ietf.org>
Subject: RE: [Ieprep] deja vu
Date: Fri, 21 Nov 2003 15:50:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Sender: jmpolk@localhost
X-Mailer: jmpolk@localhost
Content-Type: text/plain;
	charset="iso-8859-1"
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>

James,

I'll write more of "a solution" using a QoS appliance.  An IP-PBX solution
is something you can work on... :-)  

I'll put a smart QoS appliance on each LAN just before the WAN link.  If SIP
signaling traverses that link, the callee is not local and subject to being
tracked and counted. If signaling doesn't traverse it then it's a local LAN
call and it can be ignored (assume LAN bandwidth is not a problem).

This means I want some local proxy that knows what users are local and can
resolve what local address it goes to.  I also want proxies in the core that
tell exactly where the endpoint is.  I don't want to redirect through a LAN.
That ought not be so hard to ensure even if it takes a kludge with some
redundant information.

This should take care of the issues.  It's the big picture of a particular
solution.  One can nit pick forever and nobody proves anything because the
requirements aren't there to examine and show that a solution meets them or
not.

Anyone want to write up the problem to be solved and some of the
constraints?

Kimberly

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



From exim@www1.ietf.org  Fri Nov 21 16:12:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03190
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 16: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 1ANIZO-0005Hx-W7
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 16:12:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLC2lh020323
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 16:12:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANIZO-0005He-Ni
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:12:02 -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 QAA03170
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 16:11:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIZM-0000yr-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 16:12:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIZM-0000yo-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 16:12:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANIZM-0005G7-V6; Fri, 21 Nov 2003 16:12:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANIYt-0005Fm-MW
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 16:11: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 QAA03150
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 16:11:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIYr-0000yI-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 16:11:30 -0500
Received: from mclmx.mail.saic.com ([149.8.64.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANIYr-0000y8-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 16:11:29 -0500
Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Fri, 21 Nov 2003 16:10:58 -0500
Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12])
 by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003112116105808630
 ; Fri, 21 Nov 2003 16:10:58 -0500
Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <XJQCQ9AA>; Fri, 21 Nov 2003 16:10:58 -0500
Message-Id: <D24D16A6707B0A4B9EF084299CE99B3906D52031@mcl-its-exs02.mail.saic.com>
From: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>
To: "'James M. Polk '" <jmpolk@cisco.com>,
        "'King, Kimberly  S. '" <KIMBERLY.S.KING@saic.com>,
        "''''Steve Silverman ' ' ' '" <steves@shentel.net>,
        "''''Mpierce1@aol.com ' ' ' '" <Mpierce1@aol.com>
Cc: "''''ieprep@ietf.org ' ' ' '" <ieprep@ietf.org>
Subject: RE: [Ieprep] deja vu
Date: Fri, 21 Nov 2003 16:10:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Sender: jmpolk@localhost
X-Mailer: jmpolk@localhost
Content-Type: text/plain;
	charset="iso-8859-1"
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>

James,

>>  So, CAC kills one of the existing routine calls and allows
>>the priority one to setup.

>Please re-read
>http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.
>txt
>because SIP Servers are not envisioned to act this way.

Obviously, I just don't understand this problem you are trying to solve.  It
must be really hard.  Maybe if it were defined the experts could ponder it a
while.

Kimberly

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



From exim@www1.ietf.org  Fri Nov 21 16:53:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05119
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 16:53: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 1ANJD8-0007B2-13
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 16:53:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLr5lE027582
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 16:53:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJD7-0007An-N3
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:53:05 -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 QAA05070
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 16:52:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJD5-0001hC-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 16:53:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJD4-0001h7-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 16:53:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJD4-0007A6-2s; Fri, 21 Nov 2003 16:53:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJCU-00078V-Di
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 16:52: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 QAA05033
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 16:52:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJCS-0001g1-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 16:52:24 -0500
Received: from kc-msxproto3.kc.umkc.edu ([134.193.143.160])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJCR-0001fp-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 16:52:23 -0500
Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 21 Nov 2003 15:52:18 -0600
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Subject: RE: [Ieprep] deja vu
Date: Fri, 21 Nov 2003 15:52:18 -0600
Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110817C@KC-MAIL4.kc.umkc.edu>
Thread-Topic: [Ieprep] deja vu
Thread-Index: AcOwbEuhnlspSi6uR2evySj5U3SxkwAC27C1
From: "Ayyasamy, Senthilkumar  \(UMKC-Student\)" <saq66@umkc.edu>
To: "James M. Polk" <jmpolk@cisco.com>,
        "King, Kimberly  S. " <KIMBERLY.S.KING@saic.com>,
        "'Steve Silverman ' " <steves@shentel.net>, <Mpierce1@aol.com>
Cc: <ieprep@ietf.org>
X-OriginalArrivalTime: 21 Nov 2003 21:52:18.0538 (UTC) FILETIME=[BBD5ACA0:01C3B079]
Content-Transfer-Encoding: quoted-printable
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>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

>>One underlying assumption you are making about the CAC
>>function below is
>>that each knows where a destination endpoint is.
>>You are not accounting for
>>the mobility IP inherently brings to future networks.
=20
kimberly's proposal is the easiest solution using existing
standards (RSVP + some kind of marking + EF). It is far
better than creating a new PHB (which doesn't actually
implement MLPP feature.i.e. preemption.) As you mention,=20
she did not take receiver end network profile into account=20
(which requires COPS etc.) But, Is it a necessary feature=20
in a single administrative environment?=20

But, I also don't understand your usage of the term "mobility"
in this context. Is it personal mobility ? terminal mobility?=20
or some other thing... If so, you need SIP  REGISTER request=20
and DNS SRV to do the magic. But, that doesn't answer signaling
for mobility. I presume, nsis should be focusing on those=20
important questions(?).

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



From exim@www1.ietf.org  Fri Nov 21 17:13:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07105
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 17:13: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 1ANJWT-0000lX-3d
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMD5rK002935
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 17:13:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJWS-0000lG-Vg
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:13: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 RAA07042
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 17:12:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJWQ-0002Qz-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJWQ-0002Qv-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 17:13:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJWQ-0000jf-Af; Fri, 21 Nov 2003 17:13:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJW6-0000hJ-4B
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 17:12:42 -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 RAA07019
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 17:12:28 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJW3-0002QI-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 17:12:39 -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 1ANJW3-0002Pd-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 17:12:39 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 14:12:45 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hALMC6jq016794;
	Fri, 21 Nov 2003 14:12:07 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA07562; Fri, 21 Nov 2003 14:12:05 -0800 (PST)
Message-Id: <4.3.2.7.2.20031121155236.07908f00@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Nov 2003 16:12:06 -0600
To: "King, Kimberly  S." <KIMBERLY.S.KING@saic.com>,
        "''King, Kimberly  S. ' '" <KIMBERLY.S.KING@saic.com>,
        "'''Steve Silverman ' ' '" <steves@shentel.net>,
        "'''Mpierce1@aol.com ' ' '" <Mpierce1@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] deja vu
Cc: "'''ieprep@ietf.org ' ' '" <ieprep@ietf.org>
In-Reply-To: <D24D16A6707B0A4B9EF084299CE99B3906D52030@mcl-its-exs02.mai
 l.saic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 03:50 PM 11/21/2003 -0500, King, Kimberly  S. wrote:
>James,
>
>I'll write more of "a solution" using a QoS appliance.  An IP-PBX solution
>is something you can work on... :-)
>
>I'll put a smart QoS appliance on each LAN just before the WAN link.

Just like a Firewall - ensuring no packets get by this IP-PBX without its 
knowledge, or is this IP-PBX in a DMZ, or is this IP-PBX merely "near" the 
LAN to WAN router? What about LANs that are really big, requiring not just 
redundant paths (meaning there MUST be at least two such IP-PBXs - one per 
path), but one per path/redundant path pair. What about redundant IP-PBXs - 
ensuring one "just before the WAN" failing doesn't fail the system?

This is getting expensive.

>If SIP
>signaling traverses that link, the callee is not local and subject to being
>tracked and counted.

This will only work in SIP if the packet has the CAC IP-PBX in its IP DA 
field; otherwise, the packet will slip on by

>If signaling doesn't traverse it then it's a local LAN
>call and it can be ignored (assume LAN bandwidth is not a problem).
>
>This means I want some local proxy that knows what users are local and can
>resolve what local address it goes to.  I also want proxies in the core that
>tell exactly where the endpoint is.

Meaning there is no e2e encryption.... interesting

this also forces packets to take paths that are not efficient - which is 
not an efficient use of precious resources

>I don't want to redirect through a LAN.
>That ought not be so hard to ensure even if it takes a kludge with some
>redundant information.

Why should we design/model/build to a kludge?

Why not get it right the first time?


>This should take care of the issues.  It's the big picture of a particular
>solution.  One can nit pick forever and nobody proves anything because the
>requirements aren't there to examine and show that a solution meets them or
>not.

requirements are one thing, evidence that something doesn't work makes the 
requirement(s) moot

What actual, tangible analysis has been done to justify this big picture 
being presented here?


>Anyone want to write up the problem to be solved and some of the
>constraints?

It seems that most on this list aren't qualified to do such a task, as the 
requirements of this type of network are not complete or consistent. Given 
that fact, how can a problem be written up?


>Kimberly


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Fri Nov 21 17:33:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09084
	for <ieprep-archive@odin.ietf.org>; Fri, 21 Nov 2003 17:33: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 1ANJpn-0002pw-L9
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 17:33:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMX3jV010902
	for ieprep-archive@odin.ietf.org; Fri, 21 Nov 2003 17:33:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJpn-0002pl-Fj
	for ieprep-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:33:03 -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 RAA09024
	for <ieprep-web-archive@ietf.org>; Fri, 21 Nov 2003 17:32:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJpk-0003Dd-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 17:33:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJpk-0003DS-00
	for ieprep-web-archive@ietf.org; Fri, 21 Nov 2003 17:33:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJpl-0002oe-Eg; Fri, 21 Nov 2003 17:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANJpP-0002kR-L0
	for ieprep@optimus.ietf.org; Fri, 21 Nov 2003 17:32:39 -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 RAA08994
	for <ieprep@ietf.org>; Fri, 21 Nov 2003 17:32:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANJpN-0003Cs-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 17:32:37 -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 1ANJpM-0003CB-00
	for ieprep@ietf.org; Fri, 21 Nov 2003 17:32:36 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 14:32:42 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hALMW3w5015242;
	Fri, 21 Nov 2003 14:32:03 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA11238; Fri, 21 Nov 2003 14:32:01 -0800 (PST)
Message-Id: <4.3.2.7.2.20031121162042.07993f00@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Nov 2003 16:32:02 -0600
To: "Ayyasamy, Senthilkumar  \(UMKC-Student\)" <saq66@umkc.edu>,
        "King, Kimberly  S. " <KIMBERLY.S.KING@saic.com>,
        "'Steve Silverman ' " <steves@shentel.net>, <Mpierce1@aol.com>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] deja vu
Cc: <ieprep@ietf.org>
In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B0110817C@KC-MAIL4.kc.umkc.
 edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 03:52 PM 11/21/2003 -0600, Ayyasamy, Senthilkumar  \(UMKC-Student\) wrote:
> >>One underlying assumption you are making about the CAC
> >>function below is
> >>that each knows where a destination endpoint is.
> >>You are not accounting for
> >>the mobility IP inherently brings to future networks.
>
>kimberly's proposal is the easiest solution using existing
>standards (RSVP + some kind of marking + EF).

We wouldn't be having this disagreement if this was Kimberly's proposal. 
She isn't proposing RSVP at all - because it would be *the CAC function*; 
thereby not requiring any IP PBX to count the number of calls that exist on 
an outbound trunk from a LAN.

>  It is far
>better than creating a new PHB (which doesn't actually
>implement MLPP feature.i.e. preemption.)

At least the two of us agree, this will not solve the problem

>As you mention,
>she did not take receiver end network profile into account
>(which requires COPS etc.) But, Is it a necessary feature
>in a single administrative environment?

depends on the size of the domain - clearly MLPP is for the largest of 
domains, making this uncertain at best


>But, I also don't understand your usage of the term "mobility"
>in this context. Is it personal mobility ? terminal mobility?
>or some other thing... If so, you need SIP  REGISTER request
>and DNS SRV to do the magic.

Does SIP REGISTER tell a CAC IP PBX the bandwidth required for a given 
call? Does it add up all the bandwidths of existing calls on a given router 
interface? Without that information - how can that IP PBX do effective BW 
control to the point of preempting existing calls because there was no more 
BW available at a given precedence level?

BTW - how does an IP PBX know the utilization of a router interface?

>But, that doesn't answer signaling
>for mobility. I presume, nsis should be focusing on those
>important questions(?).
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Sat Nov 22 17:11:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22983
	for <ieprep-archive@odin.ietf.org>; Sat, 22 Nov 2003 17:11: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 1ANfy9-0000qn-PL
	for ieprep-archive@odin.ietf.org; Sat, 22 Nov 2003 17:11:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMMB9mU003270
	for ieprep-archive@odin.ietf.org; Sat, 22 Nov 2003 17:11:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANfy9-0000qe-In
	for ieprep-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 17:11: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 RAA22941
	for <ieprep-web-archive@ietf.org>; Sat, 22 Nov 2003 17:10:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANfy6-0002sH-00
	for ieprep-web-archive@ietf.org; Sat, 22 Nov 2003 17:11:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANfy6-0002sB-00
	for ieprep-web-archive@ietf.org; Sat, 22 Nov 2003 17:11:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANfy2-0000or-Bo; Sat, 22 Nov 2003 17:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMcLV-0007Xg-RZ
	for ieprep@optimus.ietf.org; Wed, 19 Nov 2003 19:06:53 -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 TAA24691;
	Wed, 19 Nov 2003 19:06:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMcLL-0006r6-00; Wed, 19 Nov 2003 19:06:43 -0500
Received: from obomta.csc.com ([20.137.252.211] helo=amer-bmta04.csc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMcLH-0006qz-00; Wed, 19 Nov 2003 19:06:39 -0500
Received: from csc.com (va-fch32.csc.com [20.6.39.233])
	by amer-bmta04.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAK06xx9008248;
	Wed, 19 Nov 2003 19:07:03 -0500 (EST)
Subject: RE: [IEPREP] MLPPoIP effort?
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
Cc: "'Eagan, Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org,
        ieprep-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OFDF9CAC1E.B4FA75B7-ON85256DE4.00001658-85256DE4.0000AC4B@com>
From: "Janet P Gunn" <jgunn6@csc.com>
Date: Wed, 19 Nov 2003 19:07:21 -0500
X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 5.0.11  |July 24, 2002) at
 11/19/2003 07:07:49 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>


Considering that WPS (Wireless Priority Service) is one of the current
(PSTN based) Emergency Preparedness services that represents the kind of
service IEPREP wants to help migrate to the Internet and IP networks in
general, and WPS uses eMLPP (enhanced MLPP), it seems perfectly reasonable
to consider MLPPoIP here.

  eMLPP allows for configuration of precedence without priority if so
desired, and is thus more flexible than "straight" MLPP.


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

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




                                                                                                                                
                      "King, Kimberly                                                                                           
                      S."                      To:      "'Eagan, Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org    
                      <KIMBERLY.S.KING         cc:                                                                              
                      @saic.com>               Subject: RE: [IEPREP] MLPPoIP effort?                                            
                      Sent by:                                                                                                  
                      ieprep-admin                                                                                              
                                                                                                                                
                                                                                                                                
                      11/19/2003 10:55                                                                                          
                      AM                                                                                                        
                                                                                                                                
                                                                                                                                





>it appears IEPREP is focused on the Internet
> whereas the private networks deal with a more configurable
> environment (chairs?).

IEPREP is also talking about access networks (some use the term stub
domains) that provide a "more configurable environment" for behavior within
that network alone but may still be part of the Internet.

> I guess the issue is, can we somehow unify, and invigorate
> some of these efforts under a common goal of MLPPoIP?  Is
> IEPREP the place to do it or should it be an additional
> working group?

With respect to MLPPoIP (a.k.a. Assured Service--MLPP was the name of the
particular solution within a circuit-switched environment to the general
requirement of Assured Service).  What does the working group think of
IEPREP describing requirements for MLPP services explicitly?

The charter says "Quick response for recovery
operations requires immediate access to any public telecommunications
capabilities at hand. " and we agreed access networks that were part of the
Internet may be part of public telecommunications.  Does MLPP fit the
charter?  So, I like Ken's suggestion of a draft that is more explicit
about
what is being sought.

Kimberly

_______________________________________________
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



From exim@www1.ietf.org  Sat Nov 22 17:58:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22984
	for <ieprep-archive@odin.ietf.org>; Sat, 22 Nov 2003 17:11: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 1ANfy9-0000r9-TR
	for ieprep-archive@odin.ietf.org; Sat, 22 Nov 2003 17:11:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAMMB9v8003283
	for ieprep-archive@odin.ietf.org; Sat, 22 Nov 2003 17:11:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANfy9-0000qj-NY
	for ieprep-web-archive@optimus.ietf.org; Sat, 22 Nov 2003 17:11: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 RAA22944
	for <ieprep-web-archive@ietf.org>; Sat, 22 Nov 2003 17:10:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANfy7-0002sK-00
	for ieprep-web-archive@ietf.org; Sat, 22 Nov 2003 17:11:07 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ANfy6-0002sD-00
	for ieprep-web-archive@ietf.org; Sat, 22 Nov 2003 17:11:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ANfy2-0000p6-PN; Sat, 22 Nov 2003 17:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AMrsO-0006vu-IF
	for ieprep@optimus.ietf.org; Thu, 20 Nov 2003 11:41:52 -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 LAA12458
	for <ieprep@ietf.org>; Thu, 20 Nov 2003 11:41:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMrsN-0005oA-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 11:41:51 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AMrsN-0005o2-00
	for ieprep@ietf.org; Thu, 20 Nov 2003 11:41:51 -0500
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 hAKGfGAv023035;
	Thu, 20 Nov 2003 08:41:18 -0800 (PST)
Received: from CSCOAMERA19540.cisco.com (dhcp-171-71-194-99.cisco.com [171.71.194.99])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ANT62911;
	Thu, 20 Nov 2003 08:41:15 -0800 (PST)
Message-Id: <6.0.0.22.2.20031120082249.051b0160@mira-sjc5-b.cisco.com >
X-Sender: fred@mira-sjc5-b.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 20 Nov 2003 08:26:59 -0800
To: Mpierce1@aol.com
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: steves@shentel.net, saq66@umkc.edu, ieprep@ietf.org
In-Reply-To: <38.3f14c123.2cee29ce@aol.com>
References: <38.3f14c123.2cee29ce@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 06:29 AM 11/20/2003, Mpierce1@aol.com wrote:
>Yes, I believe this has been suggested. The obvious problem is trying to 
>define an algorithm that would allow a terminal to distinguish between 
>packet loss from congestion that isn't going to go away, and packet loss 
>that is going to go away rather quickly anyway (as in my example), and 
>packet loss due to something other than congestion. I tend to think that 
>this is not possible.

actually, the obvious problem is that if we are dropping traffic from a 
precedence class, we are dropping roughly equal amounts from all calls 
within that class. If it is bad enough that some calls would give up, one 
must presume that all relevant sessions will at minimum ask the question. 
Why does one believe that they will not all, or some significant subset, 
drop? if this is done at a time when a number of sessions are being 
established, this becomes a rolling pattern - if we have enough calls for 
110% of the bandwidth, and are therefore dropping 10% of traffic in the 
precedence class, one would expect calls to drop and re-establish randomly 
in a rolling pattern.

The policy and predictability of the system is pretty suspect, I think. 


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



From exim@www1.ietf.org  Mon Nov 24 16:57:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04548
	for <ieprep-archive@odin.ietf.org>; Mon, 24 Nov 2003 16:57: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 1AOOhg-00054j-6A
	for ieprep-archive@odin.ietf.org; Mon, 24 Nov 2003 16:57:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOLv8pv019508
	for ieprep-archive@odin.ietf.org; Mon, 24 Nov 2003 16:57:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOOhe-00054Z-Ks
	for ieprep-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:57: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 QAA04482
	for <ieprep-web-archive@ietf.org>; Mon, 24 Nov 2003 16:56:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOOhc-0006HA-00
	for ieprep-web-archive@ietf.org; Mon, 24 Nov 2003 16:57:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOOhc-0006H7-00
	for ieprep-web-archive@ietf.org; Mon, 24 Nov 2003 16:57:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOOhZ-00053f-6u; Mon, 24 Nov 2003 16:57:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOOgj-00051T-AH
	for ieprep@optimus.ietf.org; Mon, 24 Nov 2003 16:56: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 QAA04261
	for <ieprep@ietf.org>; Mon, 24 Nov 2003 16:55:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOOgh-0006C4-00
	for ieprep@ietf.org; Mon, 24 Nov 2003 16:56:07 -0500
Received: from conure.mail.pas.earthlink.net ([207.217.120.54])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOOgg-0006Bg-00
	for ieprep@ietf.org; Mon, 24 Nov 2003 16:56:06 -0500
Received: from bigbird.psp.pas.earthlink.net ([207.217.78.244])
	by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1AOOez-0004oZ-00; Mon, 24 Nov 2003 13:54:21 -0800
Message-ID: <12228653.1069710861162.JavaMail.root@bigbird.psp.pas.earthlink.net>
Date: Mon, 24 Nov 2003 13:53:39 -0800 (PST)
From: Janet Gunn <jgunn@ix.netcom.com>
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
To: Steve Silverman <steves@shentel.net>, "James M. Polk" <jmpolk@cisco.com>,
        ieprep@ietf.org
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: fred@cisco.com
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

The "factor of 3" or   "1/3" applies to the mean or average traffic rate.  In order to figure anything out about how often that is going to lead to over 100% utilization on a given link, we need to know something about the DISTRIBUTION, over various time intervals.   We also need this information to figure out how effective the various strategies would be. Does this information exist?

The effect is going to be very different depending on the "size of the pipes".  A link that is equvalent to, say, 5 "full time" connections is going to have much more variability in the total, and is threfore going to go over capacity more often, thatn a link that is equivalent to 100s of "full time" connections.  So stratgies that would be effective on "big pipes" might be inadequate on "little pipes".

Janet

-----Original Message-----
From: Steve Silverman <steves@shentel.net>
Sent: Nov 20, 2003 1:55 PM
To: "James M. Polk" <jmpolk@cisco.com>, ieprep@ietf.org
Cc: fred@cisco.com
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls



> -----Original Message-----
> From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org]On Behalf Of
> James M. Polk
> Sent: Thursday, November 20, 2003 3:00 PM
> To: ieprep@ietf.org
> Cc: fred@cisco.com
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
> At 02:39 PM 11/20/2003 -0500, Steve Silverman wrote:
> >Responses below.
> >
> >It seems to me that if bandwidth is scarce, silence
> suppression is a major
> >benefit. Typical users only speak for one third of the
> time.  But the CAC
> >simply reserves enough bandwidth in each direction for
> continuous speech
> >-  A factor of 3 in actual utilization.  Does this seem a
> reasonable approach
> >to anyone?
>
> Are you suggesting the choice is no CAC or CAC that might
> waste 2/3rds of
> the BW for that session?

No.  I am saying that if silence suppression is used (and I think it
should be used) the
 deterministic busy signal calculation of the Circuit Switched world
is impossible in a Packet Switched
world.  Consequently, to maximize the utility of limited bandwidth,
some prioritization is required
and mechanisms to work within this environment need to be addressed.


>
> Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750,
> 2753, 2996, 3175
> and 3181. The first and last of this list are especially
> relevant to your
> environments
>
> >Has anyone
> >done a CAC to handle the DOD forces in the Middle East?
> I would assume
> >we don't have much fiber there.
>
> Connectivity and bandwidth awareness are the issue here,
> not whether there
> is fiber or not

The only reason I mention fiber is that in general, fiber provides an
abundance
of bandwidth but here I am focused on the case where bandwidth is a
scarce resource.



>
> >Can anyone supply the relevant facts or are they classified?
>
> I believe testing and analysis should be done prior to
> proposing solutions
> to incomplete requirements
>

I fully agree.
We had been   analyzing and testing before our funds ran out.
Is anyone looking at these issues and running the
appropriate testing.  I hope that my current impression that
these issues are being ignored is incorrect.


Steve

>



_______________________________________________
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



From exim@www1.ietf.org  Mon Nov 24 17:43:17 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07744
	for <ieprep-archive@odin.ietf.org>; Mon, 24 Nov 2003 17:43: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 1AOPQ7-000821-D4
	for ieprep-archive@odin.ietf.org; Mon, 24 Nov 2003 17:43:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOMh3NO030867
	for ieprep-archive@odin.ietf.org; Mon, 24 Nov 2003 17:43:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOPQ7-00081m-8l
	for ieprep-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 17:43:03 -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 RAA07709
	for <ieprep-web-archive@ietf.org>; Mon, 24 Nov 2003 17:42:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOPQ4-0007aJ-00
	for ieprep-web-archive@ietf.org; Mon, 24 Nov 2003 17:43:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOPQ4-0007aG-00
	for ieprep-web-archive@ietf.org; Mon, 24 Nov 2003 17:43:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOPQ5-000811-2z; Mon, 24 Nov 2003 17:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOPPN-0007yi-6q
	for ieprep@optimus.ietf.org; Mon, 24 Nov 2003 17:42: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 RAA07680;
	Mon, 24 Nov 2003 17:42:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOPPK-0007Yt-00; Mon, 24 Nov 2003 17:42:14 -0500
Received: from conure.mail.pas.earthlink.net ([207.217.120.54])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOPPJ-0007Yq-00; Mon, 24 Nov 2003 17:42:14 -0500
Received: from bigbird.psp.pas.earthlink.net ([207.217.78.244])
	by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1AOPOi-0002hY-00; Mon, 24 Nov 2003 14:41:36 -0800
Message-ID: <13347449.1069713696182.JavaMail.root@bigbird.psp.pas.earthlink.net>
Date: Mon, 24 Nov 2003 14:40:38 -0800 (PST)
From: Janet Gunn <jgunn@ix.netcom.com>
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
To: Janet P Gunn <jgunn6@csc.com>,
        "King,Kimberly S." <KIMBERLY.S.KING@saic.com>
Subject: RE: [IEPREP] MLPPoIP effort?
Cc: "'Eagan,Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org,
        ieprep-admin@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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I must have been brain dead.  

What I MEANT to say is that eMLPP can be configured for precedence without PRE-EMPTION.

Sorry for the confusion.

-----Original Message-----
From: Janet P Gunn <jgunn6@csc.com>
Sent: Nov 19, 2003 4:07 PM
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>
Cc: "'Eagan, Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org, 
	ieprep-admin@ietf.org
Subject: RE: [IEPREP] MLPPoIP effort?


Considering that WPS (Wireless Priority Service) is one of the current
(PSTN based) Emergency Preparedness services that represents the kind of
service IEPREP wants to help migrate to the Internet and IP networks in
general, and WPS uses eMLPP (enhanced MLPP), it seems perfectly reasonable
to consider MLPPoIP here.

  eMLPP allows for configuration of precedence without priority if so
desired, and is thus more flexible than "straight" MLPP.


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

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




                                                                                                                                
                      "King, Kimberly                                                                                           
                      S."                      To:      "'Eagan, Christopher'" <christopher.eagan@lmco.com>, ieprep@ietf.org    
                      <KIMBERLY.S.KING         cc:                                                                              
                      @saic.com>               Subject: RE: [IEPREP] MLPPoIP effort?                                            
                      Sent by:                                                                                                  
                      ieprep-admin                                                                                              
                                                                                                                                
                                                                                                                                
                      11/19/2003 10:55                                                                                          
                      AM                                                                                                        
                                                                                                                                
                                                                                                                                





>it appears IEPREP is focused on the Internet
> whereas the private networks deal with a more configurable
> environment (chairs?).

IEPREP is also talking about access networks (some use the term stub
domains) that provide a "more configurable environment" for behavior within
that network alone but may still be part of the Internet.

> I guess the issue is, can we somehow unify, and invigorate
> some of these efforts under a common goal of MLPPoIP?  Is
> IEPREP the place to do it or should it be an additional
> working group?

With respect to MLPPoIP (a.k.a. Assured Service--MLPP was the name of the
particular solution within a circuit-switched environment to the general
requirement of Assured Service).  What does the working group think of
IEPREP describing requirements for MLPP services explicitly?

The charter says "Quick response for recovery
operations requires immediate access to any public telecommunications
capabilities at hand. " and we agreed access networks that were part of the
Internet may be part of public telecommunications.  Does MLPP fit the
charter?  So, I like Ken's suggestion of a draft that is more explicit
about
what is being sought.

Kimberly

_______________________________________________
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



From exim@www1.ietf.org  Tue Nov 25 07:13:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14763
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 07:13: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 1AOc3y-00057S-WC
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 07:13:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPCD2f1019674
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 07:13:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOc3y-00057F-Sj
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 07:13:02 -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 HAA14756
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 07:12:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOc3y-0003E0-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 07:13:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOc3x-0003Dx-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 07:13:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOc3u-00056Y-Dh; Tue, 25 Nov 2003 07:12:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOc3J-00056A-4W
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 07:12: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 HAA14742
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 07:12:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOc3I-0003DA-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 07:12:20 -0500
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOc3I-0003CE-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 07:12:20 -0500
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id EFCD587BF4; Tue, 25 Nov 2003 07:11:49 -0500 (EST)
To: ieprep@ietf.org
Message-Id: <20031125121149.EFCD587BF4@newdev.harvard.edu>
Date: Tue, 25 Nov 2003 07:11:49 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
Subject: [Ieprep] fyi - Internet Priority Service RFI from US government
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>


http://www.fbodaily.com/archive/2003/11-November/23-Nov-2003/FBO-00474736.htm

Scott

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



From exim@www1.ietf.org  Tue Nov 25 09:36:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19112
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 09:36: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 1AOeIQ-0004Ig-8V
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 09:36:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEa6ri016529
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 09:36:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOeIQ-0004IW-4Q
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:36:06 -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 JAA19081
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 09:35:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOeIO-0005us-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 09:36:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOeIN-0005up-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 09:36:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOeIN-0004HT-4G; Tue, 25 Nov 2003 09:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOeID-0004Ge-0c
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 09:35:53 -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 JAA19064
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 09:35:38 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOeIB-0005uT-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 09:35:51 -0500
Received: from imo-d05.mx.aol.com ([205.188.157.37])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOeIA-0005tk-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 09:35:50 -0500
Received: from Mpierce1@aol.com
	by imo-d05.mx.aol.com (mail_out_v36_r1.1.) id u.33.41391318 (4468);
	Tue, 25 Nov 2003 09:34:46 -0500 (EST)
Message-ID: <33.41391318.2cf4c286@aol.com>
Date: Tue, 25 Nov 2003 09:34:46 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: jgunn@ix.netcom.com, steves@shentel.net, jmpolk@cisco.com, ieprep@ietf.org
CC: fred@cisco.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_33.41391318.2cf4c286_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_33.41391318.2cf4c286_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/24/2003 4:57:59 PM Eastern Standard Time, 
jgunn@ix.netcom.com writes:


> The "factor of 3" or   "1/3" applies to the mean or average traffic rate.  
> In order to figure anything out about how often that is going to lead to over 
> 100% utilization on a given link, we need to know something about the 
> DISTRIBUTION, over various time intervals.   We also need this information to 
> figure out how effective the various strategies would be. Does this information 
> exist?
> 
> The effect is going to be very different depending on the "size of the 
> pipes".  A link that is equvalent to, say, 5 "full time" connections is going to 
> have much more variability in the total, and is threfore going to go over 
> capacity more often, thatn a link that is equivalent to 100s of "full time" 
> connections.  So stratgies that would be effective on "big pipes" might be 
> inadequate on "little pipes".
> 



Yes, this is all the stuff that would need to go into determining a limit of 
the number of simultaneous phone calls that can be allowed through a pipe of a 
specific size, in order to meet some performance criteria, The point I was 
trying to make is that this is exactly what has been done (using silence 
suppression to cram more calls into a limited space) for trans-ocean cables for a 
long time. And someone had to do the above calculations, so they should be well 
known.

ITU-T Recommendation E.528, Dimensioning of Digital Circuit Multiplication 
Equiment systems, probably covers this. I'm looking for a copy.

The use of this technique for existing systems provides the "proof of 
concept".

If the factor is 1/3 for a large pipe, it might be only 1/2 for a smaller one 
because of probability. No matter what value is used, there will be a few 
periods in which packets must be discarded. That's where MLEF can be applied.


Mike Pierce


--part1_33.41391318.2cf4c286_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/24/=
2003 4:57:59 PM Eastern Standard Time, jgunn@ix.netcom.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">The "factor of 3" or &nbsp;=
&nbsp;"1/3" applies to the mean or average traffic rate. &nbsp;In order to f=
igure anything out about how often that is going to lead to over 100% utiliz=
ation on a given link, we need to know something about the DISTRIBUTION, ove=
r various time intervals. &nbsp;&nbsp;We also need this information to figur=
e out how effective the various strategies would be. Does this information e=
xist?
<BR>
<BR>The effect is going to be very different depending on the "size of the p=
ipes". &nbsp;A link that is equvalent to, say, 5 "full time" connections is=20=
going to have much more variability in the total, and is threfore going to g=
o over capacity more often, thatn a link that is equivalent to 100s of "full=
 time" connections. &nbsp;So stratgies that would be effective on "big pipes=
" might be inadequate on "little pipes".
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>
<BR>
<BR>Yes, this is all the stuff that would need to go into determining a limi=
t of the number of simultaneous phone calls that can be allowed through a pi=
pe of a specific size, in order to meet some performance criteria, The point=
 I was trying to make is that this is exactly what has been done (using sile=
nce suppression to cram more calls into a limited space) for trans-ocean cab=
les for a long time. And someone had to do the above calculations, so they s=
hould be well known.
<BR>
<BR>ITU-T Recommendation E.528, Dimensioning of Digital Circuit Multiplicati=
on Equiment systems, probably covers this. I'm looking for a copy.
<BR>
<BR>The use of this technique for existing systems provides the "proof of co=
ncept".
<BR>
<BR>If the factor is 1/3 for a large pipe, it might be only 1/2 for a smalle=
r one because of probability. No matter what value is used, there will be a=20=
few periods in which packets must be discarded. That's where MLEF can be app=
lied.
<BR>
<BR>
<BR>Mike Pierce
<BR></FONT></HTML>

--part1_33.41391318.2cf4c286_boundary--

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



From exim@www1.ietf.org  Tue Nov 25 11:07:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24839
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 11:07: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 1AOfiR-0003y7-Lp
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 11:07:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPG73j6015250
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 11:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOfiR-0003xs-99
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 11:07:03 -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 LAA24827
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 11:06:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOfiO-00002g-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 11:07:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOfiO-00002d-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 11:07:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOfiO-0003wL-Uq; Tue, 25 Nov 2003 11: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 1AOfhf-0003v3-2u
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 11:06:15 -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 LAA24811
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 11:05:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOfhc-00001Z-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 11:06:12 -0500
Received: from mailgw2a.lmco.com ([192.91.147.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOfhc-00001W-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 11:06:12 -0500
Received: from emss02g01.ems.lmco.com (emss02g01.ems.lmco.com [166.29.2.54])
	by mailgw2a.lmco.com (8.11.6p2/8.11.6) with ESMTP id hAPG5DS09030;
	Tue, 25 Nov 2003 11:05:14 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HOX006010KX4G@lmco.com>; Tue,
 25 Nov 2003 09:02:57 -0700 (MST)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760)
 with ESMTP id <0HOX004FK0KVJL@lmco.com>; Tue, 25 Nov 2003 09:02:57 -0700 (MST)
Date: Tue, 25 Nov 2003 11:02:55 -0500
From: "Eagan, Christopher" <christopher.eagan@lmco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: Fred Baker <fred@cisco.com>, Mpierce1@aol.com
Cc: steves@shentel.net, saq66@umkc.edu, ieprep@ietf.org
Message-id: <3F2F205501D3D411878C0008C7E6459410CFECBE@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: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Thread-Index: AcOxRcbT7ntcKpaoQMuF1gKgj/+4vwCJXw1A
content-class: urn:content-classes:message
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>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

I understand the potential problems cited in regards to an mlef-only solution, but mlef and cac are not necessarily mutually exclusive.  I think mlef has its place in assuring priority communications in places where cac may not work, or may work too slowly.

Examples of where mlef is useful:  When an intervening network node that is routing many calls fails, all the calls must be rerouted - having mlef assures the packets from the priority calls get the best possible treatment while cac mechanisms have time to recover.  Another example is in mobile ad hoc environments, where there are concerns about how fast rsvp can re-reserve resources.

Are there problems with this?  I don't see mlef breaking any existing QoS mechanisms.

Chris

> -----Original Message-----
> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of
> Fred Baker
> Sent: Thursday, November 20, 2003 11:27 AM
> To: Mpierce1@aol.com
> Cc: steves@shentel.net; saq66@umkc.edu; ieprep@ietf.org
> Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> 
> At 06:29 AM 11/20/2003, Mpierce1@aol.com wrote:
> >Yes, I believe this has been suggested. The obvious problem 
> is trying to 
> >define an algorithm that would allow a terminal to 
> distinguish between 
> >packet loss from congestion that isn't going to go away, and 
> packet loss 
> >that is going to go away rather quickly anyway (as in my 
> example), and 
> >packet loss due to something other than congestion. I tend 
> to think that 
> >this is not possible.
> 
> actually, the obvious problem is that if we are dropping 
> traffic from a 
> precedence class, we are dropping roughly equal amounts from 
> all calls 
> within that class. If it is bad enough that some calls would 
> give up, one 
> must presume that all relevant sessions will at minimum ask 
> the question. 
> Why does one believe that they will not all, or some 
> significant subset, 
> drop? if this is done at a time when a number of sessions are being 
> established, this becomes a rolling pattern - if we have 
> enough calls for 
> 110% of the bandwidth, and are therefore dropping 10% of 
> traffic in the 
> precedence class, one would expect calls to drop and 
> re-establish randomly 
> in a rolling pattern.
> 
> The policy and predictability of the system is pretty 
> suspect, I think. 
> 
> 
> _______________________________________________
> 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



From exim@www1.ietf.org  Tue Nov 25 15:05:28 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05725
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 15:05:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOjQu-0004Dj-6G
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 15:05:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPK5CTo016223
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 15:05:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOjQt-0004Da-Ut
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:05:11 -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 PAA05669
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 15:04:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOjQq-0004Re-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 15:05:08 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOjQq-0004RZ-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 15:05:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOjQi-0004Cb-G7; Tue, 25 Nov 2003 15:05:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOjPl-0004BP-Ek
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 15:04: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 PAA05501
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 15:03:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOjPi-0004PR-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 15:03:58 -0500
Received: from phobos.simply.net ([81.3.64.11])
	by ietf-mx with smtp (Exim 4.12)
	id 1AOjPh-0004OT-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 15:03:57 -0500
Received: (qmail 28551 invoked from network); 25 Nov 2003 20:03:18 -0000
Received: from pool-151-196-9-129.balt.east.verizon.net (HELO albers) (151.196.9.129)
  by phobos.simply.net with SMTP; 25 Nov 2003 20:03:18 -0000
From: "Ken Carlberg" <carlberg@g11.org.uk>
To: "'Eagan, Christopher'" <christopher.eagan@lmco.com>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 15:02:56 -0500
Message-ID: <000b01c3b38f$1ec33270$7301a8c0@albers>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3F2F205501D3D411878C0008C7E6459410CFECBE@emss09m06.ems.lmco.com>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Examples of where mlef is useful:  When an intervening network node
that
> is routing many calls fails, all the calls must be rerouted - having
mlef
> assures the packets from the priority calls get the best possible
> treatment while cac mechanisms have time to recover. 

This example is probably not as precise as it should be.  What type of
"network node" were your thinking about?  If the "network node" is a
router between two signaling or media gateways, then existing IP routing
will do the re-routing of IP flows -- transparently from the end-point
gateways.  

Also, what is the form of the call you are referring to?  Is this the
signaling traffic or the voice/data traffic?  I can see some value in an
MLEF-like capability for the latter, but not really the former. This is
because we generally don't associate the same delay & loss expectation
of VoIP signaling versus data.

> Another example is
> in mobile ad hoc environments, where there are concerns about how fast
> rsvp can re-reserve resources.

If you are referring to MANET, versus layer-2, then I would just point
out that IP level ad-hoc routing environments are still quite
experimental. Adding other capabilities like rsvp are in my view a fun
problem to consider, but also not ready for prime time.  A recent paper
in LNCS (URL below) gives some interesting results and expresses
concerns about protocols like TORA, DSV, and AODV. 

-ken

http://www.springerlink.com/app/home/contribution.asp?wasp=9ampwgwqlkrd3
67rvvtk&referrer=parent&backto=issue,56,79;journal,97,1358;linkingpublic
ationresults,id:105633,1


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



From exim@www1.ietf.org  Tue Nov 25 16:19:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11164
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 16:19: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 1AOkaP-0001Y2-9V
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 16:19:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPLJ5fG005946
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 16:19:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOkaP-0001Xp-3h
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 16:19:05 -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 QAA11136
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 16:18:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOkaN-0006cW-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 16:19:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOkaM-0006cT-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 16:19:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOkaL-0001WF-8i; Tue, 25 Nov 2003 16:19:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOkZc-0001Lb-4h
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 16:18:16 -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 QAA11114
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 16:18:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOkZa-0006bq-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 16:18:14 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOkZZ-0006bI-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 16:18:13 -0500
Received: from Steve (ha96s142.d.shentel.net [204.111.96.142])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAPLGx418351;
	Tue, 25 Nov 2003 16:16:59 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "Ken Carlberg" <carlberg@g11.org.uk>,
        "'Eagan, Christopher'" <christopher.eagan@lmco.com>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 16:17:15 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBIENGDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000b01c3b38f$1ec33270$7301a8c0@albers>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

A case where MLEF would be useful:

Consider a ship with several hundred people, serious data transmission
requirements,
(I won't go into detail on this.)
and a relatively limited (256 kb/s or maybe even less) satellite link.

As you might imagine, whatever voice services are available are
sometimes heavily subscribed.
My guess is that 8 kb/s encoding and silence suppression would be very
useful given the bandwidth limitation.

Occasionally, there is an important (high priority) call that must get
through (or even several). Even if the existing
voice calls suffer or some of them are terminated.

I think the case above is realistic.  Is there an existing CAC can
handle this case and maximize the use of the b/w?
I would assume a router on each end of the link.

Steve

> -----Original Message-----
> From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org]On Behalf Of
> Ken Carlberg
> Sent: Tuesday, November 25, 2003 3:03 PM
> To: 'Eagan, Christopher'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>



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



From exim@www1.ietf.org  Tue Nov 25 17:17:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14044
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 17:17: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 1AOlUX-0005iu-KY
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:17:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMH5pw021994
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:17:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOlUX-0005if-E7
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:17:05 -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 RAA13999
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 17:16:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOlUV-0000Rt-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17:17:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOlUU-0000Rq-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17:17:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOlUT-0005h9-B4; Tue, 25 Nov 2003 17: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 1AOlU9-0005dH-OC
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 17:16: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 RAA13982
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 17:16:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOlU7-0000Or-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:16:39 -0500
Received: from phobos.simply.net ([81.3.64.11])
	by ietf-mx with smtp (Exim 4.12)
	id 1AOlU6-0000O6-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:16:38 -0500
Received: (qmail 22677 invoked from network); 25 Nov 2003 22:16:07 -0000
Received: from pool-151-196-9-129.balt.east.verizon.net (HELO albers) (151.196.9.129)
  by phobos.simply.net with SMTP; 25 Nov 2003 22:16:07 -0000
From: "Ken Carlberg" <carlberg@g11.org.uk>
To: "'Steve Silverman'" <steves@shentel.net>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 17:15:33 -0500
Message-ID: <000d01c3b3a1$a59e56f0$7301a8c0@albers>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <CIEELMKPOOAMCIAKANLBIENGDEAA.steves@shentel.net>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Again, I am simply asking for more precision in what is said.  If people
are going to use the term "call", please indicate if you are referring
to the signaling/control packets  OR  the voice/data packets.

One does not retransmit interactive voice packets.  And typically,
concerns arise sharply when end-to-end voice exceeds 600ms delay.  On
the other hand, I have yet to hear concerns about similar delay for
signaling packets, and we can retransmit them if they are considered
lost.  Hence, there are different expectations for the two different
types of flows.

I hope we can end this thread on that note and not go down a rat hole.

-ken


> -----Original Message-----
> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf
Of
> Steve Silverman
> Sent: Tuesday, November 25, 2003 4:17 PM
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> A case where MLEF would be useful:
> 
> Consider a ship with several hundred people, serious data transmission
> requirements,
> (I won't go into detail on this.)
> and a relatively limited (256 kb/s or maybe even less) satellite link.
> 
> As you might imagine, whatever voice services are available are
> sometimes heavily subscribed.
> My guess is that 8 kb/s encoding and silence suppression would be very
> useful given the bandwidth limitation.
> 
> Occasionally, there is an important (high priority) call that must get
> through (or even several). Even if the existing
> voice calls suffer or some of them are terminated.
> 
> I think the case above is realistic.  Is there an existing CAC can
> handle this case and maximize the use of the b/w?
> I would assume a router on each end of the link.
> 
> Steve
> 
> > -----Original Message-----
> > From: ieprep-admin@ietf.org
> > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > Ken Carlberg
> > Sent: Tuesday, November 25, 2003 3:03 PM
> > To: 'Eagan, Christopher'
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> >
> >
> 
> 
> 
> _______________________________________________
> 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



From exim@www1.ietf.org  Tue Nov 25 17:27:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14388
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 17:27: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 1AOleC-0006DK-NB
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:27:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMR4AG023884
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:27:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOleC-0006D9-IF
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:27: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 RAA14378
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 17:26:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOleA-0000d3-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17:27:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOle9-0000d0-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17: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 1AOleA-0006CH-3b; Tue, 25 Nov 2003 17:27:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOldO-00069v-0e
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 17:26:14 -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 RAA14362
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 17:25:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOldL-0000ce-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:26:11 -0500
Received: from mailgw3a.lmco.com ([192.35.35.7])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOldL-0000cX-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:26:11 -0500
Received: from emss02g01.ems.lmco.com ([166.29.2.54])
	by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id hAPMQ8t20617;
	Tue, 25 Nov 2003 17:26:08 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HOX00L01IAAHS@lmco.com>; Tue,
 25 Nov 2003 15:25:23 -0700 (MST)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760)
 with ESMTP id <0HOX009JVI9UTU@lmco.com>; Tue, 25 Nov 2003 15:25:20 -0700 (MST)
Date: Tue, 25 Nov 2003 17:25:09 -0500
From: "Eagan, Christopher" <christopher.eagan@lmco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: Ken Carlberg <carlberg@g11.org.uk>
Cc: ieprep@ietf.org
Message-id: <3F2F205501D3D411878C0008C7E6459410CFECC0@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: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Thread-Index: AcOzohCx2L8ugohMRfifkWssRGVtWQAAFlqw
content-class: urn:content-classes:message
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>
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Sorry Ken,

I believe Steve and I were both referring to voice bearing packets, not signaling and control control packets (at least that is what I was talking about).  I think preferential treatment for signaling and control can be handled with the existing AF PHB's - since it is not likely to be as detrimental to a call if signaling is delayed a bit.

When I was said 'network nodes' earlier, I was referring to routers between two voice endpoints.

I'll try to be more precise next time.

Chris

> -----Original Message-----
> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of
> Ken Carlberg
> Sent: Tuesday, November 25, 2003 5:16 PM
> To: 'Steve Silverman'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> 
> Again, I am simply asking for more precision in what is said. 
>  If people
> are going to use the term "call", please indicate if you are referring
> to the signaling/control packets  OR  the voice/data packets.
> 
> One does not retransmit interactive voice packets.  And typically,
> concerns arise sharply when end-to-end voice exceeds 600ms delay.  On
> the other hand, I have yet to hear concerns about similar delay for
> signaling packets, and we can retransmit them if they are considered
> lost.  Hence, there are different expectations for the two different
> types of flows.
> 
> I hope we can end this thread on that note and not go down a rat hole.
> 
> -ken
> 
> 
> > -----Original Message-----
> > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf
> Of
> > Steve Silverman
> > Sent: Tuesday, November 25, 2003 4:17 PM
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> > 
> > A case where MLEF would be useful:
> > 
> > Consider a ship with several hundred people, serious data 
> transmission
> > requirements,
> > (I won't go into detail on this.)
> > and a relatively limited (256 kb/s or maybe even less) 
> satellite link.
> > 
> > As you might imagine, whatever voice services are available are
> > sometimes heavily subscribed.
> > My guess is that 8 kb/s encoding and silence suppression 
> would be very
> > useful given the bandwidth limitation.
> > 
> > Occasionally, there is an important (high priority) call 
> that must get
> > through (or even several). Even if the existing
> > voice calls suffer or some of them are terminated.
> > 
> > I think the case above is realistic.  Is there an existing CAC can
> > handle this case and maximize the use of the b/w?
> > I would assume a router on each end of the link.
> > 
> > Steve
> > 
> > > -----Original Message-----
> > > From: ieprep-admin@ietf.org
> > > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > > Ken Carlberg
> > > Sent: Tuesday, November 25, 2003 3:03 PM
> > > To: 'Eagan, Christopher'
> > > Cc: ieprep@ietf.org
> > > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low 
> priority calls
> > >
> > >
> > 
> > 
> > 
> > _______________________________________________
> > 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



From exim@www1.ietf.org  Tue Nov 25 17:35:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14736
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 17:35: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 1AOllx-0006w8-DU
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:35:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMZ54B026658
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 17:35:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOllx-0006vt-7Z
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 17:35:05 -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 RAA14712
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 17:34:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOllu-0000pk-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17:35:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOllu-0000ph-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 17:35:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOllv-0006t6-Df; Tue, 25 Nov 2003 17:35:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOllV-0006sU-Lb
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 17:34:37 -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 RAA14709
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 17:34:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOllT-0000pC-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:34:35 -0500
Received: from harrier.mail.pas.earthlink.net ([207.217.120.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOllS-0000p6-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 17:34:34 -0500
Received: from louie.psp.pas.earthlink.net ([207.217.78.221])
	by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1AOllM-0006sQ-00; Tue, 25 Nov 2003 14:34:28 -0800
Message-ID: <10551127.1069799668710.JavaMail.root@louie.psp.pas.earthlink.net>
Date: Tue, 25 Nov 2003 14:33:51 -0800 (PST)
From: Janet Gunn <jgunn@ix.netcom.com>
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
To: Ken Carlberg <carlberg@g11.org.uk>,
        "'Steve Silverman'" <steves@shentel.net>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

As I understand it, CAC operates at the "call" level, and thus at the signalling level, when the "call" is being set up.  The CAC mechanism MIGHT have some knowledge about the packet level activity of the voice/data packets, for instance by knowing  the codec to be used.

Any kind of per hop behavior operates at the packet level, without any explicit knowledge ABOUT the packet, except the label that indicates the PHB.  It doesn't know anything about the associated "call"

In principle, changing the PHB will change the QoS behavior, but it won't/can't, by itself "terminate" a call.  Only a call level (typically signalling based) mechanism can terminate a call.

If there is some kind of  a feedback loop between the "packet level" and the "call level", it is possible that the call level mechanism will detect that the QoS had become unacceptable.  In that case the the call level mechanism might terminate the call.

You seem to be implying that a MLEF PHB can "terminate" a lower priority call.  I don't understand how it can do that.  Please explain.

-----Original Message-----
From: Ken Carlberg <carlberg@g11.org.uk>
Sent: Nov 25, 2003 2:15 PM
To: 'Steve Silverman' <steves@shentel.net>
Cc: ieprep@ietf.org
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

Again, I am simply asking for more precision in what is said.  If people
are going to use the term "call", please indicate if you are referring
to the signaling/control packets  OR  the voice/data packets.

One does not retransmit interactive voice packets.  And typically,
concerns arise sharply when end-to-end voice exceeds 600ms delay.  On
the other hand, I have yet to hear concerns about similar delay for
signaling packets, and we can retransmit them if they are considered
lost.  Hence, there are different expectations for the two different
types of flows.

I hope we can end this thread on that note and not go down a rat hole.

-ken


> -----Original Message-----
> From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf
Of
> Steve Silverman
> Sent: Tuesday, November 25, 2003 4:17 PM
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> A case where MLEF would be useful:
> 
> Consider a ship with several hundred people, serious data transmission
> requirements,
> (I won't go into detail on this.)
> and a relatively limited (256 kb/s or maybe even less) satellite link.
> 
> As you might imagine, whatever voice services are available are
> sometimes heavily subscribed.
> My guess is that 8 kb/s encoding and silence suppression would be very
> useful given the bandwidth limitation.
> 
> Occasionally, there is an important (high priority) call that must get
> through (or even several). Even if the existing
> voice calls suffer or some of them are terminated.
> 
> I think the case above is realistic.  Is there an existing CAC can
> handle this case and maximize the use of the b/w?
> I would assume a router on each end of the link.
> 
> Steve
> 
> > -----Original Message-----
> > From: ieprep-admin@ietf.org
> > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > Ken Carlberg
> > Sent: Tuesday, November 25, 2003 3:03 PM
> > To: 'Eagan, Christopher'
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> >
> >
> 
> 
> 
> _______________________________________________
> 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



From exim@www1.ietf.org  Tue Nov 25 19:32:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19378
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 19:32: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 1AOnbB-0004Zt-2v
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 19:32:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ0W5Zd017597
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 19:32:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnbA-0004Zk-SA
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 19:32: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 TAA19371
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 19:31:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnb8-0003TC-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 19:32:02 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnb8-0003T9-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 19:32:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnb7-0004Yu-Eo; Tue, 25 Nov 2003 19:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnaM-0004Xg-Vn
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 19:31:15 -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 TAA19349
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 19:31:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnaL-0003Q9-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 19:31:13 -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 1AOnaK-0003Pg-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 19:31:12 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 25 Nov 2003 16:32:07 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAQ0Uejq024355;
	Tue, 25 Nov 2003 16:30:41 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA12919; Tue, 25 Nov 2003 16:30:38 -0800 (PST)
Message-Id: <4.3.2.7.2.20031125180153.07c6dcc0@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Nov 2003 18:30:41 -0600
To: Janet Gunn <jgunn@ix.netcom.com>, Ken Carlberg <carlberg@g11.org.uk>,
        "'Steve Silverman'" <steves@shentel.net>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: ieprep@ietf.org
In-Reply-To: <10551127.1069799668710.JavaMail.root@louie.psp.pas.earthli
 nk.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 02:33 PM 11/25/2003 -0800, Janet Gunn wrote:
>As I understand it, CAC operates at the "call" level, and thus at the 
>signalling level, when the "call" is being set up.

CAC operates at this level, but maybe other levels too

>The CAC mechanism MIGHT have some knowledge about the packet level 
>activity of the voice/data packets,

Depending on the CAC, it might have awareness of packet flows

>for instance by knowing  the codec to be used.

To be precise - it might know the amount of bandwidth required by that flow.

One particular CAC MUST know the bandwidth to set up a reservation - but it 
doesn't care at all what the actual codec is (splitting hairs now, I know)


>Any kind of per hop behavior operates at the packet level, without any 
>explicit knowledge ABOUT the packet, except the label that indicates the 
>PHB.  It doesn't know anything about the associated "call"

correct


>In principle, changing the PHB will change the QoS behavior, but it 
>won't/can't, by itself "terminate" a call.

correct

>Only a call level (typically signalling based) mechanism can terminate a call.

typically


>If there is some kind of  a feedback loop between the "packet level" and 
>the "call level", it is possible that the call level mechanism will detect 
>that the QoS had become unacceptable.  In that case the the call level 
>mechanism might terminate the call.
>
>You seem to be implying that a MLEF PHB can "terminate" a lower priority 
>call.  I don't understand how it can do that.

neither do I....

To summarize what I am hearing about MLEF, this proposed PHB will delay the 
time between packets within the same flow (which codecs don't typically 
like) unless there is some mechanism of dropping the delayed packets (which 
codecs don't like either). Creating a PHB with a drop precedence similar to 
AF and apply it to a delay sensitive application (like voice) will create 
this dropping capability (which codecs don't like) and allow packets that 
are not delayed to arrive on time but with lost information the codec 
requires to replicate the audible speech patterns of the speaker. MLPP 
users are trained to understand what to do when they hear a preemption tone 
or announcement - but if they don't hear this tone (or announcement), might 
their behavior be to stay on the call longer than is necessary? Will they 
quickly call again (making the problem sustain itself).

Further adding to this problem space is the behavior of codecs and their 
own packet loss compensation. Most codecs that have this ability - when 
they understand that there is packet loss, will actually increase the 
amount of bandwidth transmitted (because duplicate voice samples are added 
other RTP packets just in case the packet before or after is lost) - making 
the problem worse (nearly exponentially worse) because now each call flow 
requires more bandwidth...

So, without the providing the feedback necessary to terminate a call flow 
or series of call flows (and inform the user what has occurred) within the 
same priority level within a domain, how is MLEF a benefit?

>Please explain.
>
>-----Original Message-----
>From: Ken Carlberg <carlberg@g11.org.uk>
>Sent: Nov 25, 2003 2:15 PM
>To: 'Steve Silverman' <steves@shentel.net>
>Cc: ieprep@ietf.org
>Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>Again, I am simply asking for more precision in what is said.  If people
>are going to use the term "call", please indicate if you are referring
>to the signaling/control packets  OR  the voice/data packets.
>
>One does not retransmit interactive voice packets.  And typically,
>concerns arise sharply when end-to-end voice exceeds 600ms delay.  On
>the other hand, I have yet to hear concerns about similar delay for
>signaling packets, and we can retransmit them if they are considered
>lost.  Hence, there are different expectations for the two different
>types of flows.
>
>I hope we can end this thread on that note and not go down a rat hole.
>
>-ken
>
>
> > -----Original Message-----
> > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org] On Behalf
>Of
> > Steve Silverman
> > Sent: Tuesday, November 25, 2003 4:17 PM
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> >
> > A case where MLEF would be useful:
> >
> > Consider a ship with several hundred people, serious data transmission
> > requirements,
> > (I won't go into detail on this.)
> > and a relatively limited (256 kb/s or maybe even less) satellite link.
> >
> > As you might imagine, whatever voice services are available are
> > sometimes heavily subscribed.
> > My guess is that 8 kb/s encoding and silence suppression would be very
> > useful given the bandwidth limitation.
> >
> > Occasionally, there is an important (high priority) call that must get
> > through (or even several). Even if the existing
> > voice calls suffer or some of them are terminated.
> >
> > I think the case above is realistic.  Is there an existing CAC can
> > handle this case and maximize the use of the b/w?
> > I would assume a router on each end of the link.
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: ieprep-admin@ietf.org
> > > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > > Ken Carlberg
> > > Sent: Tuesday, November 25, 2003 3:03 PM
> > > To: 'Eagan, Christopher'
> > > Cc: ieprep@ietf.org
> > > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Tue Nov 25 19:47:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19773
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 19:47: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 1AOnpe-0005hx-ID
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 19:47:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ0l2gt021935
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 19:47:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnpe-0005hi-CR
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 19:47:02 -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 TAA19751
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 19:46:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnpc-0003nf-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 19:47:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnpc-0003nc-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 19:47:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnpc-0005h2-1K; Tue, 25 Nov 2003 19:47:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOnpU-0005gn-7r
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 19:46:52 -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 TAA19747
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 19:46:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnpS-0003nT-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 19:46:50 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOnpS-0003kg-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 19:46:50 -0500
Received: from Steve (ha96s091.d.shentel.net [204.111.96.91])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAQ0kG416789;
	Tue, 25 Nov 2003 19:46:16 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "Ken Carlberg" <carlberg@g11.org.uk>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 19:46:32 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBAENKDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000d01c3b3a1$a59e56f0$7301a8c0@albers>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Ken,

Sorry for any confusion.
I was using the term call in the requirements sense of both the
signaling packets and the voice packets.
>From a user's point of view, both are necessary for a phone call.


MLEF only acts on the voice/data packets.  It is a way to get critical
data packets thru a congested link.

Steve

> -----Original Message-----
> From: Ken Carlberg [mailto:carlberg@g11.org.uk]
> Sent: Tuesday, November 25, 2003 5:16 PM
> To: 'Steve Silverman'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
> Again, I am simply asking for more precision in what is
> said.  If people
> are going to use the term "call", please indicate if you
> are referring
> to the signaling/control packets  OR  the voice/data packets.
>
> One does not retransmit interactive voice packets.  And typically,
> concerns arise sharply when end-to-end voice exceeds 600ms
> delay.  On
> the other hand, I have yet to hear concerns about similar delay for
> signaling packets, and we can retransmit them if they are considered
> lost.  Hence, there are different expectations for the two different
> types of flows.
>
> I hope we can end this thread on that note and not go down
> a rat hole.
>
> -ken
>
>
> > -----Original Message-----
> > From: ieprep-admin@ietf.org
[mailto:ieprep-admin@ietf.org] On Behalf
Of
> Steve Silverman
> Sent: Tuesday, November 25, 2003 4:17 PM
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
> A case where MLEF would be useful:
>
> Consider a ship with several hundred people, serious data
transmission
> requirements,
> (I won't go into detail on this.)
> and a relatively limited (256 kb/s or maybe even less) satellite
link.
>
> As you might imagine, whatever voice services are available are
> sometimes heavily subscribed.
> My guess is that 8 kb/s encoding and silence suppression would be
very
> useful given the bandwidth limitation.
>
> Occasionally, there is an important (high priority) call that must
get
> through (or even several). Even if the existing
> voice calls suffer or some of them are terminated.
>
> I think the case above is realistic.  Is there an existing CAC can
> handle this case and maximize the use of the b/w?
> I would assume a router on each end of the link.
>
> Steve
>
> > -----Original Message-----
> > From: ieprep-admin@ietf.org
> > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > Ken Carlberg
> > Sent: Tuesday, November 25, 2003 3:03 PM
> > To: 'Eagan, Christopher'
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority
calls
> >
> >
>
>
>
> _______________________________________________
> 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



From exim@www1.ietf.org  Tue Nov 25 20:08:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20390
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 20:08:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOoA1-0006z0-NA
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 20:08:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ18558026780
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 20:08:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOoA0-0006xI-0y
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 20:08: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 UAA20386
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 20:07:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOo9x-0004CA-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 20:08:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOo9x-0004C6-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 20:08:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOo9x-0006w3-Ez; Tue, 25 Nov 2003 20:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOo9j-0006re-KN
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 20:07: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 UAA20378
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 20:07:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOo9h-0004Bw-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 20:07:45 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOo9h-0004Bn-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 20:07:45 -0500
Received: from Steve (ha96s091.d.shentel.net [204.111.96.91])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAQ179419997;
	Tue, 25 Nov 2003 20:07:09 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "Janet Gunn" <jgunn@ix.netcom.com>, "Ken Carlberg" <carlberg@g11.org.uk>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 20:07:27 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBAENLDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <10551127.1069799668710.JavaMail.root@louie.psp.pas.earthlink.net>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Comments below.

> -----Original Message-----
> From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org]On Behalf Of
> Janet Gunn
> Sent: Tuesday, November 25, 2003 5:34 PM
> To: Ken Carlberg; 'Steve Silverman'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
> As I understand it, CAC operates at the "call" level, and
> thus at the signalling level, when the "call" is being set
> up.  The CAC mechanism MIGHT have some knowledge about the
> packet level activity of the voice/data packets, for
> instance by knowing  the codec to be used.

The CAC operates at the call level. If silence suppression is in use,
the CAC
does not know if one side is transmitting or not.  It can only make
approximations to
actual usage.

>
> Any kind of per hop behavior operates at the packet level,
> without any explicit knowledge ABOUT the packet, except the
> label that indicates the PHB.  It doesn't know anything
> about the associated "call"
>

Yes.

> In principle, changing the PHB will change the QoS
> behavior, but it won't/can't, by itself "terminate" a call.
>  Only a call level (typically signalling based) mechanism
> can terminate a call.

I agaree with everything above.

>
> If there is some kind of  a feedback loop between the
> "packet level" and the "call level", it is possible that
> the call level mechanism will detect that the QoS had
> become unacceptable.  In that case the the call level
> mechanism might terminate the call.

>
> You seem to be implying that a MLEF PHB can "terminate" a
> lower priority call.  I don't understand how it can do
> that.  Please explain.

I have suggested the possibility that if a terminal had enough packets
dropped,
it might then delay or terminate the call, in order to lessen the load
on the network.
This would be terminal initiated signaling based on congestion.

Steve

>
> -----Original Message-----
> From: Ken Carlberg <carlberg@g11.org.uk>
> Sent: Nov 25, 2003 2:15 PM
> To: 'Steve Silverman' <steves@shentel.net>
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
> Again, I am simply asking for more precision in what is
> said.  If people
> are going to use the term "call", please indicate if you
> are referring
> to the signaling/control packets  OR  the voice/data packets.
>
> One does not retransmit interactive voice packets.  And typically,
> concerns arise sharply when end-to-end voice exceeds 600ms
> delay.  On
> the other hand, I have yet to hear concerns about similar delay for
> signaling packets, and we can retransmit them if they are considered
> lost.  Hence, there are different expectations for the two different
> types of flows.
>
> I hope we can end this thread on that note and not go down
> a rat hole.
>
> -ken
>
>
> > -----Original Message-----
> > From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org] On Behalf
> Of
> > Steve Silverman
> > Sent: Tuesday, November 25, 2003 4:17 PM
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low
> priority calls
> >
> > A case where MLEF would be useful:
> >
> > Consider a ship with several hundred people, serious data
> transmission
> > requirements,
> > (I won't go into detail on this.)
> > and a relatively limited (256 kb/s or maybe even less)
> satellite link.
> >
> > As you might imagine, whatever voice services are available are
> > sometimes heavily subscribed.
> > My guess is that 8 kb/s encoding and silence suppression
> would be very
> > useful given the bandwidth limitation.
> >
> > Occasionally, there is an important (high priority) call
> that must get
> > through (or even several). Even if the existing
> > voice calls suffer or some of them are terminated.
> >
> > I think the case above is realistic.  Is there an existing CAC can
> > handle this case and maximize the use of the b/w?
> > I would assume a router on each end of the link.
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: ieprep-admin@ietf.org
> > > [mailto:ieprep-admin@ietf.org]On Behalf Of
> > > Ken Carlberg
> > > Sent: Tuesday, November 25, 2003 3:03 PM
> > > To: 'Eagan, Christopher'
> > > Cc: ieprep@ietf.org
> > > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low
> priority calls
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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
>
>



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



From exim@www1.ietf.org  Tue Nov 25 20:27:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20813
	for <ieprep-archive@odin.ietf.org>; Tue, 25 Nov 2003 20:27: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 1AOoSN-0007lN-Bf
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 20:27:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ1R3e4029840
	for ieprep-archive@odin.ietf.org; Tue, 25 Nov 2003 20:27:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOoSN-0007lD-7O
	for ieprep-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 20:27:03 -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 UAA20807
	for <ieprep-web-archive@ietf.org>; Tue, 25 Nov 2003 20:26:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOoSK-0004OY-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 20:27:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOoSK-0004OV-00
	for ieprep-web-archive@ietf.org; Tue, 25 Nov 2003 20:27:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOoSL-0007kX-Gq; Tue, 25 Nov 2003 20:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AOoSK-0007kJ-LY
	for ieprep@optimus.ietf.org; Tue, 25 Nov 2003 20:27: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 UAA20804
	for <ieprep@ietf.org>; Tue, 25 Nov 2003 20:26:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOoSI-0004OS-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 20:26:58 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AOoSI-0004OM-00
	for ieprep@ietf.org; Tue, 25 Nov 2003 20:26:58 -0500
Received: from Steve (ha96s091.d.shentel.net [204.111.96.91])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAQ1Q5422804;
	Tue, 25 Nov 2003 20:26:05 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "James M. Polk" <jmpolk@cisco.com>, "Janet Gunn" <jgunn@ix.netcom.com>,
        "Ken Carlberg" <carlberg@g11.org.uk>
Cc: <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Tue, 25 Nov 2003 20:26:20 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBOENLDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <4.3.2.7.2.20031125180153.07c6dcc0@localhost>
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, November 25, 2003 7:31 PM
> To: Janet Gunn; Ken Carlberg; 'Steve Silverman'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
.........
>
> To summarize what I am hearing about MLEF, this proposed
> PHB will delay the
> time between packets within the same flow (which codecs
> don't typically
> like) unless there is some mechanism of dropping the
> delayed packets (which
> codecs don't like either).

No.  MLEF drops some lower priority packets when there is congestion.
It never delays packets.

>Creating a PHB with a drop
> precedence similar to
> AF and apply it to a delay sensitive application (like
> voice) will create
> this dropping capability (which codecs don't like) and
> allow packets that
> are not delayed to arrive on time but with lost information
> the codec
> requires to replicate the audible speech patterns of the
> speaker. MLPP
> users are trained to understand what to do when they hear a
> preemption tone
> or announcement - but if they don't hear this tone (or
> announcement), might
> their behavior be to stay on the call longer than is
> necessary? Will they
> quickly call again (making the problem sustain itself).
>
> Further adding to this problem space is the behavior of
> codecs and their
> own packet loss compensation. Most codecs that have this
> ability - when
> they understand that there is packet loss, will actually
> increase the
> amount of bandwidth transmitted (because duplicate voice
> samples are added
> other RTP packets just in case the packet before or after
> is lost) - making
> the problem worse (nearly exponentially worse) because now
> each call flow
> requires more bandwidth...
>
> So, without the providing the feedback necessary to
> terminate a call flow
> or series of call flows (and inform the user what has
> occurred) within the
> same priority level within a domain, how is MLEF a benefit?

When the voice traffic exceeds the link capacity, the high priority
calls
get thru intelligibly. This has been demonstrated.

>
> >Please explain.
> >
>
>
> cheers,
> James
>
>                                 *******************
>                  Truth is not to be argued... it is to be presented
>
>



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



From exim@www1.ietf.org  Wed Nov 26 11:06:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14521
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 11:06: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 1AP2B4-00057m-Js
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 11:06:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQG66Bb019697
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 11:06:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2B4-00057c-FC
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 11:06:06 -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 LAA14490
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 11:05:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2B1-0000LT-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 11:06:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2B1-0000LQ-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 11:06:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2Az-00055v-A9; Wed, 26 Nov 2003 11:06:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2AU-000552-74
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 11:05: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 LAA14430
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 11:05:14 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2AR-0000Kq-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 11:05:27 -0500
Received: from imo-m01.mx.aol.com ([64.12.136.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2AQ-0000KB-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 11:05:26 -0500
Received: from Mpierce1@aol.com
	by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id c.19c.1d5d0b0d (4529);
	Wed, 26 Nov 2003 11:04:28 -0500 (EST)
Message-ID: <19c.1d5d0b0d.2cf6290c@aol.com>
Date: Wed, 26 Nov 2003 11:04:28 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: jmpolk@cisco.com, jgunn@ix.netcom.com, carlberg@g11.org.uk,
        steves@shentel.net
CC: ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_19c.1d5d0b0d.2cf6290c_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_19c.1d5d0b0d.2cf6290c_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/25/2003 7:33:19 PM Eastern Standard Time, 
jmpolk@cisco.com writes:


> To summarize what I am hearing about MLEF, this proposed PHB will delay the 
> time between packets within the same flow (which codecs don't typically 
> like) unless there is some mechanism of dropping the delayed packets (which 
> codecs don't like either). Creating a PHB with a drop precedence similar to 
> AF and apply it to a delay sensitive application (like voice) will create 
> this dropping capability (which codecs don't like) and allow packets that 
> are not delayed to arrive on time but with lost information the codec 
> requires to replicate the audible speech patterns of the speaker. MLPP 
> users are trained to understand what to do when they hear a preemption tone 
> or announcement - but if they don't hear this tone (or announcement), might 
> their behavior be to stay on the call longer than is necessary? Will they 
> 



[MAP] We need to remember that EF today says that a router must discard 
packets that are in excess of the engineered limits (for the "EF" queue). This can 
be done by having a simple size limit on the queue or by using more 
complicated random early drop algorithms. The only thing that MLEF adds is to define a 
way to decide which packets to drop - nothing more. Way too much has been made 
about the efects of MLEF (on QoS, etc.). MLEF doesn't add bad QoS, it only 
says which calls feel the effect that is already there without MLEF.

I would claim that a reasonable example of what needs to be supported would 
be 10% of the calls are high priority with all of them beginning in a rather 
short time interval (right after the diaster). That means that, during the short 
period of congestion, the packet loss needs to be concentrated on 90% of the 
calls (lower ones) rather then spread across all 100% of them. As the lower 
priority calls drop, CAC prevents new low priority calls because it knows that 
the total number of calls is already at or above the limit, and the need to 
discard packets quickly goes away. This can be easily demonstrated.

> 
> Further adding to this problem space is the behavior of codecs and their 
> own packet loss compensation. Most codecs that have this ability - when 
> they understand that there is packet loss, will actually increase the 
> amount of bandwidth transmitted (because duplicate voice samples are added 
> other RTP packets just in case the packet before or after is lost) - making 
> the problem worse (nearly exponentially worse) because now each call flow 
> 



[MAP] I am not aware of any codec that adapts to packet loss by increasing 
its transmitted rate. I suppose there could be one. Can you give an example? 
They certainly couldn't be used in a possibly congested network, except maybe for 
the very high priority calls. This would be contrary to the operation of TCP 
which is required to drop back on packet rate when loss occurs. (Before anyone 
comments, I'm not saying that TCP is being used for voice packets. The 
solution for voice shouldn't take the opposite approach!)

> 
> So, without the providing the feedback necessary to terminate a call flow 
> or series of call flows (and inform the user what has occurred) within the 
> same priority level within a domain, how is MLEF a benefit?
> 
> 
> 
> 

[MAP] I believe there must be feedback from whatever knows about packet flow 
congestion to whatever limits new calls (CAC), even if we never talked about 
Assured Service. This must be possible for normal, non-priority traffic. In the 
case of Assured Service, preemption of existing calls can be added to this 
feedback. However, any such feedback can not take effect immediately, so 
something else needs to deal with the short term packet congestion. That is MLEF.

Note that, because of the probabilistic nature of packet flows and 
congestion, we would not want preemption of any existing call to be caused by a very 
short term packet loss or queue overflow. Temporary loss of packets (and audio) 
with means to stop the congestion is much better.


Mike


--part1_19c.1d5d0b0d.2cf6290c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/25/=
2003 7:33:19 PM Eastern Standard Time, jmpolk@cisco.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">To summarize what I am hear=
ing about MLEF, this proposed PHB will delay the=20
<BR>time between packets within the same flow (which codecs don't typically=20
<BR>like) unless there is some mechanism of dropping the delayed packets (wh=
ich=20
<BR>codecs don't like either). Creating a PHB with a drop precedence similar=
 to=20
<BR>AF and apply it to a delay sensitive application (like voice) will creat=
e=20
<BR>this dropping capability (which codecs don't like) and allow packets tha=
t=20
<BR>are not delayed to arrive on time but with lost information the codec=20
<BR>requires to replicate the audible speech patterns of the speaker. MLPP=20
<BR>users are trained to understand what to do when they hear a preemption t=
one=20
<BR>or announcement - but if they don't hear this tone (or announcement), mi=
ght=20
<BR>their behavior be to stay on the call longer than is necessary? Will the=
y=20
<BR>quickly call again (making the problem sustain itself).</BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] We need to remember that EF today says that a router must discard=20=
packets that are in excess of the engineered limits (for the "EF" queue). Th=
is can be done by having a simple size limit on the queue or by using more c=
omplicated random early drop algorithms. The only thing that MLEF adds is to=
 define a way to decide which packets to drop - nothing more. Way too much h=
as been made about the efects of MLEF (on QoS, etc.). MLEF doesn't add bad Q=
oS, it only says which calls feel the effect that is already there without M=
LEF.
<BR>
<BR>I would claim that a reasonable example of what needs to be supported wo=
uld be 10% of the calls are high priority with all of them beginning in a ra=
ther short time interval (right after the diaster). That means that, during=20=
the short period of congestion, the packet loss needs to be concentrated on=20=
90% of the calls (lower ones) rather then spread across all 100% of them. As=
 the lower priority calls drop, CAC prevents new low priority calls because=20=
it knows that the total number of calls is already at or above the limit, an=
d the need to discard packets quickly goes away. This can be easily demonstr=
ated.
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>Further adding to this problem space is the behavior of codecs and their=
=20
<BR>own packet loss compensation. Most codecs that have this ability - when=20
<BR>they understand that there is packet loss, will actually increase the=20
<BR>amount of bandwidth transmitted (because duplicate voice samples are add=
ed=20
<BR>other RTP packets just in case the packet before or after is lost) - mak=
ing=20
<BR>the problem worse (nearly exponentially worse) because now each call flo=
w=20
<BR>requires more bandwidth...</BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] I am not aware of any codec that adapts to packet loss by increasi=
ng its transmitted rate. I suppose there could be one. Can you give an examp=
le? They certainly couldn't be used in a possibly congested network, except=20=
maybe for the very high priority calls. This would be contrary to the operat=
ion of TCP which is required to drop back on packet rate when loss occurs. (=
Before anyone comments, I'm not saying that TCP is being used for voice pack=
ets. The solution for voice shouldn't take the opposite approach!)
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>So, without the providing the feedback necessary to terminate a call flo=
w=20
<BR>or series of call flows (and inform the user what has occurred) within t=
he=20
<BR>same priority level within a domain, how is MLEF a benefit?
<BR>
<BR>
<BR>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>[MAP] I believe there must be feedback from whatever knows about packet=20=
flow congestion to whatever limits new calls (CAC), even if we never talked=20=
about Assured Service. This must be possible for normal, non-priority traffi=
c. In the case of Assured Service, preemption of existing calls can be added=
 to this feedback. However, any such feedback can not take effect immediatel=
y, so something else needs to deal with the short term packet congestion. Th=
at is MLEF.
<BR>
<BR>Note that, because of the probabilistic nature of packet flows and conge=
stion, we would not want preemption of any existing call to be caused by a v=
ery short term packet loss or queue overflow. Temporary loss of packets (and=
 audio) with means to stop the congestion is much better.
<BR>
<BR>
<BR>Mike
<BR></FONT></HTML>

--part1_19c.1d5d0b0d.2cf6290c_boundary--

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



From exim@www1.ietf.org  Wed Nov 26 11:20:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15391
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 11:20: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 1AP2Od-0005z2-Lm
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 11:20:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQGK7TZ022994
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 11:20:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2Od-0005yn-3h
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 11:20: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 LAA15315
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 11:19:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2Ob-0000cr-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 11:20:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2Ob-0000co-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 11:20:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2OX-0005xt-Ix; Wed, 26 Nov 2003 11:20:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP2Nq-0005we-0o
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 11:19: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 LAA15224
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 11:19:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP2Nn-0000ae-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 11:19:15 -0500
Received: from bells.cs.ucl.ac.uk ([128.16.5.31])
	by ietf-mx with smtp (Exim 4.12)
	id 1AP2Nn-0000aa-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 11:19:15 -0500
Received: from 82-35-96-105.cable.ubr05.dals.blueyonder.co.uk 
          by bells.cs.ucl.ac.uk with UK SMTP id <g.17490-0@bells.cs.ucl.ac.uk>;
          Wed, 26 Nov 2003 16:18:59 +0000
From: Ian Brown <I.Brown@cs.ucl.ac.uk>
To: ieprep <ieprep@ietf.org>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Wed, 26 Nov 2003 16:18:46 -0000
Message-ID: <001701c3b438$f8c23030$6401a8c0@happy>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <19c.1d5d0b0d.2cf6290c@aol.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>I am not aware of any codec that adapts to packet loss by increasing 
>its transmitted rate. I suppose there could be one. Can you give an
>example?

There is a good overview of several Forward Error Correction schemes
that take such an approach in:

C. S. Perkins, O. Hodson, and V. Hardman, A Survey of Packet-Loss
Recovery Techniques for Streaming Audio, IEEE Network Magazine,
September/October 1998. 
http://csperkins.org/rat/publications/ErrorCorrection.ps



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



From exim@www1.ietf.org  Wed Nov 26 12:04:11 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17302
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 12:04:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP351-0000nr-Ci
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:03:55 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQH3tdX003082
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:03:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP351-0000nd-2y
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:03:55 -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 MAA17292
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 12:03:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP34z-0001L1-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:03:53 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP34z-0001Kf-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:03:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP34S-0000jZ-DF; Wed, 26 Nov 2003 12:03:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP33G-0000dg-66
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 12:02:06 -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 MAA17264
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 12:01:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP33E-0001Jx-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:02:04 -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 1AP33E-0001Ht-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:02:04 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 26 Nov 2003 09:02:58 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQH1NAt022741;
	Wed, 26 Nov 2003 09:01:23 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA24075; Wed, 26 Nov 2003 09:01:21 -0800 (PST)
Message-Id: <4.3.2.7.2.20031126105121.02955f20@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Nov 2003 11:00:04 -0600
To: "Steve Silverman" <steves@shentel.net>, "Janet Gunn" <jgunn@ix.netcom.com>,
        "Ken Carlberg" <carlberg@g11.org.uk>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: <ieprep@ietf.org>
In-Reply-To: <CIEELMKPOOAMCIAKANLBOENLDEAA.steves@shentel.net>
References: <4.3.2.7.2.20031125180153.07c6dcc0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 08:26 PM 11/25/2003 -0500, Steve Silverman wrote:


> > -----Original Message-----
> > From: James M. Polk [mailto:jmpolk@cisco.com]
> > Sent: Tuesday, November 25, 2003 7:31 PM
> > To: Janet Gunn; Ken Carlberg; 'Steve Silverman'
> > Cc: ieprep@ietf.org
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> >
> > So, without the providing the feedback necessary to
> > terminate a call flow
> > or series of call flows (and inform the user what has
> > occurred) within the
> > same priority level within a domain, how is MLEF a benefit?
>
>When the voice traffic exceeds the link capacity, the high priority
>calls
>get thru intelligibly. This has been demonstrated.

It has also been demonstrated that all calls of lower priority don't 
receive the required feedback necessary to perform correctly. It has been 
demonstrated that all calls of lower priority levels don't receive anything 
intelligibly. The GSCR mandates that all calls *up* are of MOS = 4.0 or higher.

Please refer to the GSCR for mandatory test criteria to this which every 
vendor MUST comply with in order to be certified  by DISA.

MLEF is contradictory to the GSCR - one has to give.


> >
> > >Please explain.
> > >
> >
> >
> > cheers,
> > James
> >
> >                                 *******************
> >                  Truth is not to be argued... it is to be presented
> >
> >


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Wed Nov 26 12:08:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17668
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 12:08:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP393-0001bL-Kk
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:08:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQH85Us006149
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:08:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP393-0001b6-82
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:08:05 -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 MAA17625
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 12:07:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP391-0001Pi-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:08:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP391-0001Pf-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:08:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP390-0001Yd-HQ; Wed, 26 Nov 2003 12:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP38r-0001WC-2B
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 12:07:53 -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 MAA17614;
	Wed, 26 Nov 2003 12:07:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP38p-0001PB-00; Wed, 26 Nov 2003 12:07:51 -0500
Received: from amer-bmta03.csc.com ([20.137.252.210])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP38k-0001P4-00; Wed, 26 Nov 2003 12:07:46 -0500
Received: from csc.com (va-fch32.csc.com [20.6.39.233])
	by amer-bmta03.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAQH6JiY013821;
	Wed, 26 Nov 2003 12:06:21 -0500 (EST)
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: Mpierce1@aol.com
Cc: carlberg@g11.org.uk, ieprep@ietf.org, ieprep-admin@ietf.org,
        jgunn@ix.netcom.com, jmpolk@cisco.com, steves@shentel.net
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OF6813F432.A59D2645-ON85256DEA.005B713C-85256DEA.005E1F40@com>
From: "Janet P Gunn" <jgunn6@csc.com>
Date: Wed, 26 Nov 2003 12:08:03 -0500
X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 5.0.11  |July 24, 2002) at
 11/26/2003 12:08:19 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>


Mike,

This is the part I am not understanding properly.

"That means that, during the short period of congestion, the packet loss
needs to be concentrated on 90% of the calls (lower ones) rather then
spread across all 100% of them. As the lower priority calls drop, CAC
prevents new low priority calls because it knows that the total number of
calls is already at or above the limit, and the need to discard packets
quickly goes away."

WHY do the lower priority calls drop?  Because they become unintelligible
and the users hang up?  Because they get to the end of the conversation and
hang up normally (attrition)?  Because some third party (CAC mechanism or
whatever) "disconnects" them at the "call" level?

I am also a little confused about why the CAC will prevent replacement of
the low priority calls with new low priority calls.

Your premise is: "I would claim that a reasonable example of what needs to
be supported would be 10% of the calls are high priority with all of them
beginning in a rather short time interval (right after the diaster)."   Is
the total number of calls at that point below, at, or above  "the limit"?

If above "the limit" how did it get that way?  Does the CAC admit high
priority calls even when "the limit" has been reached? In that case
admitting the "excess calls" has resulted in packets needing to be dropped,
and the mechanism chooses which packets get dropped.

But if "at" or "below" the limit the "average" packet flow should be within
the engineered limits.  Do you assume that statistical variation will lead
to some packet dropping when the number of calls is "at the limit"?  If
"statistical" variation takes it to the point where packets need to be
dropped, then you have preferential dropping.  The CAC would have no reason
to reject new calls (of any priority) on the basis of the limit.  If there
is excess demand (at the call level), as each low priority call ends, a new
one will replace it.  If (you didn't say it did, but it seems plausible)
the CAC gives preference (in call admission) to high priority calls, then
the proportion of high level calls will increase, so the "pain" (packet
dropping) will be spread over  fewer (low priority) calls.

Is this limit that the CAC bases its decision on a limit at the source
(regardless of where the calls are going), or per source-destination pair,
or for a single link?

Just trying to understand.


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

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




                                                                                                                                 
                      Mpierce1                                                                                                   
                      @aol.com                 To:      jmpolk@cisco.com, jgunn@ix.netcom.com, carlberg@g11.org.uk,              
                      Sent by:                 steves@shentel.net                                                                
                      ieprep-admin             cc:      ieprep@ietf.org                                                          
                                               Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               
                                                                                                                                 
                      11/26/2003 11:04                                                                                           
                      AM                                                                                                         
                                                                                                                                 
                                                                                                                                 




In a message dated 11/25/2003 7:33:19 PM Eastern Standard Time,
jmpolk@cisco.com writes:


 To summarize what I am hearing about MLEF, this proposed PHB will delay
 the
 time between packets within the same flow (which codecs don't typically
 like) unless there is some mechanism of dropping the delayed packets
 (which
 codecs don't like either). Creating a PHB with a drop precedence similar
 to
 AF and apply it to a delay sensitive application (like voice) will create
 this dropping capability (which codecs don't like) and allow packets that
 are not delayed to arrive on time but with lost information the codec
 requires to replicate the audible speech patterns of the speaker. MLPP
 users are trained to understand what to do when they hear a preemption
 tone
 or announcement - but if they don't hear this tone (or announcement),
 might
 their behavior be to stay on the call longer than is necessary? Will they
 quickly call again (making the problem sustain itself).




[MAP] We need to remember that EF today says that a router must discard
packets that are in excess of the engineered limits (for the "EF" queue).
This can be done by having a simple size limit on the queue or by using
more complicated random early drop algorithms. The only thing that MLEF
adds is to define a way to decide which packets to drop - nothing more. Way
too much has been made about the efects of MLEF (on QoS, etc.). MLEF
doesn't add bad QoS, it only says which calls feel the effect that is
already there without MLEF.

I would claim that a reasonable example of what needs to be supported would
be 10% of the calls are high priority with all of them beginning in a
rather short time interval (right after the diaster). That means that,
during the short period of congestion, the packet loss needs to be
concentrated on 90% of the calls (lower ones) rather then spread across all
100% of them. As the lower priority calls drop, CAC prevents new low
priority calls because it knows that the total number of calls is already
at or above the limit, and the need to discard packets quickly goes away.
This can be easily demonstrated.


 Further adding to this problem space is the behavior of codecs and their
 own packet loss compensation. Most codecs that have this ability - when
 they understand that there is packet loss, will actually increase the
 amount of bandwidth transmitted (because duplicate voice samples are added

 other RTP packets just in case the packet before or after is lost) -
 making
 the problem worse (nearly exponentially worse) because now each call flow
 requires more bandwidth...




[MAP] I am not aware of any codec that adapts to packet loss by increasing
its transmitted rate. I suppose there could be one. Can you give an
example? They certainly couldn't be used in a possibly congested network,
except maybe for the very high priority calls. This would be contrary to
the operation of TCP which is required to drop back on packet rate when
loss occurs. (Before anyone comments, I'm not saying that TCP is being used
for voice packets. The solution for voice shouldn't take the opposite
approach!)


 So, without the providing the feedback necessary to terminate a call flow
 or series of call flows (and inform the user what has occurred) within the

 same priority level within a domain, how is MLEF a benefit?





[MAP] I believe there must be feedback from whatever knows about packet
flow congestion to whatever limits new calls (CAC), even if we never talked
about Assured Service. This must be possible for normal, non-priority
traffic. In the case of Assured Service, preemption of existing calls can
be added to this feedback. However, any such feedback can not take effect
immediately, so something else needs to deal with the short term packet
congestion. That is MLEF.

Note that, because of the probabilistic nature of packet flows and
congestion, we would not want preemption of any existing call to be caused
by a very short term packet loss or queue overflow. Temporary loss of
packets (and audio) with means to stop the congestion is much better.


Mike





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



From exim@www1.ietf.org  Wed Nov 26 12:19:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18072
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 12:19: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 1AP3Je-0002Tm-F3
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:19:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHJ2ED009524
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:19:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Je-0002TX-BW
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:19:02 -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 MAA18060
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 12:18:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Jc-0001Za-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:19:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Jc-0001ZX-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:19:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Jc-0002So-K9; Wed, 26 Nov 2003 12:19:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Jb-0002Sc-PL
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 12:18:59 -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 MAA18057
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 12:18:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Ja-0001ZU-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:18:58 -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 1AP3JZ-0001ZB-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:18:57 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 26 Nov 2003 09:20:13 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAQHIPjq020538;
	Wed, 26 Nov 2003 09:18:25 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA23193; Wed, 26 Nov 2003 09:18:23 -0800 (PST)
Message-Id: <4.3.2.7.2.20031126110159.022927b0@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Nov 2003 11:18:22 -0600
To: Mpierce1@aol.com, jgunn@ix.netcom.com, carlberg@g11.org.uk,
        steves@shentel.net
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: ieprep@ietf.org
In-Reply-To: <19c.1d5d0b0d.2cf6290c@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

comments below

At 11:04 AM 11/26/2003 -0500, Mpierce1@aol.com wrote:
>In a message dated 11/25/2003 7:33:19 PM Eastern Standard Time, 
>jmpolk@cisco.com writes:
>
>
>>To summarize what I am hearing about MLEF, this proposed PHB will delay the
>>time between packets within the same flow (which codecs don't typically
>>like) unless there is some mechanism of dropping the delayed packets (which
>>codecs don't like either). Creating a PHB with a drop precedence similar to
>>AF and apply it to a delay sensitive application (like voice) will create
>>this dropping capability (which codecs don't like) and allow packets that
>>are not delayed to arrive on time but with lost information the codec
>>requires to replicate the audible speech patterns of the speaker. MLPP
>>users are trained to understand what to do when they hear a preemption tone
>>or announcement - but if they don't hear this tone (or announcement), might
>>their behavior be to stay on the call longer than is necessary? Will they
>>quickly call again (making the problem sustain itself).
>
>
>[MAP] We need to remember that EF today says that a router must discard 
>packets that are in excess of the engineered limits (for the "EF" queue). 
>This can be done by having a simple size limit on the queue or by using 
>more complicated random early drop algorithms. The only thing that MLEF 
>adds is to define a way to decide which packets to drop - nothing more. 
>Way too much has been made about the efects of MLEF (on QoS, etc.). MLEF 
>doesn't add bad QoS, it only says which calls feel the effect that is 
>already there without MLEF.

I would argue that MLEF is a hack at CAC. In choosing which calls receive 
good services and which don't, that's one function of CAC.


>I would claim that a reasonable example of what needs to be supported 
>would be 10% of the calls are high priority with all of them beginning in 
>a rather short time interval (right after the diaster). That means that, 
>during the short period of congestion, the packet loss needs to be 
>concentrated on 90% of the calls (lower ones) rather then spread across 
>all 100% of them.

Several references provide mathematical analysis that > 5% packet loss 
drops MOS to below 3.1 (considered POOR).

If this is in a tactical environment, this could cost lives because orders 
weren't heard (unless field sergeants were give F or FO precedence level 
access)

>As the lower priority calls drop, CAC prevents new low priority calls 
>because it knows that the total number of calls

MLEF has no concept of "session" - so MLEF isn't CAC, yet it's acting like 
it is. And if it looks like a duck, and walks like a duck.....

>is already at or above the limit, and the need to discard packets quickly 
>goes away.

In times of disaster, do the same/normal 3 minutes per average call still 
apply?

Without the currently available feedback of a preemption tone or 
announcement, does user behavior remain the same?

>This can be easily demonstrated.
>
>>
>>Further adding to this problem space is the behavior of codecs and their
>>own packet loss compensation. Most codecs that have this ability - when
>>they understand that there is packet loss, will actually increase the
>>amount of bandwidth transmitted (because duplicate voice samples are added
>>other RTP packets just in case the packet before or after is lost) - making
>>the problem worse (nearly exponentially worse) because now each call flow
>>requires more bandwidth...
>
>
>
>
>[MAP] I am not aware of any codec that adapts to packet loss by increasing 
>its transmitted rate.

Any codec with some form of Packet Loss Correction does this very thing - 
and a lot of ITU codecs do.

>I suppose there could be one. Can you give an example?

Some of these are in their specs,
some are with proprietary extensions

         G.729
         G.711
         G.723
         iLBC
         the list is longer...

>They certainly couldn't be used in a possibly congested network, except 
>maybe for the very high priority calls. This would be contrary to the 
>operation of TCP

huh... when does RTP use TCP?

(not for voice, not here)

>which is required to drop back on packet rate when loss occurs. (Before 
>anyone comments, I'm not saying that TCP is being used for voice packets. 
>The solution for voice shouldn't take the opposite approach!)
>
>>
>>So, without the providing the feedback necessary to terminate a call flow
>>or series of call flows (and inform the user what has occurred) within the
>>same priority level within a domain, how is MLEF a benefit?
>>
>>
>
>
>[MAP] I believe there must be feedback from whatever knows about packet 
>flow congestion to whatever limits new calls (CAC),

In MLEF, the router queue mechanism would know - and that's about it. 
Should it open up a TCP socket back to each transmitting device to provide 
this feedback?

>even if we never talked about Assured Service. This must be possible for 
>normal, non-priority traffic. In the case of Assured Service, preemption 
>of existing calls can be added to this feedback. However, any such 
>feedback can not take effect immediately, so something else needs to deal 
>with the short term packet congestion. That is MLEF.
>
>Note that, because of the probabilistic nature of packet flows and 
>congestion, we would not want preemption of any existing call to be caused 
>by a very short term packet loss or queue overflow. Temporary loss of 
>packets (and audio) with means to stop the congestion is much better.
>
>
>Mike


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Wed Nov 26 12:22:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18155
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 12:22:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Mc-0002bS-Uf
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:22:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHM6ct010000
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:22:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Mc-0002bD-QR
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:22:06 -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 MAA18136
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 12:21:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Mb-0001bb-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:22:05 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Ma-0001bY-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:22:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3MW-0002Zk-Ki; Wed, 26 Nov 2003 12:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3Lw-0002Z5-Lw
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 12:21: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 MAA18126;
	Wed, 26 Nov 2003 12:21:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Lu-0001bE-00; Wed, 26 Nov 2003 12:21:22 -0500
Received: from amer-bmta03.csc.com ([20.137.252.210])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3Lu-0001bB-00; Wed, 26 Nov 2003 12:21:22 -0500
Received: from csc.com (va-fch32.csc.com [20.6.39.233])
	by amer-bmta03.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAQHJ8ih016805;
	Wed, 26 Nov 2003 12:20:33 -0500 (EST)
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: "Steve Silverman" <steves@shentel.net>
Cc: "Ken Carlberg" <carlberg@g11.org.uk>, ieprep@ietf.org,
        ieprep-admin@ietf.org, "Janet Gunn" <jgunn@ix.netcom.com>,
        "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OF3830C7DB.2D9B103F-ON85256DEA.005F2907-85256DEA.005F8D66@com>
From: "Janet P Gunn" <jgunn6@csc.com>
Date: Wed, 26 Nov 2003 12:23:41 -0500
X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 5.0.11  |July 24, 2002) at
 11/26/2003 12:22:31 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>


"When the voice traffic exceeds the link capacity, the high priority
calls
get thru intelligibly. This has been demonstrated."

What happens to the low priority calls?  That is what I am still not
getting.

I'd also be interested in the range of conditions for which it has been
demonstrated.

Janet


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

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




                                                                                                                                 
                      "Steve                                                                                                     
                      Silverman"               To:      "James M. Polk" <jmpolk@cisco.com>, "Janet Gunn" <jgunn@ix.netcom.com>,  
                      <steves                  "Ken Carlberg" <carlberg@g11.org.uk>                                              
                      @shentel.net>            cc:      <ieprep@ietf.org>                                                        
                      Sent by:                 Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               
                      ieprep-admin                                                                                               
                                                                                                                                 
                                                                                                                                 
                      11/25/2003 08:26                                                                                           
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 






> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, November 25, 2003 7:31 PM
> To: Janet Gunn; Ken Carlberg; 'Steve Silverman'
> Cc: ieprep@ietf.org
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
.........
>
> To summarize what I am hearing about MLEF, this proposed
> PHB will delay the
> time between packets within the same flow (which codecs
> don't typically
> like) unless there is some mechanism of dropping the
> delayed packets (which
> codecs don't like either).

No.  MLEF drops some lower priority packets when there is congestion.
It never delays packets.

>Creating a PHB with a drop
> precedence similar to
> AF and apply it to a delay sensitive application (like
> voice) will create
> this dropping capability (which codecs don't like) and
> allow packets that
> are not delayed to arrive on time but with lost information
> the codec
> requires to replicate the audible speech patterns of the
> speaker. MLPP
> users are trained to understand what to do when they hear a
> preemption tone
> or announcement - but if they don't hear this tone (or
> announcement), might
> their behavior be to stay on the call longer than is
> necessary? Will they
> quickly call again (making the problem sustain itself).
>
> Further adding to this problem space is the behavior of
> codecs and their
> own packet loss compensation. Most codecs that have this
> ability - when
> they understand that there is packet loss, will actually
> increase the
> amount of bandwidth transmitted (because duplicate voice
> samples are added
> other RTP packets just in case the packet before or after
> is lost) - making
> the problem worse (nearly exponentially worse) because now
> each call flow
> requires more bandwidth...
>
> So, without the providing the feedback necessary to
> terminate a call flow
> or series of call flows (and inform the user what has
> occurred) within the
> same priority level within a domain, how is MLEF a benefit?

When the voice traffic exceeds the link capacity, the high priority
calls
get thru intelligibly. This has been demonstrated.

>
> >Please explain.
> >
>
>
> cheers,
> James
>
>                                 *******************
>                  Truth is not to be argued... it is to be presented
>
>



_______________________________________________
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



From exim@www1.ietf.org  Wed Nov 26 12:45:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19037
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 12:45:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3ir-0003yU-6Y
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:45:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQHj57t015272
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 12:45:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3ir-0003yF-2d
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 12:45:05 -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 MAA19019
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 12:44:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3ip-0001qn-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:45:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3io-0001qk-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 12:45:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3ip-0003wY-7L; Wed, 26 Nov 2003 12:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP3iR-0003vy-EQ
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 12:44:39 -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 MAA18999
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 12:44:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3iP-0001qF-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:44:37 -0500
Received: from harrier.mail.pas.earthlink.net ([207.217.120.12])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP3iO-0001qC-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 12:44:37 -0500
Received: from misspiggy.psp.pas.earthlink.net ([207.217.78.246])
	by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1AP3hK-0004gW-00; Wed, 26 Nov 2003 09:43:30 -0800
Message-ID: <2710553.1069868610729.JavaMail.root@misspiggy.psp.pas.earthlink.net>
Date: Wed, 26 Nov 2003 12:43:00 -0500 (GMT-05:00)
From: Janet Gunn <jgunn@ix.netcom.com>
Reply-To: Janet Gunn <jgunn@ix.netcom.com>
To: "James M. Polk" <jmpolk@cisco.com>, Mpierce1@aol.com, jgunn@ix.netcom.com,
        carlberg@g11.org.uk, steves@shentel.net
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Just responding to one, slightly tangental, question.

"In times of disaster, do the same/normal 3 minutes per average call still 
apply?" 

 The data I have seen for 9/11 actually indicated a slightly SHORTER than "normal" average holding time.

Janet
-----Original Message-----
From: "James M. Polk" <jmpolk@cisco.com>
Sent: Nov 26, 2003 12:18 PM
To: Mpierce1@aol.com, jgunn@ix.netcom.com, carlberg@g11.org.uk, 
	steves@shentel.net
Cc: ieprep@ietf.org
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

comments below

At 11:04 AM 11/26/2003 -0500, Mpierce1@aol.com wrote:
>In a message dated 11/25/2003 7:33:19 PM Eastern Standard Time, 
>jmpolk@cisco.com writes:
>
>
>>To summarize what I am hearing about MLEF, this proposed PHB will delay the
>>time between packets within the same flow (which codecs don't typically
>>like) unless there is some mechanism of dropping the delayed packets (which
>>codecs don't like either). Creating a PHB with a drop precedence similar to
>>AF and apply it to a delay sensitive application (like voice) will create
>>this dropping capability (which codecs don't like) and allow packets that
>>are not delayed to arrive on time but with lost information the codec
>>requires to replicate the audible speech patterns of the speaker. MLPP
>>users are trained to understand what to do when they hear a preemption tone
>>or announcement - but if they don't hear this tone (or announcement), might
>>their behavior be to stay on the call longer than is necessary? Will they
>>quickly call again (making the problem sustain itself).
>
>
>[MAP] We need to remember that EF today says that a router must discard 
>packets that are in excess of the engineered limits (for the "EF" queue). 
>This can be done by having a simple size limit on the queue or by using 
>more complicated random early drop algorithms. The only thing that MLEF 
>adds is to define a way to decide which packets to drop - nothing more. 
>Way too much has been made about the efects of MLEF (on QoS, etc.). MLEF 
>doesn't add bad QoS, it only says which calls feel the effect that is 
>already there without MLEF.

I would argue that MLEF is a hack at CAC. In choosing which calls receive 
good services and which don't, that's one function of CAC.


>I would claim that a reasonable example of what needs to be supported 
>would be 10% of the calls are high priority with all of them beginning in 
>a rather short time interval (right after the diaster). That means that, 
>during the short period of congestion, the packet loss needs to be 
>concentrated on 90% of the calls (lower ones) rather then spread across 
>all 100% of them.

Several references provide mathematical analysis that > 5% packet loss 
drops MOS to below 3.1 (considered POOR).

If this is in a tactical environment, this could cost lives because orders 
weren't heard (unless field sergeants were give F or FO precedence level 
access)

>As the lower priority calls drop, CAC prevents new low priority calls 
>because it knows that the total number of calls

MLEF has no concept of "session" - so MLEF isn't CAC, yet it's acting like 
it is. And if it looks like a duck, and walks like a duck.....

>is already at or above the limit, and the need to discard packets quickly 
>goes away.

In times of disaster, do the same/normal 3 minutes per average call still 
apply?

Without the currently available feedback of a preemption tone or 
announcement, does user behavior remain the same?

>This can be easily demonstrated.
>
>>
>>Further adding to this problem space is the behavior of codecs and their
>>own packet loss compensation. Most codecs that have this ability - when
>>they understand that there is packet loss, will actually increase the
>>amount of bandwidth transmitted (because duplicate voice samples are added
>>other RTP packets just in case the packet before or after is lost) - making
>>the problem worse (nearly exponentially worse) because now each call flow
>>requires more bandwidth...
>
>
>
>
>[MAP] I am not aware of any codec that adapts to packet loss by increasing 
>its transmitted rate.

Any codec with some form of Packet Loss Correction does this very thing - 
and a lot of ITU codecs do.

>I suppose there could be one. Can you give an example?

Some of these are in their specs,
some are with proprietary extensions

         G.729
         G.711
         G.723
         iLBC
         the list is longer...

>They certainly couldn't be used in a possibly congested network, except 
>maybe for the very high priority calls. This would be contrary to the 
>operation of TCP

huh... when does RTP use TCP?

(not for voice, not here)

>which is required to drop back on packet rate when loss occurs. (Before 
>anyone comments, I'm not saying that TCP is being used for voice packets. 
>The solution for voice shouldn't take the opposite approach!)
>
>>
>>So, without the providing the feedback necessary to terminate a call flow
>>or series of call flows (and inform the user what has occurred) within the
>>same priority level within a domain, how is MLEF a benefit?
>>
>>
>
>
>[MAP] I believe there must be feedback from whatever knows about packet 
>flow congestion to whatever limits new calls (CAC),

In MLEF, the router queue mechanism would know - and that's about it. 
Should it open up a TCP socket back to each transmitting device to provide 
this feedback?

>even if we never talked about Assured Service. This must be possible for 
>normal, non-priority traffic. In the case of Assured Service, preemption 
>of existing calls can be added to this feedback. However, any such 
>feedback can not take effect immediately, so something else needs to deal 
>with the short term packet congestion. That is MLEF.
>
>Note that, because of the probabilistic nature of packet flows and 
>congestion, we would not want preemption of any existing call to be caused 
>by a very short term packet loss or queue overflow. Temporary loss of 
>packets (and audio) with means to stop the congestion is much better.
>
>
>Mike


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented





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



From exim@www1.ietf.org  Wed Nov 26 13:08:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20039
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 13:08: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 1AP459-0005wd-Lb
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 13:08:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQI86El022845
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 13:08:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP457-0005wH-2S
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 13:08:05 -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 NAA20033
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 13:07:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP455-0002Cw-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 13:08:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP454-0002Ct-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 13:08:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP453-0005tr-Nw; Wed, 26 Nov 2003 13:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP44y-0005sP-It
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 13:07: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 NAA20016
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 13:07:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP44w-0002Cb-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 13:07:54 -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 1AP44w-0002CD-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 13:07:54 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 26 Nov 2003 10:08:56 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAQI7Kw5012962;
	Wed, 26 Nov 2003 10:07:21 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA19274; Wed, 26 Nov 2003 10:07:19 -0800 (PST)
Message-Id: <4.3.2.7.2.20031126120419.024923c8@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Nov 2003 12:07:18 -0600
To: Janet Gunn <jgunn@ix.netcom.com>, Mpierce1@aol.com, jgunn@ix.netcom.com,
        carlberg@g11.org.uk, steves@shentel.net
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: ieprep@ietf.org
In-Reply-To: <2710553.1069868610729.JavaMail.root@misspiggy.psp.pas.eart
 hlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 12:43 PM 11/26/2003 -0500, Janet Gunn wrote:
>Just responding to one, slightly tangental, question.
>
>"In times of disaster, do the same/normal 3 minutes per average call still
>apply?"
>
>  The data I have seen for 9/11 actually indicated a slightly SHORTER than 
> "normal" average holding time.

What was the feedback mechanism (fast busy)?

What if there were no feedback mechanism that all the users were trained to 
pay attention to/for (like a preemption tone or announcement)?


>Janet




cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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



From exim@www1.ietf.org  Wed Nov 26 14:19:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22539
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 14:19: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 1AP5Bo-0002Gx-D5
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 14:19:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQJJ477008729
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 14:19:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP5Bo-0002Gi-9T
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 14:19: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 OAA22529
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 14:18:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP5Bl-00039k-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 14:19:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP5Bl-00039h-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 14:19:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP5Bk-0002G2-Lw; Wed, 26 Nov 2003 14:19:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP5BU-0002Fc-HN
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 14:18:44 -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 OAA22517;
	Wed, 26 Nov 2003 14:18:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP5BR-00039T-00; Wed, 26 Nov 2003 14:18:41 -0500
Received: from obomta.csc.com ([20.137.252.210] helo=amer-bmta03.csc.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP5BJ-00039Q-00; Wed, 26 Nov 2003 14:18:38 -0500
Received: from csc.com (va-fch32.csc.com [20.6.39.233])
	by amer-bmta03.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAQJGFii015053;
	Wed, 26 Nov 2003 14:16:42 -0500 (EST)
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: "James M. Polk" <jmpolk@cisco.com>
Cc: carlberg@g11.org.uk, ieprep@ietf.org, ieprep-admin@ietf.org,
        Janet Gunn <jgunn@ix.netcom.com>, Mpierce1@aol.com, steves@shentel.net
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OF6168555C.DA65D735-ON85256DEA.0068E708-85256DEA.0068F70D@com>
From: "Janet P Gunn" <jgunn6@csc.com>
Date: Wed, 26 Nov 2003 14:06:29 -0500
X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 5.0.11  |July 24, 2002) at
 11/26/2003 02:18:40 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>


Feedback for what?  This was for the NS/EP calls in the PSTN.


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

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




                                                                                                                                 
                      "James M. Polk"                                                                                            
                      <jmpolk                  To:      Janet Gunn <jgunn@ix.netcom.com>, Mpierce1@aol.com, jgunn@ix.netcom.com, 
                      @cisco.com>              carlberg@g11.org.uk, steves@shentel.net                                           
                      Sent by:                 cc:      ieprep@ietf.org                                                          
                      ieprep-admin             Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               
                                                                                                                                 
                                                                                                                                 
                      11/26/2003 01:07                                                                                           
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 




At 12:43 PM 11/26/2003 -0500, Janet Gunn wrote:
>Just responding to one, slightly tangental, question.
>
>"In times of disaster, do the same/normal 3 minutes per average call still
>apply?"
>
>  The data I have seen for 9/11 actually indicated a slightly SHORTER than

> "normal" average holding time.

What was the feedback mechanism (fast busy)?

What if there were no feedback mechanism that all the users were trained to

pay attention to/for (like a preemption tone or announcement)?


>Janet




cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


_______________________________________________
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



From exim@www1.ietf.org  Wed Nov 26 15:20:32 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26477
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 15:20: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 1AP68t-0006dh-N1
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 15:20:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQKK7ua025516
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 15:20:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP68q-0006cY-QZ
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 15:20: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 PAA26414
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 15:19:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP68p-0004CS-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 15:20:03 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP68p-0004CO-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 15:20:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP68n-0006ba-VX; Wed, 26 Nov 2003 15:20:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP67u-0006Rl-VL
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 15:19: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 PAA26358
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 15:18:53 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP67t-0004BD-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 15:19:05 -0500
Received: from imo-r08.mx.aol.com ([152.163.225.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP67s-0004Aj-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 15:19:04 -0500
Received: from Mpierce1@aol.com
	by imo-r08.mx.aol.com (mail_out_v36_r1.1.) id c.c6.258a84c4 (2168);
	Wed, 26 Nov 2003 15:17:56 -0500 (EST)
Message-ID: <c6.258a84c4.2cf66474@aol.com>
Date: Wed, 26 Nov 2003 15:17:56 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: jmpolk@cisco.com, steves@shentel.net, jgunn@ix.netcom.com,
        carlberg@g11.org.uk
CC: ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_c6.258a84c4.2cf66474_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_c6.258a84c4.2cf66474_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/26/2003 12:04:20 PM Eastern Standard Time, 
jmpolk@cisco.com writes:


> Please refer to the GSCR for mandatory test criteria to this which every 
> vendor MUST comply with in order to be certified  by DISA.
> 
> MLEF is contradictory to the GSCR - one has to give.
> 


The current GSCR was written for circuit mode. Unless we get it changed, it 
will apply to packet mode (even when it doesn't always make sense). This is one 
of the areas we are trying to change, so it correctly takes into account the 
advantages of using packet.

I see needing some qualifying statement that an MOS=4.0 is not required in 
the case of the resources for low precedence calls being preempted for high 
precedence calls. It analogous to the requirements for premature disconnect. You 
can't fail the requirement because preemption causes disconnects.

In any case, ignoring priority calls for a moment, how would this criteria be 
met, that is, limiting the number of packet flows that get attempted through 
a single, limited resource so that there is no congestion or packet loss?

Mike


--part1_c6.258a84c4.2cf66474_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/26/=
2003 12:04:20 PM Eastern Standard Time, jmpolk@cisco.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Please refer to the GSCR fo=
r mandatory test criteria to this which every=20
<BR>vendor MUST comply with in order to be certified &nbsp;by DISA.
<BR>
<BR>MLEF is contradictory to the GSCR - one has to give.
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>
<BR>The current GSCR was written for circuit mode. Unless we get it changed,=
 it will apply to packet mode (even when it doesn't always make sense). This=
 is one of the areas we are trying to change, so it correctly takes into acc=
ount the advantages of using packet.
<BR>
<BR>I see needing some qualifying statement that an MOS=3D4.0 is not require=
d in the case of the resources for low precedence calls being preempted for=20=
high precedence calls. It analogous to the requirements for premature discon=
nect. You can't fail the requirement because preemption causes disconnects.
<BR>
<BR>In any case, ignoring priority calls for a moment, how would this criter=
ia be met, that is, limiting the number of packet flows that get attempted t=
hrough a single, limited resource so that there is no congestion or packet l=
oss?
<BR>
<BR>Mike
<BR></FONT></HTML>

--part1_c6.258a84c4.2cf66474_boundary--

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



From exim@www1.ietf.org  Wed Nov 26 15:25:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26718
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 15:25:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP6Dk-0007Ob-FR
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 15:25:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQKP8Pn028423
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 15:25:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP6Dk-0007OM-BK
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 15:25: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 PAA26670
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 15:24:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP6Di-0004Hl-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 15:25:06 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP6Di-0004Hi-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 15:25:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP6Dg-0007KC-95; Wed, 26 Nov 2003 15:25:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP6DX-0007Ev-6q
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 15:24:55 -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 PAA26654;
	Wed, 26 Nov 2003 15:24:41 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP6DV-0004HL-00; Wed, 26 Nov 2003 15:24:53 -0500
Received: from imo-m01.mx.aol.com ([64.12.136.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP6DV-0004HA-00; Wed, 26 Nov 2003 15:24:53 -0500
Received: from Mpierce1@aol.com
	by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id t.fb.4aefa217 (2168);
	Wed, 26 Nov 2003 15:24:17 -0500 (EST)
Message-ID: <fb.4aefa217.2cf665f1@aol.com>
Date: Wed, 26 Nov 2003 15:24:17 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
To: jgunn6@csc.com
CC: carlberg@g11.org.uk, ieprep@ietf.org, ieprep-admin@ietf.org,
        jgunn@ix.netcom.com, jmpolk@cisco.com, steves@shentel.net
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_fb.4aefa217.2cf665f1_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_fb.4aefa217.2cf665f1_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/26/2003 12:08:13 PM Eastern Standard Time, 
jgunn6@csc.com writes:


> Mike,
> 
> This is the part I am not understanding properly.
> 
> "That means that, during the short period of congestion, the packet loss
> needs to be concentrated on 90% of the calls (lower ones) rather then
> spread across all 100% of them. As the lower priority calls drop, CAC
> prevents new low priority calls because it knows that the total number of
> calls is already at or above the limit, and the need to discard packets
> quickly goes away."
> 
> WHY do the lower priority calls drop?  Because they become unintelligible
> and the users hang up?  Because they get to the end of the conversation and
> hang up normally (attrition)?  Because some third party (CAC mechanism or
> 



[MAP] Yes, mainly to the 2nd reason - normal attrition. Yes, if the quality 
got that bad, more might be enticed to release early, but I believe limits can 
be set to make this highly unlikely. As for the third reason, yes there may be 
preemption. I do not consider this a part of CAC. (I will limit my notion of 
CAC to something that prevents new call setups, not something that preempts 
existing ones.)

> 
> I am also a little confused about why the CAC will prevent replacement of
> 



[MAP] There have to be different limits for different precedence levels of 
calls, as I described in Section 3.2 of my pref-treat-examples draft. For 
example, if CAC is set to limit the total number of Routine calls on a resource to 
say 100 to provide MOS=4.0, but allows priority calls to push the total over 
that, say to 105, then every time a priority call is setup and one routine call 
drops, a routine call can not be setup again, since there are then still 100 
calls. (Notice that no change in the CAC limits is required in real-time when a 
priority call occurs.)

> 
> Your premise is: "I would claim that a reasonable example of what needs to
> be supported would be 10% of the calls are high priority with all of them
> beginning in a rather short time interval (right after the diaster)."   Is
> the total number of calls at that point below, at, or above  

[MAP] Yes, it can be any of these.

> 
> If above "the limit" how did it get that way?  Does the CAC admit high
> priority calls even when "the limit" has been reached? In that case
> admitting the "excess calls" has resulted in packets needing to be dropped,
> 


[MAP] Yes, CAC admits Priority calls to go above the "limit" set for normal 
traffic, which is what causes the temporary need to discard packets.

> 
> But if "at" or "below" the limit the "average" packet flow should be within
> the engineered limits.  Do you assume that statistical variation will lead
> 


[MAP] Yes, I believe this can still happen. Say the link can support 100 
packet flows (calls). If the packets arrive completely random and spread out 
perfectly over time, and the queue is served at a regular rate, every packet queued 
is dequeued and sent before or just as the next packet arrives. The queue 
limit could be 50 packets. If all 100 sources sent packets that arrived at the 
same instant, they would all need to go into the queue at the same time and 
would not fit. 50 would be discarded. This is an extreme case, but that's the 
nature of a statistical model. It's so far out that we don't worry about it, but 
it can happen. (Note: We don't want any preemption or change to the CAC to be 
caused by such a far-out case.) If the CAC limt were set so that packet discard 
absolutely never occurred, then I would argue that the CAC limit should be 
higher.

  If  > "statistical" variation takes it to the point where packets need to be
> 



[MAP] Yes, that's the whole point of MLEF. It would have some affect on which 
of the above 50 packets are discarded (although it isn't really intended to 
address this rare statistical case).

 The CAC would have no reason
> 



[MAP] A CAC could take into account some notion of the loading on a link (or 
overflow of the buffer) but I see that as rather complicated and too transient 
to affect a CAC (which must be resident someplace else).

> is excess demand (at the call level), as each low priority call 
> ends, a new
> one will replace it.  If (you didn't say it did, but it seems plausible)
> the CAC gives preference (in call admission) to high priority calls, then
> the proportion of high level calls will increase, so the "pain" (packet
> dropping) will be spread over  



[MAP] It is essential that CAC gives preference to high priority calls in 
order for MLEF to work properly. I presume any network would set a limit on how 
many priority calls could exist. If all started at the exact same moment, then 
there would be significant, temporary "pain" on the existing normal calls. But 
preemption is also a "pain". With appropriate assumptions about the rate at 
which high priority calls will "suddenly" start and limits on how many are 
allowes, I believe the "pain" inflicted on the low priority calls can be bounded. 
It's under control of the network administrator to set the limits.

> 
> Is this limit that the CAC bases its decision on a limit at the source
> (regardless of where the calls are going), or per source-destination pair,
> or for a single link?
> 



[MAP] To be meaningful for VoIP (even without Assured Service or MLEF) it 
needs to be per single link (since that's where congestion can occur) but the 
decision must affect the source (prevent a source from setting up a new call). 
I'd like to see this issue discussed and solved separately from Assured Service, 
since it is still required without Assured Service.

> Just trying to understand.
> 

[MAP] Thanks for the question. I'm trying to take all these questions and 
work them into a better description for a draft of how MLEF and CAC work together.

Mike



--part1_fb.4aefa217.2cf665f1_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/26/=
2003 12:08:13 PM Eastern Standard Time, jgunn6@csc.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Mike,
<BR>
<BR>This is the part I am not understanding properly.
<BR>
<BR>"That means that, during the short period of congestion, the packet loss
<BR>needs to be concentrated on 90% of the calls (lower ones) rather then
<BR>spread across all 100% of them. As the lower priority calls drop, CAC
<BR>prevents new low priority calls because it knows that the total number o=
f
<BR>calls is already at or above the limit, and the need to discard packets
<BR>quickly goes away."
<BR>
<BR>WHY do the lower priority calls drop? &nbsp;Because they become unintell=
igible
<BR>and the users hang up? &nbsp;Because they get to the end of the conversa=
tion and
<BR>hang up normally (attrition)? &nbsp;Because some third party (CAC mechan=
ism or
<BR>whatever) "disconnects" them at the "call" level?</BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] Yes, mainly to the 2nd reason - normal attrition. Yes, if the qual=
ity got that bad, more might be enticed to release early, but I believe limi=
ts can be set to make this highly unlikely. As for the third reason, yes the=
re may be preemption. I do not consider this a part of CAC. (I will limit my=
 notion of CAC to something that prevents new call setups, not something tha=
t preempts existing ones.)
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>I am also a little confused about why the CAC will prevent replacement o=
f
<BR>the low priority calls with new low priority calls.</BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] There have to be different limits for different precedence levels=20=
of calls, as I described in Section 3.2 of my pref-treat-examples draft. For=
 example, if CAC is set to limit the total number of Routine calls on a reso=
urce to say 100 to provide MOS=3D4.0, but allows priority calls to push the=20=
total over that, say to 105, then every time a priority call is setup and on=
e routine call drops, a routine call can not be setup again, since there are=
 then still 100 calls. (Notice that no change in the CAC limits is required=20=
in real-time when a priority call occurs.)
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>Your premise is: "I would claim that a reasonable example of what needs=20=
to
<BR>be supported would be 10% of the calls are high priority with all of the=
m
<BR>beginning in a rather short time interval (right after the diaster)." &n=
bsp;&nbsp;Is
<BR>the total number of calls at that point below, at, or above &nbsp;"the l=
imit"?</BLOCKQUOTE>
<BR>
<BR>[MAP] Yes, it can be any of these.
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>If above "the limit" how did it get that way? &nbsp;Does the CAC admit h=
igh
<BR>priority calls even when "the limit" has been reached? In that case
<BR>admitting the "excess calls" has resulted in packets needing to be dropp=
ed,
<BR>and the mechanism chooses which packets get dropped.</BLOCKQUOTE>
<BR>
<BR>
<BR>[MAP] Yes, CAC admits Priority calls to go above the "limit" set for nor=
mal traffic, which is what causes the temporary need to discard packets.
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>But if "at" or "below" the limit the "average" packet flow should be wit=
hin
<BR>the engineered limits. &nbsp;Do you assume that statistical variation wi=
ll lead
<BR>to some packet dropping when the number of calls is "at the limit"?</BLO=
CKQUOTE>
<BR>
<BR>
<BR>[MAP] Yes, I believe this can still happen. Say the link can support 100=
 packet flows (calls). If the packets arrive completely random and spread ou=
t perfectly over time, and the queue is served at a regular rate, every pack=
et queued is dequeued and sent before or just as the next packet arrives. Th=
e queue limit could be 50 packets. If all 100 sources sent packets that arri=
ved at the same instant, they would all need to go into the queue at the sam=
e time and would not fit. 50 would be discarded. This is an extreme case, bu=
t that's the nature of a statistical model. It's so far out that we don't wo=
rry about it, but it can happen. (Note: We don't want any preemption or chan=
ge to the CAC to be caused by such a far-out case.) If the CAC limt were set=
 so that packet discard absolutely never occurred, then I would argue that t=
he CAC limit should be higher.
<BR>
<BR> &nbsp;If &nbsp;<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2p=
x solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">"statistica=
l" variation takes it to the point where packets need to be
<BR>dropped, then you have preferential dropping. </BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] Yes, that's the whole point of MLEF. It would have some affect on=20=
which of the above 50 packets are discarded (although it isn't really intend=
ed to address this rare statistical case).
<BR>
<BR> The CAC would have no reason
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">to reject new calls (of any=
 priority) on the basis of the limit.</BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] A CAC could take into account some notion of the loading on a link=
 (or overflow of the buffer) but I see that as rather complicated and too tr=
ansient to affect a CAC (which must be resident someplace else).
<BR>
<BR> If there <BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">is excess demand=20=
(at the call level), as each low priority call ends, a new
<BR>one will replace it. &nbsp;If (you didn't say it did, but it seems plaus=
ible)
<BR>the CAC gives preference (in call admission) to high priority calls, the=
n
<BR>the proportion of high level calls will increase, so the "pain" (packet
<BR>dropping) will be spread over &nbsp;fewer (low priority) calls.</BLOCKQU=
OTE>
<BR>
<BR>
<BR>
<BR>[MAP] It is essential that CAC gives preference to high priority calls i=
n order for MLEF to work properly. I presume any network would set a limit o=
n how many priority calls could exist. If all started at the exact same mome=
nt, then there would be significant, temporary "pain" on the existing normal=
 calls. But preemption is also a "pain". With appropriate assumptions about=20=
the rate at which high priority calls will "suddenly" start and limits on ho=
w many are allowes, I believe the "pain" inflicted on the low priority calls=
 can be bounded. It's under control of the network administrator to set the=20=
limits.
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<BR>Is this limit that the CAC bases its decision on a limit at the source
<BR>(regardless of where the calls are going), or per source-destination pai=
r,
<BR>or for a single link?
<BR></BLOCKQUOTE>
<BR>
<BR>
<BR>
<BR>[MAP] To be meaningful for VoIP (even without Assured Service or MLEF) i=
t needs to be per single link (since that's where congestion can occur) but=20=
the decision must affect the source (prevent a source from setting up a new=20=
call). I'd like to see this issue discussed and solved separately from Assur=
ed Service, since it is still required without Assured Service.
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Just trying to understand.
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>[MAP] Thanks for the question. I'm trying to take all these questions an=
d work them into a better description for a draft of how MLEF and CAC work t=
ogether.
<BR>
<BR>Mike
<BR>
<BR></FONT></HTML>

--part1_fb.4aefa217.2cf665f1_boundary--

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



From exim@www1.ietf.org  Wed Nov 26 16:48:19 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29501
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 16:48: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 1AP7Vy-0004tq-Ud
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 16:48:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQLm2d4018828
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 16:48:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7Vy-0004tb-R3
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 16:48:02 -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 QAA29485
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 16:47:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7Vw-0005Jp-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 16:48:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7Vw-0005Jm-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 16:48:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7Vx-0004st-76; Wed, 26 Nov 2003 16:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7V1-0004sP-LZ
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 16:47:03 -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 QAA29465
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 16:46:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7Uz-0005JB-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 16:47:01 -0500
Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7Uz-0005J5-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 16:47:01 -0500
Received: from no.name.available by [140.32.132.66]
          via smtpd (for [132.151.6.1]) with ESMTP; Wed, 26 Nov 2003 13:43:32 -0800
Received: from ro178-234.ro.nps.navy.mil ([131.120.178.234]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 26 Nov 2003 13:46:55 -0800
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
From: Rex Buddenberg <budden@nps.navy.mil>
To: Mpierce1@aol.com
Cc: jmpolk@cisco.com, steves@shentel.net, jgunn@ix.netcom.com,
        carlberg@g11.org.uk, ieprep@ietf.org
In-Reply-To: <c6.258a84c4.2cf66474@aol.com>
References: <c6.258a84c4.2cf66474@aol.com>
Content-Type: text/plain
Message-Id: <1069883215.3824.66.camel@ro178-234.ro.nps.navy.mil>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 26 Nov 2003 13:46:55 -0800
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2003 21:46:55.0548 (UTC) FILETIME=[CF620FC0:01C3B466]
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Wed, 2003-11-26 at 12:17, Mpierce1@aol.com wrote:
...
> 
> The current GSCR was written for circuit mode. Unless we get it
> changed, it will apply to packet mode (even when it doesn't always
> make sense). This is one of the areas we are trying to change, so it
> correctly takes into account the advantages of using packet. 
...


This whole conversation appears to be predicated on some tacit and false
assumptions.

The principal assumption seems to be that the entire capacity of a hop
is taken up with VOICE conversations so that the solution to
oversubscription is to shed some of those VOICE conversations.  

If you come to the conversation with a bellhead mentality, then we can
probably read up on Erlangs and reach much the same conclusion that the
circuit switch world reached years ago.


If you have a priority voice conversation and experience congestion, it
would seem to me that we would want to bump something other than other
voice conversations:
	- anything file transfer (incl e-mail enclosures) with .ppt in the file
label.  The content:bit-bloat ratio there is terrible to the extent that
I'm calling powerpoint a virus these days.
	- cut back a VTC to voice only.  The psychologists tell us that a
talking-head VTC has visual cues that we use for about 5-10 minutes;
after that we might as well turn the video off and just leave the
audio.  The problem here is that we can't know by looking at port
numbers whether someone has turned the camera around and is sharing view
of a crime scene
	- filter out any ftp-based operating system installs (they can wait). 
Only picking on this example because I did it this morning.
	What we have to be careful not to do is filter out things that are
higher priority than the priority voice conversation.  LSAs (router link
state announcements, necessary to keep the network converged and
functioning) is one example.  


-- 
b


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



From exim@www1.ietf.org  Wed Nov 26 17:15:48 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00327
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 17:15:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7wa-0006LT-Ub
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 17:15:32 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQMFWgW024381
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 17:15:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7wa-0006L9-NL
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 17:15:32 -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 RAA00240
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 17:15:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7wY-0005dS-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 17:15:30 -0500
Received: from manatick.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7wX-0005cw-02
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 17:15:29 -0500
Received: from [132.151.6.22] (helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1AP7nO-00084K-Vc
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 17:06:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7nM-0005jY-Oa; Wed, 26 Nov 2003 17:06:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7mU-0005iC-NT
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 17:05:06 -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 RAA00021
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 17:04:51 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7mS-0005YM-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 17:05:04 -0500
Received: from imo-d03.mx.aol.com ([205.188.157.35])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7mR-0005Y8-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 17:05:04 -0500
Received: from Mpierce1@aol.com
	by imo-d03.mx.aol.com (mail_out_v36_r1.1.) id c.168.26f3d15f (4012);
	Wed, 26 Nov 2003 17:04:14 -0500 (EST)
Message-ID: <168.26f3d15f.2cf67d5d@aol.com>
Date: Wed, 26 Nov 2003 17:04:13 EST
Subject: Re: [Ieprep] RE:MLPPoIP - Codecs with error correction
To: jmpolk@cisco.com, carlberg@g11.org.uk, steves@shentel.net
CC: ieprep@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_168.26f3d15f.2cf67d5d_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
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>


--part1_168.26f3d15f.2cf67d5d_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 11/26/2003 12:19:17 PM Eastern Standard Time, 
jmpolk@cisco.com writes:


> >[MAP] I am not aware of any codec that adapts to packet loss by increasing 
> >its transmitted rate.
> 
> Any codec with some form of Packet Loss Correction does this very thing - 
> and a lot of ITU codecs do.
> 
> >I suppose there could be one. Can you give an example?
> 
> Some of these are in their specs,
> some are with proprietary extensions
> 
>          G.729
>          G.711
>          G.723
>          iLBC
>          the list is longer...
> 
> 
[MAP] I think we're talking about two different things. The initial comment 
was about codecs that detect packet loss and then start transmitting higher bit 
rates (forward error correction?) to accomodate the loss. G.729, G.711, G.723 
certainly don't do that. iLBC doesn't, as far as I can tell. It transmits at 
a fixed 13.33 or 15.2 kbit/s (for different packet rates).

Yes, there are Forward Error Correction schemes built into some codecs, but I 
don't know of any that change their operation based on detecting packet loss 
(through some feedback mechanism). They are preconfigured to handle a certain 
amount of loss and transmit a fixed rate. As I said, there may be some, but I 
can't see using them in this environment since they are contrary to the 
principle of backing off on data rate when loss occurs (since loss is primarily 
caused by congestion).

Let me know if there are any that work that way so I can put them on the list 
of codecs not allowed in the DSN.

In a message dated 11/26/2003 11:20:44 AM Eastern Standard Time, 
I.Brown@cs.ucl.ac.uk writes:


> There is a good overview of several Forward Error Correction schemes
> that take such an approach in:
> 
> C. S. Perkins, O. Hodson, and V. Hardman, A Survey of Packet-Loss
> Recovery Techniques for Streaming Audio, IEEE Network Magazine,
> September/October 1998. 
> http://csperkins.org/rat/publications/ErrorCorrection.ps
> 


[MAP] This paper provides an overview of various error correction schemes 
(including FEC), but notes the problem with simply inserting more data to 
counteract the loss caused by congestion. It does not describe any situation (as I 
read it) of changing the data rate in real-time based on detection of loss (and 
cautions against it).

Mike



--part1_168.26f3d15f.2cf67d5d_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>In a message dated 11/26/=
2003 12:19:17 PM Eastern Standard Time, jmpolk@cisco.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">&gt;[MAP] I am not aware of=
 any codec that adapts to packet loss by increasing=20
<BR>&gt;its transmitted rate.
<BR>
<BR>Any codec with some form of Packet Loss Correction does this very thing=20=
-=20
<BR>and a lot of ITU codecs do.
<BR>
<BR>&gt;I suppose there could be one. Can you give an example?
<BR>
<BR>Some of these are in their specs,
<BR>some are with proprietary extensions
<BR>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G.729
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G.711
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G.723
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;iLBC
<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the list is longer...
<BR>
<BR></BLOCKQUOTE>
<BR>[MAP] I think we're talking about two different things. The initial comm=
ent was about codecs that detect packet loss and then start transmitting hig=
her bit rates (forward error correction?) to accomodate the loss. G.729, G.7=
11, G.723 certainly don't do that. iLBC doesn't, as far as I can tell. It tr=
ansmits at a fixed 13.33 or 15.2 kbit/s (for different packet rates).
<BR>
<BR>Yes, there are Forward Error Correction schemes built into some codecs,=20=
but I don't know of any that change their operation based on detecting packe=
t loss (through some feedback mechanism). They are preconfigured to handle a=
 certain amount of loss and transmit a fixed rate. As I said, there may be s=
ome, but I can't see using them in this environment since they are contrary=20=
to the principle of backing off on data rate when loss occurs (since loss is=
 primarily caused by congestion).
<BR>
<BR>Let me know if there are any that work that way so I can put them on the=
 list of codecs not allowed in the DSN.
<BR>
<BR>In a message dated 11/26/2003 11:20:44 AM Eastern Standard Time, I.Brown=
@cs.ucl.ac.uk writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-=
LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">There is a good overview of=
 several Forward Error Correction schemes
<BR>that take such an approach in:
<BR>
<BR>C. S. Perkins, O. Hodson, and V. Hardman, A Survey of Packet-Loss
<BR>Recovery Techniques for Streaming Audio, IEEE Network Magazine,
<BR>September/October 1998.=20
<BR>http://csperkins.org/rat/publications/ErrorCorrection.ps
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0"></BLOCKQUOTE>
<BR></FONT><FONT  COLOR=3D"#000000" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Ar=
ial" LANG=3D"0">
<BR>
<BR>[MAP] This paper provides an overview of various error correction scheme=
s (including FEC), but notes the problem with simply inserting more data to=20=
counteract the loss caused by congestion. It does not describe any situation=
 (as I read it) of changing the data rate in real-time based on detection of=
 loss (and cautions against it).
<BR>
<BR>Mike
<BR>
<BR></FONT></HTML>

--part1_168.26f3d15f.2cf67d5d_boundary--

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



From exim@www1.ietf.org  Wed Nov 26 17:18:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00526
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 17:18: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 1AP7z1-0006cO-A9
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 17:18:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQMI31m025387
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 17:18:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7z1-0006bO-4Q
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 17:18:03 -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 RAA00517
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 17:17:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7yy-0005lC-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 17:18:00 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7yy-0005l6-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 17:18:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7yy-0006aE-Qd; Wed, 26 Nov 2003 17:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AP7xz-0006Y2-Sn
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 17:16:59 -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 RAA00437
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 17:16:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7xx-0005jY-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 17:16:57 -0500
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AP7xx-0005fB-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 17:16:57 -0500
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id 454578C2D2; Wed, 26 Nov 2003 17:16:27 -0500 (EST)
To: budden@nps.navy.mil, Mpierce1@aol.com
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Cc: carlberg@g11.org.uk, ieprep@ietf.org, jgunn@ix.netcom.com,
        jmpolk@cisco.com, steves@shentel.net
In-Reply-To: <1069883215.3824.66.camel@ro178-234.ro.nps.navy.mil>
Message-Id: <20031126221627.454578C2D2@newdev.harvard.edu>
Date: Wed, 26 Nov 2003 17:16:27 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
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>

>         - anything file transfer (incl e-mail enclosures) with .ppt in the file

kinda tricky for a router to figure out if the data stream is a ppt file

Scott

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



From exim@www1.ietf.org  Wed Nov 26 19:47:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06791
	for <ieprep-archive@odin.ietf.org>; Wed, 26 Nov 2003 19:47: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 1APAJD-0007q4-AP
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 19:47:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR0l3e9030128
	for ieprep-archive@odin.ietf.org; Wed, 26 Nov 2003 19:47:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APAJD-0007pr-6N
	for ieprep-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 19:47:03 -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 TAA06782
	for <ieprep-web-archive@ietf.org>; Wed, 26 Nov 2003 19:46:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APAJB-000034-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 19:47:01 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1APAJA-000031-00
	for ieprep-web-archive@ietf.org; Wed, 26 Nov 2003 19:47:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APAJA-0007pC-QC; Wed, 26 Nov 2003 19:47:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1APAIt-0007oT-Pu
	for ieprep@optimus.ietf.org; Wed, 26 Nov 2003 19:46:43 -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 TAA06779
	for <ieprep@ietf.org>; Wed, 26 Nov 2003 19:46:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APAIr-00001b-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 19:46:42 -0500
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx with esmtp (Exim 4.12)
	id 1APAIr-00001S-00
	for ieprep@ietf.org; Wed, 26 Nov 2003 19:46:41 -0500
Received: from Steve (ha96s496.d.shentel.net [204.111.97.240])
	by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id hAR0k5419894;
	Wed, 26 Nov 2003 19:46:06 -0500
From: "Steve Silverman" <steves@shentel.net>
To: "Janet P Gunn" <jgunn6@csc.com>
Cc: "Ken Carlberg" <carlberg@g11.org.uk>, <ieprep@ietf.org>,
        "Janet Gunn" <jgunn@ix.netcom.com>, "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
Date: Wed, 26 Nov 2003 19:46:26 -0500
Message-ID: <CIEELMKPOOAMCIAKANLBIEOLDEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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
In-Reply-To: <OF3830C7DB.2D9B103F-ON85256DEA.005F2907-85256DEA.005F8D66@com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Janet P Gunn [mailto:jgunn6@csc.com]
> Sent: Wednesday, November 26, 2003 12:24 PM
> To: Steve Silverman
> Cc: Ken Carlberg; ieprep@ietf.org; ieprep-admin@ietf.org;
> Janet Gunn;
> James M. Polk
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
>
> "When the voice traffic exceeds the link capacity, the high priority
> calls
> get thru intelligibly. This has been demonstrated."
>
> What happens to the low priority calls?  That is what I am still not
> getting.

Enough packets are dropped from the lowest priority traffic that the
congestion is relieved.
Comments below.
>
> I'd also be interested in the range of conditions for which
> it has been
> demonstrated.
>
> Janet

We had a test setup with multiple voice files and each file could have
a DSCP
associated with it.  The various calls were significantly more than
the bandwidth on the link.
When all were at the same DSCP, as more calls were turned on, the
"important" call became
unintelligible.  By raising the priority of the "important" call, it
stays intelligible as the
rest of the calls are turned on.

This has been demonstrated at DISA.

The quality of the lower priority calls is definitely impacted.  They
are not MOS 4 although
we never did any serious testing.  The requirement for no impact on
lower priority calls
is new to me and appears to me to be impossible.  Since in the CS
world, lower priority calls are terminated,
it always seemed reasonable to me to drop packets from the lower
priority calls. Since in the most common situations,
the number of drops would be small, there would be an acceptable drop
in quality even for the routine traffic.


We had enough voice demand for 30% more than the link had available.

I agree that a thorough testing of the algorithm and its behavior
under varying conditions would be a good idea but unfortunately, DISA
never funded this work.  When the original funding was exhausted and
DISA failed to fund
additional work in this direction, the project was ended.  I am
extremely skeptical that DISA or the DOD can provide
an MLPP-like function over an IP network without something like MLEF.

Steve









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