Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt

Michael Menth <menth@informatik.uni-wuerzburg.de> Wed, 20 September 2006 06:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvoF-0004ZX-9o; Wed, 20 Sep 2006 02:43:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvoE-0004ZS-4n for pcn@ietf.org; Wed, 20 Sep 2006 02:43:50 -0400
Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPvoA-0003vq-Bh for pcn@ietf.org; Wed, 20 Sep 2006 02:43:50 -0400
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 851801405; Wed, 20 Sep 2006 08:43:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 78F481287; Wed, 20 Sep 2006 08:43:41 +0200 (CEST)
Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 55EF8119A; Wed, 20 Sep 2006 08:43:41 +0200 (CEST)
Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id k8K6hfs15478; Wed, 20 Sep 2006 08:43:41 +0200
Received: from [132.187.106.123] (win3123.informatik.uni-wuerzburg.de [132.187.106.123]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 9FFDA6F58E; Wed, 20 Sep 2006 08:42:32 +0200 (CEST)
Message-ID: <4510E339.6030607@informatik.uni-wuerzburg.de>
Date: Wed, 20 Sep 2006 08:44:09 +0200
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: "Anna Charny (acharny)" <acharny@cisco.com>
Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt
References: <BABC859E6D0B9A4D8448CC7F41CD2B07026A1012@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B07026A1012@xmb-rtp-203.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
List-Id: Pre-Congestion Notification Discussion List <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org

Dear Anna,
> After I wrote this, I read the draft about the markers:
> http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt
> The suggested algorithm implements the preemption marker in fact in such
> a way that it respects only non-preemption-marked packets for the
> measurement process. This is a requirement which should also be
> mentioned in this draft.
>
> 	[Anna] I believe that it is understood in the approaches that
> were 	considered for preemption that router meters the packet
> aggregates 	which have not already been preemption-marked.  Need to
> go through 	various drafts to make sure this is clear.  But again,
> one of the 	issues her is whether in fact there is consensus that
> this is a 	behaviour that is a MUST (and hence needs to be
> standardized) or 	whether this is just a good thing to have (my
> personal view here is 	that it does need to be standardized, but this
> is again an issue to 	reach consensus on).
>
>
> 7) Section 5.5
>
> Another potential solution: add the declared rate to the SAR at the
> ingress gateway as long as new flows send hardly any traffic. This
> information must be obtained from the corresponding policers which are
> also under the control of the ingress gateway. Or add it for an initial
> period of e.g. 10 s?
>
>        [Anna]Just to understand what you mean: this is a proposal to
> solve 	 which aspect of the problem?
>   
This proposal tries to cope with flash crowds, i.e. with many almost 
simultaneous admission requests. The problem is that the AC can respect 
the impact of  newly admitted flows only after some time when their 
typical sent rate influences the admission marking in the routers. I 
think that there should be a mechanism to find out the minimum rate 
between two border routers that is still admissible. The sum of the 
overall declared rates of new flows should not consume more than this 
rate. A flow is new as long as its typical rate has not yet hat an 
impact on the packet marking, and to keep things simple, for an initial 
time of maybe 10 s.
> 9) Section 5.7.4
> Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for
> Diffserv-aware MPLS Traffic Engineering (and other models for that
> objective)
>          [Anna] Not sure what point you are trying to make?
>   
I'd like to say that some of the nomenclature in this context can maybe 
be reused.
>
> 11) Section 6.8 *NEW*
> Other Network Admission Control Approaches Link admission control (LAC)
> describes how admission control (AC) can be done on a single link and
> comprises, e.g., the calculation of effective bandwidths which may be
> the base for a parameter-based AC.
> In contrast, network AC (NAC) describes how AC can be done for a network
> and focuses on the locations from which data is gathered for the
> admission decision. Most approaches implement a link budget based NAC
> (LB NAC) where each link has a certain AC-budget. RSVP works according
> to that principle,
>  but also the new concept admits additional flows as long as each link
> on
>  the new flow's path still has resources available. The border-to-border
>
> budget based NAC (BBB NAC) pre-configures an AC budget for all
> border-to-
> border relationships (=CL-region-aggregates) and if this capacity budget
>  is exhausted, new flows are rejected. The TCA-based admission control 
> which is associated with the DiffServ architecture implements an ingress
>
> budget based NAC (IB NAC). These basically different concepts have 
> different flexibility and efficiency with regard to the use of link 
> bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the
>  budgets in such a way that the network will not be congested after 
> rerouting due to a failure. The efficiency of the approaches is
> different
>  with and without such resilient requirements.
>
> [NAC-a] Michael Menth: "Efficient Admission Control and Routing in
> Resilient Communication Networks", PhD thesis, July 2004,
> http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment
> h04.pdf
>
>
> [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl
> Schrodi: "Resilient Network Admission Control", currently under
> submission.
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-
> 3.pdf
>
>     	[Anna] Thanks for pointing out this work. We have had some 
> 	experience 	in estimating bandwidth requirements of
> mechanisms 
> 	similar to the ones you propose in the above paper, and found
> that 
> 	the bandwidth requirements needed for resiliency depend quite 
> 	dramatically on the assumption on which failures one protects 
> 	against (just link or node, or shared risk link groups (SRLGs),
> and 
> 	are also rather topology dependent.  We found that for some real
>
> 	networks capacity requirements nneeded to provide resiliency to 
> 	local failures in the manner you disuss in the above paper is
> quite 
> 	high.  Some of the refereces in various pcn drafts also point to
>
> 	similar conclusions albeit the circumstances are slighly
> different 
> 	that those you consider.  
This is right. The required (backup) capacity depends on many aspects: 
the routing, the traffic matrix, the topology, and probably many others. 
However, it also depends on the network admission control (NAC) approach 
that is used and the PCN concept implements a specific NAC approach. 
Therefore, it is of interest how its efficiency relates, e.g., to the 
one of the TCA approach. And this is done in my PhD thesis and the cited 
paper. Apart from the TCA approach, there are several other basic NAC 
approaches that are compared.
> This sometimes 	extensive
> capacity needed 	
> 	for resiliency seems in fact to motivate 	a lot of the pcn
> work, 	
> 	which tries to address the "normal"  operating conditions and 	
> 	protect against unexpected (and/or expensive to protect
> otherwise)
> 	failures in a graceful manner.
Hm? - Anyway. I think [IyBh03] provides the best motivation for 
resilient admission control as it points out that "link overload is 
rare, and when it occurs, 80% of the time it is caused due to link 
failures" (see abstract). Conventional AC does not consider a safety 
margin to accommodate redirected traffic. Therefore, failures will still 
lead to overload and therefore conventional AC mostly doesn't work when 
it is needed.  This concludes that AC must be resilient to failures, 
anything else does not make sense.

[IyBh03] S. Iyer, S. Bhattacharyya, N. Taft, and C. Diot: "An Approach 
to Alleviate Link Overload as Observed on an IP Backbone", in 
proceedings of IEEE Infocom, San Francisco, CA, USA, April 2003
http://klamath.stanford.edu/~sundaes/Papers/infocom2003.pdf

>  
>
>
> 13) Section 11.3
> By running the EWMA whenever a new packet for a specific
> CL-region-aggregate arrives makes the aging process depending on the
> arrival rate of the traffic. As a consequence, there is the problem with
> the stale information. This can be done in a better way, e.g.
> by using the time-exponentially weighted moving average (TEWMA) [TEWMA].
>
> [TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of
> Rate Measurements", in proceedings of GI/ITG Conference on Measuring,
> Modelling and Evaluation of Computer and Communication Systems (MMB),
> Dresden, Germany, September 2004
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf
>
> If the TEWMA seems too complex (it requires the calculation of an
> exponential function), a rate of the admission- or preemption-marked
> packets can be calculated based on a, e.g., 20 ms interval and used as
> input for a conventional EWMA.
>
>       [Anna] Thanks - will look into the reference.  Again, from the
>  	standartisation point one needs to decide how much detail does
> one 
> 	have to standardize and in fact at the moment the question of 
> 	whether anything that the edges do must be standardized at all
> is an
>  	open question.  This would be something the BoF/WG would adress
> I 
> 	presume (assuming of course the WG is created)
>   
Any moving average mechanism has some "memory". For example, if new 
samples get a high weight relative to the existing average, the memory 
is short. Both the averaging algorithm and the length of the 
corresponding memory at the egress routers may be chosen differently in 
different networks. They have both an impact on the reaction speed of 
the AC which should carefully be investigated. The same holds for the 
measurement algorithms and their parameters for the markers.

Best wishes,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn


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