[Ieprep] Re: liason & the 5 priorities

ken carlberg <carlberg@g11.org.uk> Tue, 26 September 2006 15:19 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEiT-0005FB-NR; Tue, 26 Sep 2006 11:19:25 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEiS-0005F1-Nz for ieprep@ietf.org; Tue, 26 Sep 2006 11:19:24 -0400
Received: from athena.hosts.co.uk ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEiQ-0007aI-Ce for ieprep@ietf.org; Tue, 26 Sep 2006 11:19:24 -0400
Received: from [] (helo=[]) by athena.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62) (envelope-from <carlberg@g11.org.uk>) id 1GSEiT-0007xK-KL; Tue, 26 Sep 2006 16:19:26 +0100
In-Reply-To: <200609261543.k8QFhHVo001900@workhorse.brookfield.occnc.com>
References: <200609261543.k8QFhHVo001900@workhorse.brookfield.occnc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <A9CFBFAC-CDBF-40D5-82B8-69C147260C70@g11.org.uk>
Content-Transfer-Encoding: 7bit
From: ken carlberg <carlberg@g11.org.uk>
Date: Tue, 26 Sep 2006 11:19:17 -0400
To: curtis@occnc.com
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -1.4 (-)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: ieprep@ietf.org
Subject: [Ieprep] Re: liason & the 5 priorities
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
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>
Errors-To: ieprep-bounces@ietf.org

> If priority and preemption can be accomplished at the admission level
> (SIP and/or microflow RSVP level) then it may be that policing and the
> existing EF is sufficient.  Its only where insufficient bandwidth is
> allocated and carved into categories and adaptive elastic services are
> carried is something like AF needed.  None of the above existing
> examples fit the latter category.  It would be nice though if one more
> first responder needed to communicate that flow was not blocked but
> service quality for some dropped to a more efficient but slightly less
> clear audio compression.  Currently that is not possible in any of the
> above deployments (afaik).

true.  one effort that may compliment what you are looking for is a  
draft being advanced in TSVWG, involving a proposed extension to  
RSVP.  In the following draft, the appendix presents several  
potential modes of operation, one of which focuses on carefully  
engineered capacity.

there is also a new BoF titled Pre-Congestion Notification (PCN)  
scheduled for San Diego that also touches on what you bring up in  
your last sentence above.  The BoF stems from several related drafts  
discussed in TSVWG including the architecture draft of:

(a cast of thousands :)

along with a problem statement that has been discussed on the PCN list
with updated issues list leading to the meeting

PCN mailing list: https://www1.ietf.org/mailman/listinfo/pcn


Ieprep mailing list