Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

Fred Baker <fred@cisco.com> Fri, 17 November 2006 02:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktJE-00008l-JX; Thu, 16 Nov 2006 21:18:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GktJD-00007Y-5R; Thu, 16 Nov 2006 21:18:27 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktJ9-0003kE-MD; Thu, 16 Nov 2006 21:18:27 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2006 18:18:21 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAH2ILu5002217; Thu, 16 Nov 2006 18:18:21 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAH2IKin008770; Thu, 16 Nov 2006 18:18:20 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:18:20 -0800
Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:18:20 -0800
In-Reply-To: <200611170002.kAH02rtC065633@workhorse.brookfield.occnc.com>
References: <200611170002.kAH02rtC065633@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: <5512B961-3280-4EBD-8A0B-275AD43358DE@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Date: Thu, 16 Nov 2006 17:23:58 -0800
To: curtis@occnc.com
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 17 Nov 2006 02:18:20.0474 (UTC) FILETIME=[A69111A0:01C709EE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2753; t=1163729901; x=1164593901; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20[Ieprep]=20Re=3A=20WG=20Review=3A=20Recharter=20of=20 Internet=20Emergency=20Preparedness=20(ieprep)=20 |Sender:=20; bh=X+c2kMefwmRUXf+nmzaRtmtCz2BAO5j6yE3nIUlsLDw=; b=F1ls9dMky9Zf4PgWkwZuF45SgVj/3Jeo57gZakjH1x+zWgHP4K+qjj6lXGHl5m427V/DFZ2q 4zg9NKUNiwGU5EerB+f3Uk56SUSfgQQwaDvnVAzlzrrOZL9eesmOmSml;
Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: "Robert G. Cole" <robert.cole@jhuapl.edu>, Pekka Savola <pekkas@netcore.fi>, ieprep@ietf.org, Kimberly King <kimberly.s.king@saic.com>, Brian E Carpenter <brc@zurich.ibm.com>, Scott Bradner <sob@harvard.edu>, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
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

On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
> Preemption in MPLS can be soft preemption (setting aside  
> differences of opinion about how signaling of soft preempt should  
> be done for the moment)...
>
> Even for hard preemption, there is at worst a fall back to IP and  
> reroute...

Those are both options, but IMHO have issues. One can't, for example,  
fall back and reroute to a different path if the bottleneck where  
preemption is occurring is the only path to the destination. Further,  
MPLS is one of many ways we have of building the network. Some of us  
still use IP...

What I have suggested to DoD is simpler. Imagine one defines two  
elastic traffic classes for class 1 and class 2 (whatever DSCP and  
application might be implied). Assign half the capacity to class 1  
and 5% to class 2 (let's presume that the other 45% is taken up with  
other stuff, irrelevant to the present example). In normal use,  
though, presume that one in fact finds 99% class 2 and 1% class 1.

Guess what, class 1 will experience relatively low delay and class 2  
will in fact use the available bandwidth, as our queuing is work- 
conserving. Should suddenly a whole bunch of class 1 show up, it will  
get up to its assigned capacity and class 2 will get squeezed,  
experiencing greater delay and potentially loss momentarily. To class  
2, it will look a lot like a re-route event. Reroute happens.

To my small mind, that has the same characteristics as preemption,  
but does so in a manner that is pretty consistent with elastic  
traffic in the global internet. I can look at the technology, the  
algorithms, and the network, and say what the implications are. So  
define a traffic class (ten if it suits you) for your higher  
precedence traffic.

Other proposals have been offered, like introducing different min- 
thresholds for different preference levels. This has a problem - it's  
not predictable. Let's imagine just for fun that my low precedence  
traffic is already in trouble - I am seeing a 10% drop rate at the  
time the higher precedence traffic shows up [pick your reason]. TCP  
is already, in that case, deep in its back-off behavior, and isn't  
going to back off a whole lot more. What will happen to the higher  
precedence traffic? It will get dropped too. But using two classes,  
fine, I change 10% loss to 80% loss and get the higher precedence  
traffic through with little harm.

Yes, I'm being extreme, but this topic is about the end cases. And  
yes, adding more bandwidth is always helpful. It isn't always an  
option, and under the scenarios in question (in some cases, just say  
"Armageddon") might be pretty difficult to predict in detail.

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