[Ieprep] Question about RSVP based preemption
"Eagan, Christopher" <christopher.eagan@lmco.com> Mon, 18 October 2004 13:30 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15604 for <ieprep-web-archive@ietf.org>; Mon, 18 Oct 2004 09:30:12 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXmX-0000B6-9o for ieprep-web-archive@ietf.org; Mon, 18 Oct 2004 09:42:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXVd-000078-Uy; Mon, 18 Oct 2004 09:25:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXQE-0007Px-HX for ieprep@megatron.ietf.org; Mon, 18 Oct 2004 09:19:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14820 for <ieprep@ietf.org>; Mon, 18 Oct 2004 09:19:33 -0400 (EDT)
Received: from mailgw3a.lmco.com ([192.35.35.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXc7-0008O0-CB for ieprep@ietf.org; Mon, 18 Oct 2004 09:31:58 -0400
Received: from emss09g01.ems.lmco.com (relay6.ems.lmco.com [166.17.13.59]) by mailgw3a.lmco.com (8.12.10/8.12.10) with ESMTP id i9IDJFk1016660; Mon, 18 Oct 2004 09:19:23 -0400 (EDT)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30875) id <0I5S00L017O3B9@lmco.com>; Mon, 18 Oct 2004 09:19:15 -0400 (EDT)
Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30875) with ESMTP id <0I5S0098T7O2IM@lmco.com>; Mon, 18 Oct 2004 09:19:15 -0400 (EDT)
Received: from EMSS09M02.us.lmco.com ([158.183.26.5]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 09:19:14 -0400
Date: Mon, 18 Oct 2004 09:19:14 -0400
From: "Eagan, Christopher" <christopher.eagan@lmco.com>
Subject: [Ieprep] Question about RSVP based preemption
To: ieprep@ietf.org
Message-id: <CC0012A5C59D1C4AB6898D5355B3EA640D4532@emss09m02.us.lmco.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
Thread-Topic: [Ieprep] Question about RSVP based preemption
Thread-Index: AcS1FRA5xsN7X8QkRYy732cJI6lwrA==
content-class: urn:content-classes:message
X-OriginalArrivalTime: 18 Oct 2004 13:19:14.0654 (UTC) FILETIME=[105ABFE0:01C4B515]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: "James M. Polk" <jmpolk@cisco.com>, fred@cisco.com
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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Regarding the example in Appendix A of draft-baker-tsvwg-mlpp-that-works-02.txt, it seems that RSVP based preemption may unnecessarily drop low priority calls in cases were the preempting call is not completed to the original callee - in cases where the callee's UAS is alive and well but the call for some reason goes unanswered and is forwarded to an alternate party or a global attendant somewhere else on the network. If you have a network snippet like...... Alt Party R Talker | | | | F Caller-----N---------------N------F Callee | | R Talker Where the 2 "R Talkers" are on an existing Routine Call, N are routers where RSVP preemptions may occur, and F Caller / F Callee are participants in a Flash call being set up (and assuming that the current b/w requirements are such that the F's cannot make their call w/o preempting the R's). >From the example in the draft, it looks like the R's will receive the RSVP preemption messages before F Callee's phone rings to prevent dead rings. Is this correct? Is yes, and F Callee doesn't answer the phone for any reason, F Caller will be redirected to F Callee's Alternate Party. In this case the Routine call is unnecessarily preempted. Is my understanding of how this works correct? Is it possible for the RSVP preempting routers to delay the tear down of low priority calls until the high priority stream actually starts? I.e. Mark the low priority stream for preemption, but don't actually tear it down until the b/w is at capacity. Thanks, Chris Christopher Eagan Software Engineer Lockheed Martin, IS&S (301) 240 - 6328 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] Question about RSVP based preemption Eagan, Christopher
- Re: [Ieprep] Question about RSVP based preemption Fred Baker