From pcn-bounces@ietf.org Mon Oct 02 09:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNu6-0004oz-BE; Mon, 02 Oct 2006 09:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNu5-0004ou-63 for pcn@ietf.org; Mon, 02 Oct 2006 09:32:17 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNu3-00029t-Od for pcn@ietf.org; Mon, 02 Oct 2006 09:32:17 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92DWDx14424 for ; Mon, 2 Oct 2006 09:32:13 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 09:32:05 -0400 Message-Id: <6.2.5.6.0.20061002092948.033b66b0@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 Oct 2006 09:32:04 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 02 Oct 2006 13:32:05.0359 (UTC) FILETIME=[26AC7FF0:01C6E627] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [PCN] Fwd: 67th IETF - DRAFT Meeting Agenda X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Please Notice PCN BOF is NOT in the IETF Agenda dated Oct 2, 2006 00:14:26 -0400 yet. Just want to save some of your time looking for it (as I have done). :) -- Kwok -- >To: IETF Announcement list >Cc: >From: IETF Secretariat >Date: Mon, 02 Oct 2006 00:14:26 -0400 >X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed >Subject: 67th IETF - DRAFT Meeting Agenda >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >X-Spam-Score: 0.1 >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ertph000.nortel.com >X-Spam-Tests: FORGED_RCVD_HELO=0.05 >X-DNSBL-Score: -20 >X-DNSBL-Servers: bl.nortel.com >X-SMTP-HELO: megatron.ietf.org >X-SMTP-MAIL-FROM: ietf-announce-bounces@ietf.org >X-SMTP-RCPT-TO: >khchan@nortel.com,audet@nortel.com,rninan@nortel.com,mchen@nortel.com,mary.barnes@nortel.com,jykchan@nortel.com,jseligso@nortel.com,gkenward@nortel.com >X-SMTP-PEER-INFO: odin.ietf.org [156.154.16.145] >X-OriginalArrivalTime: 02 Oct 2006 04:23:56.0001 (UTC) >FILETIME=[9316BD10:01C6E5DA] > >The DRAFT agenda for the 67th IETF Meeting can be found at: >http://www.ietf.org/meetings/67-IETF.html > >Please note that the agenda is in draft form and is subject to change >substantially before the final agenda is published on Monday, October 16. > >IETF Secretariat > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 02 10:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOUh-00057j-Vb; Mon, 02 Oct 2006 10:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOUg-00057e-Ns for pcn@ietf.org; Mon, 02 Oct 2006 10:10:06 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOUX-0006pn-W4 for pcn@ietf.org; Mon, 02 Oct 2006 10:10:06 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 15:09:57 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 15:09:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Oct 2006 15:09:55 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD13@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues A1, A2, A3, A4 Thread-Index: AcbmLG/WigOHnm5QRWyfx4HM9/h/cw== From: To: X-OriginalArrivalTime: 02 Oct 2006 14:09:55.0988 (UTC) FILETIME=[7012FD40:01C6E62C] X-Spam-Score: 0.6 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Subject: [PCN] Issues A1, A2, A3, A4 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1691480925==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1691480925== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E62C.6FE1DFFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt=20 =20 A1 "PCN-Region Term" Issue=20 Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement.=20 =20 A2 "PIN Term" Issue=20 Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement =20 =20 A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node =20 Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes.=20 =20 I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far.=20 =20 PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested.=20 =20 PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region.=20 =20 I favour PCN Edge Node, and also ok with PCN Boundary / Border Node =20 =20 A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? =20 Best wishes phil ------_=_NextPart_001_01C6E62C.6FE1DFFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Thought I’d try to close a few more of =
the Issues – covering the Issues “A. Terminology =
Issues” listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
A1      =
"PCN-Region Term" Issue 
Should =
the region running the PCN mechanism be called the PCN-Region or =
PCN-Domain?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 RFC2998 =
supports use of Region, RFC2474 supports use of =
Domain.
Personally I don’t mind, happy to stick =
with PCN-region as currently used in draft-chan-problem-statement. =

 
A2      "PIN =
Term" Issue 
Should we =
use the terminology PCN Interior Node or PCN Intermediate Node =
(function)?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 RFC2475 =
supports use of PCN Interior Node
Personally I slightly prefer PCN Interior =
Node, though I don’t mind much. So happy to stick with PCN =
Interior Node as currently used in =
draft-chan-problem-statement
 
 
A3      "PEN =
Term" Issue
Should we =
use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node =
or PCN Border Node or PCN Gateway Node =
(function)?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 The term =
currently used in draft-chan-problem-statement is PCN End =
Node
 
Personally I don’t like the term PCN =
End Node – the problem is that it will probably get shortened to =
end node (already seen this happening on the list). I think this will =
get confusing as [1] the innocent may think it means ‘end =
host’; [2] the deployment models will probably show how PCN fits =
into the ‘big picture’ of end-to-end QoS, in which case =
we’d have both end hosts & PCN End Nodes. =

 
I also =
think PCN Gateway Node (function) could be slightly confusing. The =
actual physical node where the “PCN End Node” function sits =
is typically the PCN-region’s gateway node, but it could in some =
deployment situations be an end host, if the PCN-region extends out that =
far. 
 
PCN =
Boundary Node would be consistent with rfc2474 =
terminology.
PCN =
Border Node is a similar possibility that Michael has suggested. =

 
PCN Edge =
Node allows us to continue to use the nice acronym PEN, with its hint of =
‘penning in’ the PCN-region. 
 
I favour =
PCN Edge Node, and also ok with PCN Boundary / Border =
Node
 
=

 

A4    “Pre-emption Marking = term” Issue

Pre-emption Marking may = seem to indicate the requirement of pre-empting existing flows/sessions to allow = additional new flows/sessions to be admitted.  This scenario is not allowed in = some markets due to regulations.  Should a better term be used instead = of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network?

Michael suggested “excess traffic mark” – what do you reckon?

 

Best wishes

phil

=00 ------_=_NextPart_001_01C6E62C.6FE1DFFF-- --===============1691480925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1691480925==-- From pcn-bounces@ietf.org Mon Oct 02 10:43:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP0c-0005xO-Bx; Mon, 02 Oct 2006 10:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP0a-0005nQ-RQ for pcn@ietf.org; Mon, 02 Oct 2006 10:43:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP0Z-0002KG-8e for pcn@ietf.org; Mon, 02 Oct 2006 10:43:04 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92Eh0e12988; Mon, 2 Oct 2006 10:43:00 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:42:56 -0400 Message-Id: <6.2.5.6.0.20061002103356.033369b8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 Oct 2006 10:42:56 -0400 To: From: "Kwok-Ho Chan" Subject: Re: [PCN] Issue A4 Preemption Marking Term In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD13@E03MVZ1-UKDY.domain 1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD13@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2006 14:42:56.0418 (UTC) FILETIME=[0C80A020:01C6E631] X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1945023492==" Errors-To: pcn-bounces@ietf.org --===============1945023492== Content-Type: multipart/alternative; boundary="=====================_8200742==.ALT" --=====================_8200742==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Some other suggestions related to Issue A4 of: >A4 =93Pre-emption Marking term=94 Issue > >Pre-emption Marking may seem to indicate the=20 >requirement of pre-empting existing=20 >flows/sessions to allow additional new=20 >flows/sessions to be admitted. This scenario is=20 >not allowed in some markets due to=20 >regulations. Should a better term be used=20 >instead of Pre-emption Marking to indicate the=20 >need to reduce the offered traffic load to the=20 >congested portions of the network? > >Michael suggested =93excess traffic mark=94 =96 what do you reckon? How about the terms of: "Admissible Rate Marking" for the marking=20 indication of exceeding the "Admissible Rate" and "Supportable Rate Marking" for the marking=20 indication of exceeding the "Supportable Rate" ? It is then up to the Policy Decision to take the=20 appropriate action when the rate of traffic is not "Supportable" anymore. With Preemption being=20 one of the possible policy decision actions. Thanks! -- Kwok -- At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" > > >Thought I=92d try to close a few more of the=20 >Issues =96 covering the Issues =93A. Terminology=20 >Issues=94 listed at=20 >http:/= /standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt=20 > > >A1 "PCN-Region Term" Issue >Should the region running the PCN mechanism be=20 >called the PCN-Region or PCN-Domain? > Reference: draft-chan-problem-statement-00.txt section 2.1. > RFC2998 supports use of Region, RFC2474 supports use of Domain. >Personally I don=92t mind, happy to stick with=20 >PCN-region as currently used in draft-chan-problem-statement. > >A2 "PIN Term" Issue >Should we use the terminology PCN Interior Node=20 >or PCN Intermediate Node (function)? > Reference: draft-chan-problem-statement-00.txt section 2.1. > RFC2475 supports use of PCN Interior Node >Personally I slightly prefer PCN Interior Node,=20 >though I don=92t mind much. So happy to stick with=20 >PCN Interior Node as currently used in draft-chan-problem-statement > > >A3 "PEN Term" Issue >Should we use the terminology PCN End Node or=20 >PCN Edge Node or PCN Boundary Node or PCN Border=20 >Node or PCN Gateway Node (function)? > Reference: draft-chan-problem-statement-00.txt section 2.1. > The term currently used in draft-chan-problem-statement is PCN End Node > >Personally I don=92t like the term PCN End Node =96=20 >the problem is that it will probably get=20 >shortened to end node (already seen this=20 >happening on the list). I think this will get=20 >confusing as [1] the innocent may think it means=20 >=91end host=92; [2] the deployment models will=20 >probably show how PCN fits into the =91big=20 >picture=92 of end-to-end QoS, in which case we=92d=20 >have both end hosts & PCN End Nodes. > >I also think PCN Gateway Node (function) could=20 >be slightly confusing. The actual physical node=20 >where the =93PCN End Node=94 function sits is=20 >typically the PCN-region=92s gateway node, but it=20 >could in some deployment situations be an end=20 >host, if the PCN-region extends out that far. > >PCN Boundary Node would be consistent with rfc2474 terminology. >PCN Border Node is a similar possibility that Michael has suggested. > >PCN Edge Node allows us to continue to use the=20 >nice acronym PEN, with its hint of =91penning in=92 the PCN-region. > >I favour PCN Edge Node, and also ok with PCN Boundary / Border Node > >A4 =93Pre-emption Marking term=94 Issue >Pre-emption Marking may seem to indicate the=20 >requirement of pre-empting existing=20 >flows/sessions to allow additional new=20 >flows/sessions to be admitted. This scenario is=20 >not allowed in some markets due to=20 >regulations. Should a better term be used=20 >instead of Pre-emption Marking to indicate the=20 >need to reduce the offered traffic load to the=20 >congested portions of the network? >Michael suggested =93excess traffic mark=94 =96 what do you reckon? > >Best wishes >phil >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn --=====================_8200742==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some other suggestions related to Issue A4 of:

A4    =93Pre-emption Marking term=94 Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted.  This scenario is not allowed in some markets due to regulations.  Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network?

Michael suggested =93excess traffic mark=94 =96 what do you reckon?

How about the terms of:
"Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate"
and
"Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ?

It is then up to the Policy Decision to take the appropriate action when the rate of traffic is
not "Supportable" anymore.  With Preemption being one of the possible policy decision actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"


Thought I=92d try to close=
 a
few more of the Issues =96 covering the Issues =93A. Terminology Issues=94
listed at

http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt


 


A1      "PCN-Region Term" Issue


Should the region running
the PCN mechanism be called the PCN-Region or
PCN-Domain?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 RFC2998 supports use
of Region, RFC2474 supports use of
Domain.

Personally I don=92t mind,
happy to stick with PCN-region as currently used in
draft-chan-problem-statement.


 


A2      "PIN Term" Issue


Should we use the
terminology PCN Interior Node or PCN Intermediate Node
(function)?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 RFC2475 supports use
of PCN Interior
Node

Personally I slightly
prefer PCN Interior Node, though I don=92t mind much. So happy to stick
with PCN Interior Node as currently used in
draft-chan-problem-statement

 

 


A3      "PEN Term"
Issue

Should we use the
terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN
Border Node or PCN Gateway Node
(function)?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 The term currently
used in draft-chan-problem-statement is PCN End
Node

 

Personally I don=92t like =
the
term PCN End Node =96 the problem is that it will probably get shortened to
end node (already seen this happening on the list). I think this will get
confusing as [1] the innocent may think it means =91end host=92; [2] the
deployment models will probably show how PCN fits into the =91big picture=92
of end-to-end QoS, in which case we=92d have both end hosts & PCN End
Nodes. 

 

I also think PCN Gateway
Node (function) could be slightly confusing. The actual physical node
where the =93PCN End Node=94 function sits is typically the PCN-region=92s
gateway node, but it could in some deployment situations be an end host,
if the PCN-region extends out that far.


 

PCN Boundary Node would be
consistent with rfc2474
terminology.

PCN Border Node is a
similar possibility that Michael has suggested.


 

PCN Edge Node allows us to
continue to use the nice acronym PEN, with its hint of =91penning in=92 the
PCN-region. 

 

I favour PCN Edge Node, an=
d
also ok with PCN Boundary / Border
Node

 
 
A4    =93Pre-emption Marking term=94 Issue
Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted.  This scenario is not allowed in some markets due to regulations.  Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network?
Michael suggested =93excess traffic mark=94 =96 what do you reckon?
 
Best wishes
phil
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--=====================_8200742==.ALT-- --===============1945023492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1945023492==-- From pcn-bounces@ietf.org Mon Oct 02 10:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP8a-000676-Pa; Mon, 02 Oct 2006 10:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP8Y-00062U-Np for pcn@ietf.org; Mon, 02 Oct 2006 10:51:18 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP8R-0002zW-CR for pcn@ietf.org; Mon, 02 Oct 2006 10:51:18 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 15:51:10 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 15:51:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt Date: Mon, 2 Oct 2006 15:51:09 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD14@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000301c6e20e$6afd1bf0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt Thread-Index: Acbh/ydd0EJEyVWoQIiGJfjYiegBswADrfnQAQfEgZA= From: To: , X-OriginalArrivalTime: 02 Oct 2006 14:51:09.0782 (UTC) FILETIME=[3291FF60:01C6E632] X-Spam-Score: 0.2 (/) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Just a quick follow-up. There are 3 bit-rates of interest on a link 1. configured-admission-rate (or - Michael's proposal - admissible link rate) 2. configured-pre-emption-rate (or - Michael's proposal - supportable link rate) 3. line rate - the maximum possible rate available to packets of the traffic class using the PCN mechanism (this might not be the bit-rate of the router interface, since there might be some capacity assigned eg for control/management traffic) the first two (at least) are up to the operator to set. If the traffic rate on a link exceeds (3) line rate, the pkts have to be queued / dropped. However, when this happens then all flows through the congested router are affected. Hence the idea of the configured-pre-emption-rate (which is set a bit less than the line rate) - this enables a few flows to be pre-empted, hence the line rate is not exceeded and so all the remaining flows get their full QoS. However, pre-emption is probably something an operator will want to do as rarely as possible. Hence the idea of a configured-admission-rate: by doing admission control the chances of a link exceeding the configured-pre-emption-rate or line rate can be reduced. Setting the 3 rates relative to each other is (as stated below) basically up to the operator. Their choice could depend on things like=20 - what the link bandwidth is - what the typical flow bandwidth is expected to be - how variable rate are the flows expected to be - how strongly does the operator not want to pre-empt existing flows & how strongly to admit new flows - etc as you say, simulations to explore the trade-offs etc here would be very good.=20 best wishes phil/=20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 27 September 2006 09:25 To: menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: RE: ProblemStatement Issue B.9:Call Preemption NotAllowedIssue.Used to be Re: [PCN]draft-chan-pcn-problem-statement-00.txt Hi Michael I think that you are right, we need to somehow provide some quantification=20 of the overprovisioning, which depends on: 1) the time until the calls are admtted: If the response time is long, the overprovisioning is substantial. 2) the statistics of the aggregated traffic. It will work well with traffic that have a nice average behaviour. 3) mass-call events that usually happends in telefony networks. If the number of calls suddenly increases, the PCN will not have time to block the calls. 4) response time for the measurement function. Best Regards, Georgios -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: woensdag 27 september 2006 8:36 To: Geib, Ruediger Cc: pcn@ietf.org Subject: Re: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue.Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt Hi Ruediger, Stuart, I think that the question is the following: How large should the admissible and supportable link rates be that QoS can be maintained in spite of (1) bursty traffic (2) admission errors due to the measurement-based nature of the AC (flash crowds) (3) redirected traffic due to likely network outages like single link failures The answer depends on the traffic model and the link capacity. I think this defines plenty of work for academic parametric studies to give guidelines for operators. This is a feasible thing to do. We addressed issue (3) in previous work for a different NAC approach. If the network is configured to copy with (1)-(3), QoS is quite well protected. And if all the assumptions for (1)-(3) fail that were made for the configuration, then preemption kicks in, but only then. Best wishes, Michael Geib, Ruediger wrote: > Stuart, > > if "pre-congestion level" is the configured-admission-rate, then=20 > "leaving enough excess capacity" is, at least from my point of view, a > planning task. PCN should make sure that vendors have sufficient=20 > guidance to implement the knobs allowing network operators to fulfill=20 > this task. > > As I mentioned, what a "relatively high (CL load) level"=20 > on a particular PCN link is, should for his network entirely be the=20 > decision of a carrier. As long as the SLA's defining the CL service=20 > commercially are kept, it is nobody else' matter how it is produced. > > Regards, > > Rudiger > > |-----Original Message----- > |From: GOLDMAN, STUART O (STUART) [mailto:sgoldman@lucent.com] > |Sent: Tuesday, September 26, 2006 6:36 PM > |To: Geib, Rudiger; khchan@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > |AllowedIssue. Used to be Re: [PCN]=20 > |draft-chan-pcn-problem-statement-00.txt > | > | > |Ruediqer, > | > |I think my mental picture is close to your view of having the two=20 > |level settings. I would hope that the pre-congestion level while=20 > |relatively high still leaves enough excess capacity so that the=20 > |actions taken are more likely to prevent the second level from actually being crossed. > | > |Stuart Goldman > |Lucent Technologies > |sgoldman@lucent.com > |602 493 8438 > | > | > |-----Original Message----- > |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |Sent: Tuesday, September 26, 2006 12:29 AM > |To: khchan@nortel.com; GOLDMAN, STUART O (STUART) > |Cc: pcn@ietf.org > |Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > |AllowedIssue. Used to be Re: [PCN]=20 > |draft-chan-pcn-problem-statement-00.txt > | > |Kwok, Stuart, > | > |my take may be a slightly different one. PCN allows to mark packets=20 > |once a settable load level has been reached on a particular link and=20 > |prior to any of these packets being discarded due to the traffic rate > |crossing a second settable rate. > | > |The former of both rates is the admissible link rate or=20 > |configured-admission-rate. The latter is the supportable link rate or > |configured-preemption-rate. My understanding is that PCN doesn't=20 > |specify "service" to more detail then demanding CL like performance=20 > |for admitted traffic. To reach this aim, the preemption-rate must be=20 > |chosen sufficiently bigger than the admission-rate. How the rates are > |set exactly is left to operators and depends on the network planning=20 > |philosophy applied by each of them and the characteristics of the=20 > |traffic being forwarded by PCN. A second condition is that PCN=20 > |traffic should consist of a large number of multiplexed flows whose=20 > |individual peak rate is small as compared to the admission-rate. What > |PCN should do is provide simulation results and measurements prooving > |that the mechanism works under todays "common" load and network=20 > |conditions. > |Giving guidance on operational settings for a variety of networks and > |traffic mixes to me is a research topic, which is out of scope of the > |PCN WG. A BCP may be published, once sufficient "P" is available. > | > |Regards, > | > |Rudiger > | > ||-----Original Message----- > ||From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||Sent: Monday, September 25, 2006 5:30 PM > ||To: GOLDMAN, STUART O (STUART) > ||Cc: pcn@ietf.org; Shahram Davari; ken carlberg > ||Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||AllowedIssue. Used to be Re: [PCN]=20 > ||draft-chan-pcn-problem-statement-00.txt > || > || > ||Stuart: > ||No problem. > ||By "Pre-Congestion", we mean: > ||"if additional IP packet traffic is admitted (into the traffic class > ||handling this traffic), then already admitted traffic (of the same=20 > ||traffic class) will experience degraded QoS. > ||This degraded QoS happens at specific nodes (or diffserv hops) of=20 > ||the end-to-end path because we are working with IP packet network. =20 > ||This degraded QoS may affect the end-to-end service required of the=20 > ||network by the Using Application." > || > ||Of course there are many factors that defines what is (and what is > ||not) acceptable > ||"degraded QoS" and how much additional traffic will cause the=20 > ||degraded QoS to be not acceptable, for example: > ||- the Using Application and the requirements it have on the network. > ||--- hence we are looking at inelastic, interactive, Real-Time use of > ||the network (first). > ||- the ratio of the total shared (by the traffic class) network=20 > ||resource at specific network > || nodes with respect to each admitted traffic flow and each=20 > ||to-be-admitted traffic flow. > || This indicates how each additional traffic flow over some limit=20 > ||will impact already > || admitted traffic flows. In both space and time dimensions. > ||--- hence we are looking into amount of network resource, e.g. size=20 > ||of network pipes. > || We first look at the easier one (we think), large network=20 > ||pipes. Then the harder ones > || of smaller and smaller network pipes. > ||- the characteristic of the traffic flows, for example are they=20 > ||constant bit rate? Or close > || to constant bit rate?, etc. > ||- the promised service to the Using Application. > || On this Issue B.9, we are talking about promised service of NO=20 > ||PREEMPTION > || (but may be with some condition). > || > ||As you indicated, the network resource we are discussing allows=20 > ||provisioning of detection before congestion, before the packet=20 > ||forwarding queues gets backed up. > ||And we want to have some capacity still available (this may be view=20 > ||as one of the ways on HOW we can do this). But you are right that=20 > ||we may need to conserve this head-room capacity, but again depending > ||on for what reasons. > ||Is it because we can not preempt any admitted flows? > ||Is it because we need to handle emergency services? > ||Is it because we need to handle none-constant bit rate traffic? > ||Some other reasons or combinations of them? > || > ||These are still topics of discussions and additional work we hope we > ||can do together in this WG (hopeful result of the PCN BOF). > || > ||Sorry for such a long reply, just want to indicate some of the=20 > ||thinkings I have and working toward/down the path of agreements. > ||Thanks! > ||-- Kwok -- > || > || > ||At 07:34 PM 9/24/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||>Kwok, > ||> > ||>Sorry to have taken so long to respond, but my day job got > |in the way. > ||> > ||>As I understood the topic, we are addressing pre-congestion. In=20 > ||>that light, I assumed that congestion has not yet occurred, but > |that we are > ||>approaching congestion. So, I further assumed that there was > ||still some > ||>capacity available, although this remaining capacity needs to be=20 > ||>conserved as best as possible. > ||> > ||>Am I am the right wavelength? > ||> > ||>Stuart Goldman > ||>Lucent Technologies > ||>sgoldman@lucent.com > ||>602 493 8438 > ||> > ||>-----Original Message----- > ||>From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||>Sent: Wednesday, September 20, 2006 10:58 AM > ||>To: GOLDMAN, STUART O (STUART) > ||>Cc: Kwok-Ho Chan; Shahram Davari; pcn@ietf.org; ken carlberg > ||>Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||>AllowedIssue. Used to be Re: [PCN]=20 > ||>draft-chan-pcn-problem-statement-00.txt > ||> > ||>Stuart: > ||>Preemption is just one of possibly multiple decisions the End Node=20 > ||>function can take. > ||>Hence you are right that there may be other decisions that > |is of value > ||>to the > ||>system as a whole, possibly depending on the deployment evironment. > ||> > ||>These discussions we have so far indicates that we may not > ||want to call > ||>the network information the Interior Nodes are providing as > ||"Preemption > ||>Mark" > ||>indication. > ||> > ||>Hence these discussions are very helpful for our BOF/WG. > ||> > ||>Thanks! > ||>-- Kwok -- > ||> > ||> > ||>At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: > ||> >Kwok-Ho, > ||> >While you seem to have only mentioned preemption, there > ||should be ways > ||> >to recognize a call deserving higher than normal preference > ||and giving > ||> >it that preference to the remaining network resources > ||without having to > ||> >preempt a call in progress. Yes? > ||> > > ||> >Stuart Goldman > ||> >Lucent Technologies > ||> >sgoldman@lucent.com > ||> >602 493 8438 > ||> > > ||> > > ||> >-----Original Message----- > ||> >From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> >Sent: Wednesday, September 20, 2006 8:54 AM > ||> >To: Shahram Davari > ||> >Cc: pcn@ietf.org; ken carlberg > ||> >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not=20 > ||> >AllowedIssue. Used to be Re: [PCN]=20 > ||> >draft-chan-pcn-problem-statement-00.txt > ||> > > ||> >Shahram: > ||> >I totally agree. > ||> >The cell phone network was also jammed during 9/11. > ||> >I was trying to reach my brother who were stuck in the subway > ||> >~2 stops from WTC. > ||> >So I know exactly how this feels like. But I prefer to let the=20 > ||> >Police and Firemen to use this resource to help the general=20 > ||> >public at large. > ||> > > ||> >The question becomes: > ||> >- Does the Emergency Services want to use the same physical=20 > ||> >network as the general public? > ||> >-- If Yes. Then should the problem statement becomes: > ||> > "Some controlled preemption functionality is allowed for=20 > ||> >Emergency purposes in the general > ||> > public integrated (voice, video, data, etc) network. This=20 > ||> >controlled preemption functionality > ||> > needs to be supported by the network mechanisms." > ||> >-- If Yes. Then we will need some guidance and help wrt the=20 > ||> >regulations of the different jurisdictions. > ||> > Also if the different jurisdictions even wants to use the=20 > ||> >same network infrastructure for both > ||> > emergency and public usage purposes. If it is technically > ||>possible. > ||> > > ||> >By this I am not saying a good solution exist or that I am > |promoting > ||> >a specific solution. > ||> >I am just agreeing that this problem needs to be addressed. > ||> >We may end up saying we can not solve this problem as of > |yet. But I > ||> >wish we can solve it. > ||> > > ||> >Regards. > ||> >-- Kwok -- > ||> > > ||> > > ||> >At 09:34 AM 9/20/2006, Shahram Davari wrote: > ||> > >Kwok, > ||> > > > ||> > >Indeed you raised a good subject. The requirements for=20 > ||> > >emergency services should be part of the problem statement, and > ||> > >be > ||dealt with > ||> > >in the proposed solution draft. ITU-T has quite extensive work=20 > ||> > >on the requirements for Emergency services. > ||> > > > ||> > >On a side note, one of the problems identified during a recent=20 > ||> > >school shooting in Canada was that the emergency and > ||police couldn't > ||> > >use the phone or cell phones to communicate because the > ||network was > ||> > >jammed due to high volume of calls between students and their > ||>families. > ||> > > > ||> > >Yours, > ||> > >Shahram > ||> > > > ||> > > > ||> > > > -----Original Message----- > ||> > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > ||> > > > Sent: Tuesday, September 19, 2006 5:26 PM > ||> > > > To: ken carlberg > ||> > > > Cc: pcn@ietf.org > ||> > > > Subject: ProblemStatement Issue B.9:Call Preemption > |Not Allowed > ||> >Issue. > ||> > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > ||> > > > > ||> > > > > ||> > > > Ken: > ||> > > > Thank you for handling so many of our replies at the > ||same time. :) > ||> > > > > ||> > > > YES, on your point of: > ||> > > > > ||> > > > >just to recap. I just wanted to point out that there are=20 > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider=20 > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > ||> > > > We are using the Problem-Statement draft to put out an=20 > ||> > > > initial version of what we are thinking, as this is still=20 > ||> > > > work in progress, there > ||>definitely > ||> > > > are area we > ||> > > > may have missed. > ||> > > > > ||> > > > Thank you for pointing out at least one of them. > ||> > > > > ||> > > > I will write some additional text for -01 version of > ||the Problem > ||> > > > Statement draft to try > ||> > > > and describe the problem you have indicated (but I > ||will try NOT to > ||> > > > indicate any solution > ||> > > > in the Problem Statement draft). > ||> > > > > ||> > > > And we will try to have some text in at least some of our > ||>Deployment > ||> > > > Model drafts > ||> > > > to see if there are good solutions to the problem you=20 > ||> > > > indicated. There may be more than one solution as there may > ||> > > > be more than one > |Deployment > ||> >Model. > ||> > > > > ||> > > > Please Notice I have changed the subject of the E-Mail > ||thread for > ||> > > > issue tracking purpose. > ||> > > > Please use this E-Mail Subject for continuing this discussion. > ||> > > > > ||> > > > Now I have additional questions concerning the use of > ||Preemption > ||>for > ||> > > > handling Emergency > ||> > > > Services. Will Preemption be allowed for Emergency Services? > ||> > > > Does some of the > ||> > > > jurisdiction you have indicated want to use a separate > ||network for > ||> > > > Emergency Services > ||> > > > purpose? Will combining Emergency Services with the normal=20 > ||> > > > VoIP calls/sessions be a good Problem Statement that we can=20 > ||> > > > add to our Problem Statement draft? > ||> > > > > ||> > > > I am concentrating on Problem Statement instead of Solutions > ||> > > > for now because we want to get the Problem Statement cleared > ||> > > > away first for the BOF purpose. > ||> > > > > ||> > > > Thanks! > ||> > > > -- Kwok -- > ||> > > > > ||> > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > ||> > > > >Anna, > ||> > > > > > ||> > > > >>>maybe we have a different perspective of > ||preemption. as I view > ||> >it, > ||> > > > >>>preemption is removing *existing* state (circuit > |in the PSTN > ||> > > > >>>world) in > ||> > > > >>>favor of new state. > ||> > > > >> > ||> > > > >>I guess that may be one thing that needs > ||clarification. The way > ||>I > ||> > > > >>view > ||> > > > >>it (and I think the way > ||draft-chan-pcn-problem-statement-00.txt > ||> >and > ||> > > > >>related docs view the issue) is that pre-emption > ||should kick in > ||> > > > >>when for > ||> > > > >>whatever reason provisioning mechanisms fail there > ||simply is not > ||> > > > >>enough > ||> > > > >>capacity to carry all calls. Setting aside the issue of > ||> >precedence > ||> > > > >>for > ||> > > > >>the moment, the expectation is that the level of > ||traffic needed > ||>to > ||> > > > >>trigger premption is typicaly higher (perhaps substanially > ||>higher) > ||> > > > >>than > ||> > > > >>the level triggering to stop admission of new flows. That > ||> > > > means that > ||> > > > >>when preemption does get triggered, there would actually > ||> > > > not really be > ||> > > > >>any new state admitted. > ||> > > > > > ||> > > > >I'm sorry, but with that last sentence you lost me > ||:-)...I kind > ||>of > ||> > > > >understood some of the things you were saying, but > ||there were too > ||> > > > >many things you left out (why does one have an > ||admission control > ||>at > ||> > > > >level X and a preemption level at X+N?, are you > ||implying that the > ||> > > > >edge is keeping track of the flows it > ||rejects?....that would seem > ||> > > > >quite granular in keeping measurements). > ||> > > > > > ||> > > > >I'm not sure its necessary to clarify the above. =20 > |Its probably > ||>just > ||> > > > >best that we agree that future work should include a more > ||>detailed > ||> > > > >discussion of what is preemption in the context of your > ||> >architecture. > ||> > > > > > ||> > > > >>The degree of how far apart preemption and admission=20 > ||> > > > >>thresholds are is of course a mater of > ||> > > > configuration, but I > ||> > > > >>would expect that they would be sufficiently apart to=20 > ||> > > > >>ensure > ||>that > ||> > > > >>you do > ||> > > > >>not just toggle preempted and new flows. Of course if=20 > ||> > > > >>there > ||> > > > are higher > ||> > > > >>precedence calls, then one might expect that a higher > ||> > > > precedence call > ||> > > > >>may be established while lower precedence calls may > ||need to be > ||> > > > >>preempted? > ||> > > > >> > ||> > > > >>Perhaps this expectation should be made more > ||transparent in the > ||> > > > >>drafts? > ||> > > > >> > ||> > > > >>>In the US and some other countries, this is not allowed=20 > ||> > > > >>>in the PSTN. > ||> > > > >> > ||> > > > >>Just wanted to make sure I understand exactly what is not > ||>allowed. > ||> > > > >>Are > ||> > > > >>you saying that PSTN is not allowed to preempt a lower > ||> > > > precedence call > ||> > > > >>in order to establish a high recedence call? Or are you > ||> > > > referring to > ||> > > > >>the same precedence levels? > ||> > > > > > ||> > > > >as an example, in the US PSTN, all calls from the > ||general public > ||> >are > ||> > > > >treated with the same level of precedence. the exception=20 > ||> > > > >are > ||> >systems > ||> > > > >like GETS, but they simply increase the probability of call > ||> > > > >completion -- they do not use preemption. private > ||systems based > ||>on > ||> > > > >MLPP, like Autovon in the DoD and NATO, do allow > ||different levels > ||> >of > ||> > > > >priority and subsequent preemption if so needed. =20 > |rfc-4190 and > ||> > > > >rfc-4542 provide background on these systems/services > ||along with > ||> > > > >discussion in the context of IP (since this is the IETF :-) > ||> > > > > > ||> > > > >just to recap. I just wanted to point out that there are=20 > ||> > > > >jurisdictions that do not allow preemption for voice > ||>communications > ||> > > > >used by the general public -- this definitely applies for a > ||>number > ||> >of > ||> > > > >PSTNs, and I'm sure it will trickle down to certain > ||deployments > ||>of > ||> > > > >VoIP. Hence, I would recommend that the group consider=20 > ||> > > > >other > ||>(re) > ||> > > > >actions other than preemption....which from the > |feedback of my > ||> > > > >original note, seems will be done. > ||> > > > > > ||> > > > >regards, > ||> > > > > > ||> > > > >-ken > ||> > > > > > ||> > > > > > ||> > > > >_______________________________________________ > ||> > > > >PCN mailing list > ||> > > > >PCN@ietf.org > ||> > > > >https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > > > ||> > > > _______________________________________________ > ||> > > > PCN mailing list > ||> > > > PCN@ietf.org > ||> > > > https://www1.ietf.org/mailman/listinfo/pcn > ||> > > > > ||> > > ||> > > ||> >_______________________________________________ > ||> >PCN mailing list > ||> >PCN@ietf.org > ||> >https://www1.ietf.org/mailman/listinfo/pcn > || > || > ||_______________________________________________ > ||PCN mailing list > ||PCN@ietf.org > ||https://www1.ietf.org/mailman/listinfo/pcn > || > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 -- 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 02 10:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP9L-0007SE-6S; Mon, 02 Oct 2006 10:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP9I-0007Ol-Oo for pcn@ietf.org; Mon, 02 Oct 2006 10:52:04 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP8z-00036F-UQ for pcn@ietf.org; Mon, 02 Oct 2006 10:52:04 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k92Epaqm010959; Mon, 2 Oct 2006 16:51:41 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 16:51:32 +0200 Message-ID: <005601c6e632$4376cbd0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbmMR9TjklrM+eJRLCKIU7hcv3mcQAAOsrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6.2.5.6.0.20061002103356.033369b8@nortel.com> X-Spam-Score: -5.647 () ALL_TRUSTED,AWL,BAYES_00,HTML_50_60,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 02 Oct 2006 16:51:43 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634651974==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0634651974== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C6E643.06FF9BD0" This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C6E643.06FF9BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kwock What about using the term "severe congestion marking"? Best Regards, Georgios _____ From: Kwok-Ho Chan [mailto:khchan@nortel.com] Sent: maandag 2 oktober 2006 16:43 To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term Some other suggestions related to Issue A4 of: A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? How about the terms of: "Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate" and "Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ? It is then up to the Policy Decision to take the appropriate action when the rate of traffic is not "Supportable" anymore. With Preemption being one of the possible policy decision actions. Thanks! -- Kwok -- At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt A1 "PCN-Region Term" Issue Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement. A2 "PIN Term" Issue Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes. I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far. PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested. PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region. I favour PCN Edge Node, and also ok with PCN Boundary / Border Node A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? Best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------=_NextPart_000_0057_01C6E643.06FF9BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kwock
 
What about using the term "severe=20 congestion marking"?
 
Best Regards,
Georgios
 
 

From: Kwok-Ho Chan = [mailto:khchan@nortel.com]=20
Sent: maandag 2 oktober 2006 16:43
To:=20 philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: Re: = [PCN]=20 Issue A4 Preemption Marking Term

Some other suggestions related to Issue A4 of:

A4    “Pre-emption Marking term”=20 Issue

Pre-emption Marking=20 may seem to indicate the requirement of pre-empting existing = flows/sessions to=20 allow additional new flows/sessions to be admitted.  This = scenario is not=20 allowed in some markets due to regulations.  Should a better term = be used=20 instead of Pre-emption Marking to indicate the need to reduce the = offered=20 traffic load to the congested portions of the = network?

Michael suggested “excess = traffic mark” – what=20 do you reckon?

How about the terms = of:
"Admissible=20 Rate Marking" for the marking indication of exceeding the "Admissible=20 Rate"
and
"Supportable Rate Marking" for the marking indication = of=20 exceeding the "Supportable Rate" ?

It is then up to the Policy = Decision=20 to take the appropriate action when the rate of traffic is
not = "Supportable"=20 anymore.  With Preemption being one of the possible policy decision = actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006,=20 philip.eardley@bt.com wrote:
Content-class:=20 urn:content-classes:message
Content-Type:=20 = multipart/alternative;
      &nbs= p; =20 = boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"


Thought I’d try to close =
a
few more of the Issues – covering the Issues “A. Terminology =
Issues”
listed at

http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt


 


A1      "PCN-Region Term" Issue


Should the region running
the PCN mechanism be called the PCN-Region or
PCN-Domain?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 RFC2998 supports use
of Region, RFC2474 supports use of
Domain.

Personally I don’t mind,
happy to stick with PCN-region as currently used in
draft-chan-problem-statement.


 


A2      "PIN Term" Issue


Should we use the
terminology PCN Interior Node or PCN Intermediate Node
(function)?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 RFC2475 supports use
of PCN Interior
Node

Personally I slightly
prefer PCN Interior Node, though I don’t mind much. So happy to =
stick
with PCN Interior Node as currently used in
draft-chan-problem-statement

 

 


A3      "PEN Term"
Issue

Should we use the
terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN
Border Node or PCN Gateway Node
(function)?

 Reference:
draft-chan-problem-statement-00.txt section
2.1.

 The term currently
used in draft-chan-problem-statement is PCN End
Node

 

Personally I don’t like the
term PCN End Node – the problem is that it will probably get =
shortened to
end node (already seen this happening on the list). I think this will =
get
confusing as [1] the innocent may think it means ‘end host’; =
[2] the
deployment models will probably show how PCN fits into the ‘big =
picture’
of end-to-end QoS, in which case we’d have both end hosts & =
PCN End
Nodes. 

 

I also think PCN Gateway
Node (function) could be slightly confusing. The actual physical node
where the “PCN End Node” function sits is typically the =
PCN-region’s
gateway node, but it could in some deployment situations be an end host,
if the PCN-region extends out that far.


 

PCN Boundary Node would be
consistent with rfc2474
terminology.

PCN Border Node is a
similar possibility that Michael has suggested.


 

PCN Edge Node allows us to
continue to use the nice acronym PEN, with its hint of ‘penning =
in’ the
PCN-region. 

 

I favour PCN Edge Node, and
also ok with PCN Boundary / Border
Node

 
 
A4    “Pre-emption Marking = term”=20 Issue
Pre-emption Marking may seem to indicate the requirement of=20 pre-empting existing flows/sessions to allow additional new = flows/sessions to=20 be admitted.  This scenario is not allowed in some markets due to = regulations.  Should a better term be used instead of Pre-emption = Marking=20 to indicate the need to reduce the offered traffic load to the = congested=20 portions of the network?
Michael suggested “excess traffic = mark” – what do=20 you reckon?
 
Best=20 = wishes
phil
_______________________________________________<= BR>PCN=20 mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn ------=_NextPart_000_0057_01C6E643.06FF9BD0-- --===============0634651974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0634651974==-- From pcn-bounces@ietf.org Mon Oct 02 10:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPFu-0007AS-1T; Mon, 02 Oct 2006 10:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPFs-0007A7-ME for pcn@ietf.org; Mon, 02 Oct 2006 10:58:52 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPFg-0004T1-8C for pcn@ietf.org; Mon, 02 Oct 2006 10:58:52 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 15:58:38 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 15:58:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 15:58:37 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD15@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <6.2.5.6.0.20061002103356.033369b8@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issue A4 Preemption Marking Term Thread-Index: AcbmMRhiavqcDbsrQ8m4UPxE29Xm4wAATRGg From: To: X-OriginalArrivalTime: 02 Oct 2006 14:58:38.0004 (UTC) FILETIME=[3DBB3F40:01C6E633] X-Spam-Score: 0.6 (/) X-Scan-Signature: 86914b0033efd24523ee4a427c36d849 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0273543944==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0273543944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E633.3D67146A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E633.3D67146A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like "Admissible Rate Marking" & "Admissible Rate" or maybe "configured-admissible-rate" also seem nice to me.=20 =20 I'm not so sure about "Supportable Rate Marking" & "Supportable Rate".=20 As well as the "Admissible Rate" there are 2 other rates associated with a link - the rate at which pkts are Pre-emption Marked (to use the current terminology!) - the rate at which pkts are dropped, ie the line rate.=20 =20 To me, "Supportable Rate" suggests the latter rather than the former. Maybe this is just me. Will try and think of something else. =20 phil =20 -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 Sent: 02 October 2006 15:43 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term =20 Some other suggestions related to Issue A4 of: A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? How about the terms of: "Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate" and=20 "Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ? It is then up to the Policy Decision to take the appropriate action when the rate of traffic is not "Supportable" anymore. With Preemption being one of the possible policy decision actions. Thanks! -- Kwok -- At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at =20 http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt =20 =20 =20 =20 A1 "PCN-Region Term" Issue =20 Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 RFC2998 supports use of Region, RFC2474 supports use of Domain. =20 Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement. =20 =20 =20 =20 A2 "PIN Term" Issue =20 Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 RFC2475 supports use of PCN Interior Node =20 Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement =20 =20 =20 =20 =20 =20 A3 "PEN Term" Issue =20 Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 The term currently used in draft-chan-problem-statement is PCN End Node =20 =20 =20 Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes.=20 =20 =20 =20 I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far. =20 =20 =20 PCN Boundary Node would be consistent with rfc2474 terminology. =20 PCN Border Node is a similar possibility that Michael has suggested. =20 =20 =20 PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region.=20 =20 =20 =20 I favour PCN Edge Node, and also ok with PCN Boundary / Border Node =20 =20 =20 A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? =20 Best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C6E633.3D67146A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like = "Admissible Rate Marking" & "Admissible Rate" or maybe = “configured-admissible-rate” also seem nice to me.

 

I’m not so sure about "Supportable Rate Marking" = & “Supportable Rate”.

As well as the "Admissible Rate" there are 2 other = rates associated with a link

-         the rate at which pkts are Pre-emption = Marked (to use the current terminology!)

-          the rate at which pkts are dropped, ie the = line rate.

 

To me, “Supportable Rate” suggests the latter rather = than the former. Maybe this is just me. Will try and think of something = else.

 

phil

 

-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortel.com]
Sent: 02 October 2006 = 15:43
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: Re: [PCN] Issue = A4 Preemption Marking Term

 

Some other suggestions related to Issue A4 of:


A4    “Pre-emption Marking term” Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting existing = flows/sessions to allow additional new flows/sessions to be admitted.  This = scenario is not allowed in some markets due to regulations.  Should a better = term be used instead of Pre-emption Marking to indicate the need to reduce the = offered traffic load to the congested portions of the network?

Michael suggested “excess traffic mark” – what do you = reckon?


How about the terms of:
"Admissible Rate Marking" for the marking indication of = exceeding the "Admissible Rate"
and
"Supportable Rate Marking" for the marking indication of = exceeding the "Supportable Rate" ?

It is then up to the Policy Decision to take the appropriate action when = the rate of traffic is
not "Supportable" anymore.  With Preemption being one of = the possible policy decision actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"

Thought I’d try to close =
a
few more =
of the Issues – covering the Issues “A. Terminology =
Issues”
listed =
at
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt

 

 

 

 
A1      =
"PCN-Region Term" Issue

 

Should the region =
running
the PCN =
mechanism be called the PCN-Region or
PCN-Domain?

 

 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.

 

 RFC2998 supports =
use
of =
Region, RFC2474 supports use of
Domain.

 

Personally I don’t =
mind,
happy to =
stick with PCN-region as currently used in
draft-chan-problem-statement.


 



 



 



 
A2      "PIN =
Term" Issue



 



Should we use =
the
terminology PCN Interior Node or PCN =
Intermediate Node
(function)?



 



 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.



 



 RFC2475 supports =
use
of PCN =
Interior
Node



 



Personally I =
slightly
prefer =
PCN Interior Node, though I don’t mind much. So happy to =
stick
with PCN =
Interior Node as currently used in
draft-chan-problem-statement


 



 



 



 



 



 
A3      "PEN =
Term"
Issue



 



Should we use =
the
terminology PCN End Node or PCN Edge Node or =
PCN Boundary Node or PCN
Border =
Node or PCN Gateway Node
(function)?



 



 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.



 



 The term =
currently
used in =
draft-chan-problem-statement is PCN End
Node



 



 



 



Personally I don’t like =
the
term PCN =
End Node – the problem is that it will probably get shortened =
to
end node =
(already seen this happening on the list). I think this will =
get
confusing =
as [1] the innocent may think it means ‘end host’; [2] =
the
deployment models will probably show how PCN =
fits into the ‘big picture’
of =
end-to-end QoS, in which case we’d have both end hosts & PCN =
End
Nodes. =




 



 



 



I also think PCN =
Gateway
Node =
(function) could be slightly confusing. The actual physical =
node
where the =
“PCN End Node” function sits is typically the =
PCN-region’s
gateway =
node, but it could in some deployment situations be an end =
host,
if the =
PCN-region extends out that far.



 



 



 



PCN Boundary Node would =
be
consistent with =
rfc2474
terminology.



 



PCN Border Node is =
a
similar =
possibility that Michael has suggested.



 



 



 



PCN Edge Node allows us =
to
continue =
to use the nice acronym PEN, with its hint of ‘penning in’ =
the
PCN-region. 



 



 



 



I favour PCN Edge Node, =
and
also ok =
with PCN Boundary / Border
Node



 



 
=



 

A4    “Pre-emption Marking term” Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting
existing flows/sessions to allow additional new flows/sessions to be =
admitted. 
This scenario is not allowed in some markets due to regulations.  =
Should a
better term be used instead of Pre-emption Marking to indicate the need =
to
reduce the offered traffic load to the congested portions of the =
network?

Michael suggested “excess traffic mark” – what do you =
reckon?

 

Best wishes

phil

_______________________________________________

PCN mailing list

PCN@ietf.org

https://www1.ietf.org/mailman/listinfo/pcn
=00 ------_=_NextPart_001_01C6E633.3D67146A-- --===============0273543944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0273543944==-- From pcn-bounces@ietf.org Mon Oct 02 11:02:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPIx-0007mC-DN; Mon, 02 Oct 2006 11:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPIv-0007le-I7 for pcn@ietf.org; Mon, 02 Oct 2006 11:02:02 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPIr-00055r-Bo for pcn@ietf.org; Mon, 02 Oct 2006 11:02:01 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:01:52 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 16:01:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 16:01:48 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD16@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <005601c6e632$4376cbd0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issue A4 Preemption Marking Term Thread-Index: AcbmMR9TjklrM+eJRLCKIU7hcv3mcQAAOsrAAABQYwA= From: To: , X-OriginalArrivalTime: 02 Oct 2006 15:01:51.0069 (UTC) FILETIME=[B0CEA0D0:01C6E633] X-Spam-Score: 0.6 (/) X-Scan-Signature: 37e57dc5d599c455d17d0c082f3536c2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1278064632==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1278064632== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E633.AF7E7895" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E633.AF7E7895 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure I like this, as the idea of this (pre-emption) marking is that action is taken so the link should never be congested.=20 =20 Perhaps "severe pre-congestion marking"? =20 =20 -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 02 October 2006 15:52 To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] Issue A4 Preemption Marking Term =20 Hi Kwock =20 What about using the term "severe congestion marking"? =20 Best Regards, Georgios =20 =20 =20 ________________________________ From: Kwok-Ho Chan [mailto:khchan@nortel.com]=20 Sent: maandag 2 oktober 2006 16:43 To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term Some other suggestions related to Issue A4 of: A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? How about the terms of: "Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate" and=20 "Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ? It is then up to the Policy Decision to take the appropriate action when the rate of traffic is not "Supportable" anymore. With Preemption being one of the possible policy decision actions. Thanks! -- Kwok -- At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at =20 http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt =20 =20 =20 =20 A1 "PCN-Region Term" Issue =20 Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 RFC2998 supports use of Region, RFC2474 supports use of Domain. =20 Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement. =20 =20 =20 =20 A2 "PIN Term" Issue =20 Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 RFC2475 supports use of PCN Interior Node =20 Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement =20 =20 =20 =20 =20 =20 A3 "PEN Term" Issue =20 Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? =20 Reference: draft-chan-problem-statement-00.txt section 2.1. =20 The term currently used in draft-chan-problem-statement is PCN End Node =20 =20 =20 Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes.=20 =20 =20 =20 I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far. =20 =20 =20 PCN Boundary Node would be consistent with rfc2474 terminology. =20 PCN Border Node is a similar possibility that Michael has suggested. =20 =20 =20 PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region.=20 =20 =20 =20 I favour PCN Edge Node, and also ok with PCN Boundary / Border Node =20 =20 =20 A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? =20 Best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C6E633.AF7E7895 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not sure I like this, as the idea = of this (pre-emption) marking is that action is taken so the link should never = be congested.

 

Perhaps “severe = pre-congestion marking”?

 

 

-----Original Message-----
From: Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 02 October 2006 = 15:52
To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] Issue = A4 Preemption Marking Term

 

Hi Kwock

 

What about using the term = "severe congestion marking"?

 

Best Regards,

Georgios

 

 

 

From: Kwok-Ho Chan [mailto:khchan@nortel.com]
Sent: maandag 2 oktober = 2006 16:43
To: = philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] Issue = A4 Preemption Marking Term

Some other suggestions related to Issue A4 of:


A4    “Pre-emption Marking term” Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be = admitted.  This scenario is not allowed in some markets due to regulations.  = Should a better term be used instead of Pre-emption Marking to indicate the need = to reduce the offered traffic load to the congested portions of the = network?

Michael suggested “excess traffic mark” – what do you = reckon?


How about the terms of:
"Admissible Rate Marking" for the marking indication of = exceeding the "Admissible Rate"
and
"Supportable Rate Marking" for the marking indication of = exceeding the "Supportable Rate" ?

It is then up to the Policy Decision to take the appropriate action when = the rate of traffic is
not "Supportable" anymore.  With Preemption being one of = the possible policy decision actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"

Thought I’d try to close =
a
few more =
of the Issues – covering the Issues “A. Terminology =
Issues”
listed =
at
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt

 

 

 

 
A1      =
"PCN-Region Term" Issue

 

Should the region =
running
the PCN =
mechanism be called the PCN-Region or
PCN-Domain?

 

 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.

 

 RFC2998 supports =
use
of =
Region, RFC2474 supports use of
Domain.

 

Personally I don’t =
mind,
happy to =
stick with PCN-region as currently used in
draft-chan-problem-statement.


 



 



 



 
A2      "PIN =
Term" Issue



 



Should we use =
the
terminology PCN Interior Node or PCN =
Intermediate Node
(function)?



 



 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.



 



 RFC2475 supports =
use
of PCN =
Interior
Node



 



Personally I =
slightly
prefer =
PCN Interior Node, though I don’t mind much. So happy to =
stick
with PCN =
Interior Node as currently used in
draft-chan-problem-statement


 



 



 



 



 



 
A3      "PEN =
Term"
Issue



 



Should we use =
the
terminology PCN End Node or PCN Edge Node or =
PCN Boundary Node or PCN
Border =
Node or PCN Gateway Node
(function)?



 



 Reference:
draft-chan-problem-statement-00.txt =
section
2.1.



 



 The term =
currently
used in =
draft-chan-problem-statement is PCN End
Node



 



 



 



Personally I don’t like =
the
term PCN =
End Node – the problem is that it will probably get shortened =
to
end node =
(already seen this happening on the list). I think this will =
get
confusing =
as [1] the innocent may think it means ‘end host’; [2] =
the
deployment models will probably show how PCN =
fits into the ‘big picture’
of =
end-to-end QoS, in which case we’d have both end hosts & PCN =
End
Nodes. =




 



 



 



I also think PCN =
Gateway
Node =
(function) could be slightly confusing. The actual physical =
node
where the =
“PCN End Node” function sits is typically the =
PCN-region’s
gateway =
node, but it could in some deployment situations be an end =
host,
if the =
PCN-region extends out that far.



 



 



 



PCN Boundary Node would =
be
consistent with =
rfc2474
terminology.



 



PCN Border Node is =
a
similar =
possibility that Michael has suggested.



 



 



 



PCN Edge Node allows us =
to
continue =
to use the nice acronym PEN, with its hint of ‘penning in’ =
the
PCN-region. 



 



 



 



I favour PCN Edge Node, =
and
also ok =
with PCN Boundary / Border
Node



 



 
=



 

A4    “Pre-emption Marking term” Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting
existing flows/sessions to allow additional new flows/sessions to be
admitted.  This scenario is not allowed in some markets due to =
regulations. 
Should a better term be used instead of Pre-emption Marking to indicate =
the
need to reduce the offered traffic load to the congested portions of the
network?

Michael suggested “excess traffic mark” – what do you =
reckon?

 

Best wishes

phil

_______________________________________________

PCN mailing list

PCN@ietf.org

https://www1.ietf.org/mailman/listinfo/pcn
=00 ------_=_NextPart_001_01C6E633.AF7E7895-- --===============1278064632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1278064632==-- From pcn-bounces@ietf.org Mon Oct 02 11:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPTp-0001Qa-5G; Mon, 02 Oct 2006 11:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPTn-0001QH-9j for pcn@ietf.org; Mon, 02 Oct 2006 11:13:15 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPTk-0006WD-BV for pcn@ietf.org; Mon, 02 Oct 2006 11:13:15 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92FCiI20569; Mon, 2 Oct 2006 11:12:44 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:12:42 -0400 Message-Id: <6.2.5.6.0.20061002110946.0368d678@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 Oct 2006 11:12:42 -0400 To: From: "Kwok-Ho Chan" Subject: RE: [PCN] Issue A4 Preemption Marking Term In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD16@E03MVZ1-UKDY.domain 1.systemhost.net> References: <005601c6e632$4376cbd0$4c0d5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD16@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2006 15:12:42.0384 (UTC) FILETIME=[35056900:01C6E635] X-Spam-Score: 0.1 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1365023268==" Errors-To: pcn-bounces@ietf.org --===============1365023268== Content-Type: multipart/alternative; boundary="=====================_9986489==.ALT" --=====================_9986489==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Georgios: I agree with Phil: that the use of "servere=20 congestion marking" will not be appropriate as Phil indicated. Lets see if there are more suggestions and let=20 all of us to allow some of these ideas to sink in a bit. -- Kwok -- At 11:01 AM 10/2/2006, philip.eardley@bt.com wrote: >Not sure I like this, as the idea of this=20 >(pre-emption) marking is that action is taken so=20 >the link should never be congested. > >Perhaps =93severe pre-congestion marking=94? > > >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >Sent: 02 October 2006 15:52 >To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >Cc: pcn@ietf.org >Subject: RE: [PCN] Issue A4 Preemption Marking Term > >Hi Kwock > >What about using the term "severe congestion marking"? > >Best Regards, >Georgios > > > > >---------- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: maandag 2 oktober 2006 16:43 >To: philip.eardley@bt.com >Cc: pcn@ietf.org >Subject: Re: [PCN] Issue A4 Preemption Marking Term >Some other suggestions related to Issue A4 of: > > >A4 =93Pre-emption Marking term=94 Issue > >Pre-emption Marking may seem to indicate the=20 >requirement of pre-empting existing=20 >flows/sessions to allow additional new=20 >flows/sessions to be admitted. This scenario is=20 >not allowed in some markets due to=20 >regulations. Should a better term be used=20 >instead of Pre-emption Marking to indicate the=20 >need to reduce the offered traffic load to the=20 >congested portions of the network? > >Michael suggested =93excess traffic mark=94 =96 what do you reckon? > >How about the terms of: >"Admissible Rate Marking" for the marking=20 >indication of exceeding the "Admissible Rate" >and >"Supportable Rate Marking" for the marking=20 >indication of exceeding the "Supportable Rate" ? > >It is then up to the Policy Decision to take the=20 >appropriate action when the rate of traffic is >not "Supportable" anymore. With Preemption=20 >being one of the possible policy decision actions. > >Thanks! >-- Kwok -- > >At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: > >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" > > >Thought I=92d try to close a >few more of the Issues =96 covering the Issues =93A. Terminology Issues=94 >listed at > > >http:/= /standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt=20 > > > > > >A1 "PCN-Region Term" Issue > >Should the region running >the PCN mechanism be called the PCN-Region or >PCN-Domain? > > Reference: >draft-chan-problem-statement-00.txt section >2.1. > > RFC2998 supports use >of Region, RFC2474 supports use of >Domain. > >Personally I don=92t mind, >happy to stick with PCN-region as currently used in >draft-chan-problem-statement. > > > > >A2 "PIN Term" Issue > >Should we use the >terminology PCN Interior Node or PCN Intermediate Node >(function)? > > Reference: >draft-chan-problem-statement-00.txt section >2.1. > > RFC2475 supports use >of PCN Interior >Node > >Personally I slightly >prefer PCN Interior Node, though I don=92t mind much. So happy to stick >with PCN Interior Node as currently used in >draft-chan-problem-statement > > > > > > >A3 "PEN Term" >Issue > >Should we use the >terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >Border Node or PCN Gateway Node >(function)? > > Reference: >draft-chan-problem-statement-00.txt section >2.1. > > The term currently >used in draft-chan-problem-statement is PCN End >Node > > > >Personally I don=92t like the >term PCN End Node =96 the problem is that it will probably get shortened to >end node (already seen this happening on the list). I think this will get >confusing as [1] the innocent may think it means =91end host=92; [2] the >deployment models will probably show how PCN fits into the =91big picture= =92 >of end-to-end QoS, in which case we=92d have both end hosts & PCN End >Nodes. > > > >I also think PCN Gateway >Node (function) could be slightly confusing. The actual physical node >where the =93PCN End Node=94 function sits is typically the PCN-region=92s >gateway node, but it could in some deployment situations be an end host, >if the PCN-region extends out that far. > > > >PCN Boundary Node would be >consistent with rfc2474 >terminology. > >PCN Border Node is a >similar possibility that Michael has suggested. > > > >PCN Edge Node allows us to >continue to use the nice acronym PEN, with its hint of =91penning in=92 the >PCN-region. > > > >I favour PCN Edge Node, and >also ok with PCN Boundary / Border >Node > > >A4 =93Pre-emption Marking term=94 Issue >Pre-emption Marking may seem to indicate the=20 >requirement of pre-empting existing=20 >flows/sessions to allow additional new=20 >flows/sessions to be admitted. This scenario is=20 >not allowed in some markets due to=20 >regulations. Should a better term be used=20 >instead of Pre-emption Marking to indicate the=20 >need to reduce the offered traffic load to the=20 >congested portions of the network? >Michael suggested =93excess traffic mark=94 =96 what do you reckon? > >Best wishes >phil >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn --=====================_9986489==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Georgios:
I agree with Phil:  that the use of "servere congestion marking" will not be appropriate as Phil indicated.
Lets see if there are more suggestions and let all of us to allow some of these ideas to sink in a bit.
-- Kwok --
 
At 11:01 AM 10/2/2006, philip.eardley@bt.com wrote:
Not sure I like this, as the idea of this (pre-emption) marking is that action is taken so the link should never be congested.
 
Perhaps =93severe pre-congestion marking=94?
 
 
-----Original Message-----
From: Georgios Karagiannis [ mailto:karagian@cs.utwente.nl]
Sent: 02 October 2006 15:52
To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] Issue A4 Preemption Marking Term
 
Hi Kwock
 
What about using the term "severe congestion marking"?
 
Best Regards,
Georgios
 
 
 
From: Kwok-Ho Chan [ mailto:khchan@nortel.com]
Sent: maandag 2 oktober 2006 16:43
To: philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: Re: [PCN] Issue A4 Preemption Marking Term
Some other suggestions related to Issue A4 of:


A4    =93Pre-emption Marking term=94 Issue

Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted.  This scenario is not allowed in some markets due to regulations.  Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network?

Michael suggested =93excess traffic mark=94 =96 what do you reckon?

How about the terms of:
"Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate"
and
"Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ?

It is then up to the Policy Decision to take the appropriate action when the rate of traffic is
not "Supportable" anymore.  With Preemption being one of the possible policy decision actions.

Thanks!
-- Kwok --

At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"


Thought I=92d try to close
a

few more of the Issues =96
covering the Issues =93A. Terminology
Issues=94

listed
at





http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt
 

 
 

 


A1      "PCN-Region Term"
Issue
 

Should the region
running

the PCN mechanism be calle=
d
the PCN-Region
or

PCN-Domain?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 RFC2998 supports
use

of Region, RFC2474 support=
s
use of

Domain.
 

Personally I don=92t
mind,

happy to stick with
PCN-region as currently used
in


draft-chan-problem-statement.
 

 
 

 


A2      "PIN Term"
Issue
 

Should we use
the

terminology PCN Interior
Node or PCN Intermediate
Node

(function)?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 RFC2475 supports
use

of PCN
Interior

Node
 

Personally I
slightly

prefer PCN Interior Node,
though I don=92t mind much. So happy to
stick

with PCN Interior Node as
currently used
in


draft-chan-problem-statement
 

 
 

 
 

 


A3      "PEN
Term"

Issue
 

Should we use
the

terminology PCN End Node o=
r
PCN Edge Node or PCN Boundary Node or
PCN

Border Node or PCN Gateway
Node

(function)?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 The term
currently

used in
draft-chan-problem-statement is PCN
End

Node
 

 
 

Personally I don=92t like
the

term PCN End Node =96 the
problem is that it will probably get shortened
to

end node (already seen thi=
s
happening on the list). I think this will
get

confusing as [1] the
innocent may think it means =91end host=92; [2]
the

deployment models will
probably show how PCN fits into the =91big
picture=92

of end-to-end QoS, in whic=
h
case we=92d have both end hosts & PCN
End

Nodes.
 

 
 

I also think PCN
Gateway

Node (function) could be
slightly confusing. The actual physical
node

where the =93PCN End Node=
=94
function sits is typically the
PCN-region=92s

gateway node, but it could
in some deployment situations be an end
host,

if the PCN-region extends
out that
far.
 

 
 

PCN Boundary Node would
be

consistent with
rfc2474

terminology.
 

PCN Border Node is
a

similar possibility that
Michael has
suggested.
 

 
 

PCN Edge Node allows us
to

continue to use the nice
acronym PEN, with its hint of =91penning in=92
the

PCN-region.
 

 
 

I favour PCN Edge Node,
and

also ok with PCN Boundary =
/
Border

Node
 

 
 
A4    =93Pre-emption Marking term=94 Issue
Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted.  This scenario is not allowed in some markets due to regulations.  Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network?
Michael suggested =93excess traffic mark=94 =96 what do you reckon?
 
Best wishes
phil
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn
--=====================_9986489==.ALT-- --===============1365023268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1365023268==-- From pcn-bounces@ietf.org Mon Oct 02 11:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPb6-0002yR-LE; Mon, 02 Oct 2006 11:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPb5-0002yB-Qs for pcn@ietf.org; Mon, 02 Oct 2006 11:20:47 -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 1GUPb3-0007iy-4n for pcn@ietf.org; Mon, 02 Oct 2006 11:20:47 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1945F42B8; Mon, 2 Oct 2006 17:20:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0BB764232; Mon, 2 Oct 2006 17:20:40 +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 9EF192F31; Mon, 2 Oct 2006 17:20:39 +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 k92FKds31585; Mon, 2 Oct 2006 17:20:39 +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 6CF176F58E; Mon, 2 Oct 2006 17:19:19 +0200 (CEST) Message-ID: <45212E61.3080300@informatik.uni-wuerzburg.de> Date: Mon, 02 Oct 2006 17:21:05 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] Issue A4 Preemption Marking Term References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD16@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD16@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, what do you think about the terms * admissible link rate and "admission stop marking" using an admission=20 stop bit * tolerable link rate and "excess traffic marking" using an excess=20 traffic bit * supportED link rate (now =3D physical or virtual link rate used for=20 interface traffic shaping (Phil), but I'm not sure whether this=20 expression is required at all: maybe just link rate?) Admission control is a requirement in our context, but preemption is=20 just an option when the tolerable link rate is exceeded (I think I read=20 that somewhere). Therefore, I don't like the term "preemption marking"=20 since this suggests preemption as mandatory. IF preemption is a=20 mandatory feature, the term preemption marking is fine. Regards, Michael philip.eardley@bt.com wrote: > > Not sure I like this, as the idea of this (pre-emption) marking is=20 > that action is taken so the link should never be congested. > > Perhaps =93severe pre-congestion marking=94? > > -----Original Message----- > *From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > *Sent:* 02 October 2006 15:52 > *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R > *Cc:* pcn@ietf.org > *Subject:* RE: [PCN] Issue A4 Preemption Marking Term > > Hi Kwock > > What about using the term "severe congestion marking"? > > Best Regards, > > Georgios > > -----------------------------------------------------------------------= - > > *From:* Kwok-Ho Chan [mailto:khchan@nortel.com] > *Sent:* maandag 2 oktober 2006 16:43 > *To:* philip.eardley@bt.com > *Cc:* pcn@ietf.org > *Subject:* Re: [PCN] Issue A4 Preemption Marking Term > > Some other suggestions related to Issue A4 of: > > > A4 =93Pre-emption Marking term=94 Issue > > Pre-emption Marking may seem to indicate the requirement of=20 > pre-empting existing flows/sessions to allow additional new=20 > flows/sessions to be admitted. This scenario is not allowed in some=20 > markets due to regulations. Should a better term be used instead of=20 > Pre-emption Marking to indicate the need to reduce the offered traffic=20 > load to the congested portions of the network? > > Michael suggested =93excess traffic mark=94 =96 what do you reckon? > > > How about the terms of: > "Admissible Rate Marking" for the marking indication of exceeding the=20 > "Admissible Rate" > and > "Supportable Rate Marking" for the marking indication of exceeding the=20 > "Supportable Rate" ? > > It is then up to the Policy Decision to take the appropriate action=20 > when the rate of traffic is > not "Supportable" anymore. With Preemption being one of the possible=20 > policy decision actions. > > Thanks! > -- Kwok -- > > At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: > > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" > > Thought I=92d try to close a > few more of the Issues =96 covering the Issues =93A. Terminology Issues= =94 > listed at > _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ > > =20 > > =20 > A1 "PCN-Region Term" Issue > > Should the region running > the PCN mechanism be called the PCN-Region or > PCN-Domain? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > RFC2998 supports use > of Region, RFC2474 supports use of > Domain. > > Personally I don=92t mind, > happy to stick with PCN-region as currently used in > draft-chan-problem-statement. > > =20 > > =20 > A2 "PIN Term" Issue > > Should we use the > terminology PCN Interior Node or PCN Intermediate Node > (function)? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > RFC2475 supports use > of PCN Interior > Node > > Personally I slightly > prefer PCN Interior Node, though I don=92t mind much. So happy to stick > with PCN Interior Node as currently used in > draft-chan-problem-statement > > =20 > > =20 > > =20 > A3 "PEN Term" > Issue > > Should we use the > terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN > Border Node or PCN Gateway Node > (function)? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > The term currently > used in draft-chan-problem-statement is PCN End > Node > > =20 > > Personally I don=92t like the > term PCN End Node =96 the problem is that it will probably get shortene= d to > end node (already seen this happening on the list). I think this will g= et > confusing as [1] the innocent may think it means =91end host=92; [2] th= e > deployment models will probably show how PCN fits into the =91big pictu= re=92 > of end-to-end QoS, in which case we=92d have both end hosts & PCN End > Nodes.=20 > > =20 > > I also think PCN Gateway > Node (function) could be slightly confusing. The actual physical node > where the =93PCN End Node=94 function sits is typically the PCN-region=92= s > gateway node, but it could in some deployment situations be an end host= , > if the PCN-region extends out that far. > > =20 > > PCN Boundary Node would be > consistent with rfc2474 > terminology. > > PCN Border Node is a > similar possibility that Michael has suggested. > > =20 > > PCN Edge Node allows us to > continue to use the nice acronym PEN, with its hint of =91penning in=92= the > PCN-region.=20 > > =20 > > I favour PCN Edge Node, and > also ok with PCN Boundary / Border > Node > > =20 > > > A4 =93Pre-emption Marking term=94 Issue > Pre-emption Marking may seem to indicate the requirement of=20 > pre-empting existing flows/sessions to allow additional new=20 > flows/sessions to be admitted. This scenario is not allowed in some=20 > markets due to regulations. Should a better term be used instead of=20 > Pre-emption Marking to indicate the need to reduce the offered traffic=20 > load to the congested portions of the network? > Michael suggested =93excess traffic mark=94 =96 what do you reckon? > > Best wishes > phil > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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 From pcn-bounces@ietf.org Mon Oct 02 11:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPkT-00033p-5s; Mon, 02 Oct 2006 11:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUPkS-00033i-6n for pcn@ietf.org; Mon, 02 Oct 2006 11:30:28 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUPkQ-0000In-6A for pcn@ietf.org; Mon, 02 Oct 2006 11:30:28 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k92FUFWp014193; Mon, 2 Oct 2006 17:30:18 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kwok-Ho Chan'" , Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 17:30:10 +0200 Message-ID: <007701c6e637$a9773730$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbmNT+Fd3dyMVhfSzeippFO0OuF0gAAk8fQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6.2.5.6.0.20061002110946.0368d678@nortel.com> X-Spam-Score: -5.39 () ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE,J_CHICKENPOX_72 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 02 Oct 2006 17:30:21 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34793307b79a1353c9d03ed8a398bb86 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1715917941==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1715917941== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C6E648.6D000730" This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C6E648.6D000730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kwok yes I agree with your proposal! Best regards, Georgios _____ From: Kwok-Ho Chan [mailto:khchan@nortel.com] Sent: maandag 2 oktober 2006 17:13 To: philip.eardley@bt.com Cc: karagian@cs.utwente.nl; Kwok-Ho Chan; pcn@ietf.org Subject: RE: [PCN] Issue A4 Preemption Marking Term Georgios: I agree with Phil: that the use of "servere congestion marking" will not be appropriate as Phil indicated. Lets see if there are more suggestions and let all of us to allow some of these ideas to sink in a bit. -- Kwok -- At 11:01 AM 10/2/2006, philip.eardley@bt.com wrote: Not sure I like this, as the idea of this (pre-emption) marking is that action is taken so the link should never be congested. Perhaps "severe pre-congestion marking"? -----Original Message----- From: Georgios Karagiannis [ mailto:karagian@cs.utwente.nl] Sent: 02 October 2006 15:52 To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] Issue A4 Preemption Marking Term Hi Kwock What about using the term "severe congestion marking"? Best Regards, Georgios _____ From: Kwok-Ho Chan [ mailto:khchan@nortel.com] Sent: maandag 2 oktober 2006 16:43 To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term Some other suggestions related to Issue A4 of: A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? How about the terms of: "Admissible Rate Marking" for the marking indication of exceeding the "Admissible Rate" and "Supportable Rate Marking" for the marking indication of exceeding the "Supportable Rate" ? It is then up to the Policy Decision to take the appropriate action when the rate of traffic is not "Supportable" anymore. With Preemption being one of the possible policy decision actions. Thanks! -- Kwok -- At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt A1 "PCN-Region Term" Issue Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement. A2 "PIN Term" Issue Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes. I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far. PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested. PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region. I favour PCN Edge Node, and also ok with PCN Boundary / Border Node A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? Best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------=_NextPart_000_0078_01C6E648.6D000730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kwok
 
yes I agree with your = proposal!
Best regards,
Georgios
 

From: Kwok-Ho Chan = [mailto:khchan@nortel.com]=20
Sent: maandag 2 oktober 2006 17:13
To:=20 philip.eardley@bt.com
Cc: karagian@cs.utwente.nl; Kwok-Ho = Chan;=20 pcn@ietf.org
Subject: RE: [PCN] Issue A4 Preemption Marking=20 Term

Georgios:
I agree with Phil:  that the use of = "servere=20 congestion marking" will not be appropriate as Phil indicated.
Lets = see if=20 there are more suggestions and let all of us to allow some of these = ideas to=20 sink in a bit.
-- Kwok --
 
At 11:01 AM 10/2/2006,=20 philip.eardley@bt.com wrote:
Not sure=20 I like this, as the idea of this (pre-emption) marking is that action = is taken=20 so the link should never be congested.
 
Perhaps = “severe=20 pre-congestion marking”?
 
 
-----Original Message-----
From: Georgios = Karagiannis [=20 mailto:karagian@cs.utwente.nl]
Sent: 02 October 2006=20 15:52
To: 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 = R
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] Issue A4 Preemption Marking=20 Term
 
Hi Kwock
 
What=20 about using the term "severe congestion marking"?
 
Best=20 Regards,
Georgios
 
 
 
From: Kwok-Ho=20 Chan [=20 mailto:khchan@nortel.com]
Sent: maandag 2 oktober 2006=20 16:43
To: philip.eardley@bt.com
Cc:=20 pcn@ietf.org
Subject: Re: [PCN] Issue A4 Preemption Marking=20 Term
Some other = suggestions=20 related to Issue A4 of:


A4    “Pre-emption Marking term”=20 Issue

Pre-emption Marking=20 may seem to indicate the requirement of pre-empting existing = flows/sessions to=20 allow additional new flows/sessions to be admitted.  This = scenario is not=20 allowed in some markets due to regulations.  Should a better term = be used=20 instead of Pre-emption Marking to indicate the need to reduce the = offered=20 traffic load to the congested portions of the = network?

Michael suggested “excess = traffic mark” – what=20 do you reckon?

How = about the=20 terms of:
"Admissible Rate Marking" for the marking indication of = exceeding=20 the "Admissible Rate"
and
"Supportable Rate Marking" for the = marking=20 indication of exceeding the "Supportable Rate" ?

It is then up = to the=20 Policy Decision to take the appropriate action when the rate of = traffic=20 is
not "Supportable" anymore.  With Preemption being one of = the=20 possible policy decision actions.

Thanks!
-- Kwok = --

At 10:09=20 AM 10/2/2006, philip.eardley@bt.com wrote:

Content-class:=20 urn:content-classes:message
Content-Type:=20 = multipart/alternative;
      &nbs= p; =20 = boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF"


Thought I’d try to = close a
few more of the Issues –
covering the Issues “A. Terminology
Issues”

listed
at





http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt
 

 
 

 


A1      "PCN-Region Term"
Issue
 

Should the region
running

the PCN mechanism be called
the PCN-Region
or

PCN-Domain?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 RFC2998 supports
use

of =
Region, RFC2474 supports
use of

Domain.
 

Personally I don’t
mind,

happy to stick with
PCN-region as currently used
in


draft-chan-problem-statement.
 

 
 

 


A2      "PIN Term"
Issue
 

Should we use
the

terminology PCN Interior
Node or PCN Intermediate
Node

(function)?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 RFC2475 supports
use

of =
PCN
Interior

Node
 

Personally I
slightly

prefer PCN Interior Node,
though I don’t mind much. So happy to
stick

with PCN Interior Node as
currently used
in


draft-chan-problem-statement
 

 
 

 
 

 


A3      "PEN
Term"

Issue
 

Should we use
the

terminology PCN End Node or
PCN Edge Node or PCN Boundary Node or
PCN

Border Node or PCN Gateway
Node

(function)?
 

 Reference:



draft-chan-problem-statement-00.txt
section

2.1.
 

 The term
currently

used in
draft-chan-problem-statement is PCN
End

Node
 

 
 

Personally I don’t like
the

term PCN End Node – the
problem is that it will probably get shortened
to

end node (already seen this
happening on the list). I think this will
get

confusing as [1] the
innocent may think it means ‘end host’; [2]
the

deployment models will
probably show how PCN fits into the ‘big
picture’

of =
end-to-end QoS, in which
case we’d have both end hosts & PCN
End

Nodes.
 

 
 

I also think PCN
Gateway

Node (function) could be
slightly confusing. The actual physical
node

where the “PCN End Node”
function sits is typically the
PCN-region’s

gateway node, but it could
in some deployment situations be an end
host,

if =
the PCN-region extends
out that
far.
 

 
 

PCN Boundary Node would
be

consistent with
rfc2474

terminology.
 

PCN Border Node is
a

similar possibility that
Michael has
suggested.
 

 
 

PCN Edge Node allows us
to

continue to use the nice
acronym PEN, with its hint of ‘penning in’
the

PCN-region.
 

 
 

I favour PCN Edge Node,
and

also ok with PCN Boundary /
Border

Node
 

 
 
A4    “Pre-emption Marking = term”=20 Issue
Pre-emption Marking may seem to indicate the requirement of=20 pre-empting existing flows/sessions to allow additional new = flows/sessions to=20 be admitted.  This scenario is not allowed in some markets due to = regulations.  Should a better term be used instead of Pre-emption = Marking=20 to indicate the need to reduce the offered traffic load to the = congested=20 portions of the network?
Michael suggested “excess traffic = mark” – what do=20 you reckon?
 
Best=20 = wishes
phil
_______________________________________________<= BR>PCN=20 mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn ------=_NextPart_000_0078_01C6E648.6D000730-- --===============1715917941== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1715917941==-- From pcn-bounces@ietf.org Mon Oct 02 12:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQvk-0004Fo-HM; Mon, 02 Oct 2006 12:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQvi-0004EE-W0 for pcn@ietf.org; Mon, 02 Oct 2006 12:46:10 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQvh-0004Ia-HD for pcn@ietf.org; Mon, 02 Oct 2006 12:46:10 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92Gk6x28805; Mon, 2 Oct 2006 12:46:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 12:46:06 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.com> In-Reply-To: <45212E61.3080300@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issue A4 Preemption Marking Term thread-index: AcbmNmjUQgZh52ZOTHG47zyOVlqahwAB+6Bw From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I like what Michael is suggesting with the following minor changes. "admissible rate" drop the word link because only some of the traffic on the link is being measured e.g., per service class.=20 I'm OK with "admission stop marking" or just "admission marking" meaning this is when admission of additional flows should be stopped. For the second level I support using "supportable rate" and for the marking "excess traffic marking" where the excess traffic is greater then the configured supportable rate and may or may not be above the actual link rate. I would expect that normally supportable rate would loss that link rate and possible less than the forwarding rate of the queue used. Preemption is an action of removing flows that some solution may take to get ride of excess traffic and return to provide good QoS to remaining traffic. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Monday, October 02, 2006 11:21 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term Hi, what do you think about the terms * admissible link rate and "admission stop marking" using an admission=20 stop bit * tolerable link rate and "excess traffic marking" using an excess=20 traffic bit * supportED link rate (now =3D physical or virtual link rate used for=20 interface traffic shaping (Phil), but I'm not sure whether this=20 expression is required at all: maybe just link rate?) Admission control is a requirement in our context, but preemption is=20 just an option when the tolerable link rate is exceeded (I think I read=20 that somewhere). Therefore, I don't like the term "preemption marking"=20 since this suggests preemption as mandatory. IF preemption is a=20 mandatory feature, the term preemption marking is fine. Regards, Michael philip.eardley@bt.com wrote: > > Not sure I like this, as the idea of this (pre-emption) marking is=20 > that action is taken so the link should never be congested. > > Perhaps "severe pre-congestion marking"? > > -----Original Message----- > *From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > *Sent:* 02 October 2006 15:52 > *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R > *Cc:* pcn@ietf.org > *Subject:* RE: [PCN] Issue A4 Preemption Marking Term > > Hi Kwock > > What about using the term "severe congestion marking"? > > Best Regards, > > Georgios > > ------------------------------------------------------------------------ > > *From:* Kwok-Ho Chan [mailto:khchan@nortel.com] > *Sent:* maandag 2 oktober 2006 16:43 > *To:* philip.eardley@bt.com > *Cc:* pcn@ietf.org > *Subject:* Re: [PCN] Issue A4 Preemption Marking Term > > Some other suggestions related to Issue A4 of: > > > A4 "Pre-emption Marking term" Issue > > Pre-emption Marking may seem to indicate the requirement of=20 > pre-empting existing flows/sessions to allow additional new=20 > flows/sessions to be admitted. This scenario is not allowed in some=20 > markets due to regulations. Should a better term be used instead of=20 > Pre-emption Marking to indicate the need to reduce the offered traffic > load to the congested portions of the network? > > Michael suggested "excess traffic mark" - what do you reckon? > > > How about the terms of: > "Admissible Rate Marking" for the marking indication of exceeding the=20 > "Admissible Rate" > and > "Supportable Rate Marking" for the marking indication of exceeding the > "Supportable Rate" ? > > It is then up to the Policy Decision to take the appropriate action=20 > when the rate of traffic is > not "Supportable" anymore. With Preemption being one of the possible=20 > policy decision actions. > > Thanks! > -- Kwok -- > > At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: > > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" > > Thought I'd try to close a > few more of the Issues - covering the Issues "A. Terminology Issues" > listed at > _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ > > =20 > > =20 > A1 "PCN-Region Term" Issue > > Should the region running > the PCN mechanism be called the PCN-Region or > PCN-Domain? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > RFC2998 supports use > of Region, RFC2474 supports use of > Domain. > > Personally I don't mind, > happy to stick with PCN-region as currently used in > draft-chan-problem-statement. > > =20 > > =20 > A2 "PIN Term" Issue > > Should we use the > terminology PCN Interior Node or PCN Intermediate Node > (function)? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > RFC2475 supports use > of PCN Interior > Node > > Personally I slightly > prefer PCN Interior Node, though I don't mind much. So happy to stick > with PCN Interior Node as currently used in > draft-chan-problem-statement > > =20 > > =20 > > =20 > A3 "PEN Term" > Issue > > Should we use the > terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN > Border Node or PCN Gateway Node > (function)? > > Reference: > draft-chan-problem-statement-00.txt section > 2.1. > > The term currently > used in draft-chan-problem-statement is PCN End > Node > > =20 > > Personally I don't like the > term PCN End Node - the problem is that it will probably get shortened to > end node (already seen this happening on the list). I think this will get > confusing as [1] the innocent may think it means 'end host'; [2] the > deployment models will probably show how PCN fits into the 'big picture' > of end-to-end QoS, in which case we'd have both end hosts & PCN End > Nodes.=20 > > =20 > > I also think PCN Gateway > Node (function) could be slightly confusing. The actual physical node > where the "PCN End Node" function sits is typically the PCN-region's > gateway node, but it could in some deployment situations be an end host, > if the PCN-region extends out that far. > > =20 > > PCN Boundary Node would be > consistent with rfc2474 > terminology. > > PCN Border Node is a > similar possibility that Michael has suggested. > > =20 > > PCN Edge Node allows us to > continue to use the nice acronym PEN, with its hint of 'penning in' the > PCN-region.=20 > > =20 > > I favour PCN Edge Node, and > also ok with PCN Boundary / Border > Node > > =20 > > > A4 "Pre-emption Marking term" Issue > Pre-emption Marking may seem to indicate the requirement of=20 > pre-empting existing flows/sessions to allow additional new=20 > flows/sessions to be admitted. This scenario is not allowed in some=20 > markets due to regulations. Should a better term be used instead of=20 > Pre-emption Marking to indicate the need to reduce the offered traffic > load to the congested portions of the network? > Michael suggested "excess traffic mark" - what do you reckon? > > Best wishes > phil > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 02 13:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURDj-0002Bc-AG; Mon, 02 Oct 2006 13:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURDh-00026Z-F2 for pcn@ietf.org; Mon, 02 Oct 2006 13:04:45 -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 1GURDf-000307-La for pcn@ietf.org; Mon, 02 Oct 2006 13:04:45 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E998220FF; Mon, 2 Oct 2006 19:04:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DABF53076; Mon, 2 Oct 2006 19:04:42 +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 86DFA2F6C; Mon, 2 Oct 2006 19:04:42 +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 k92H4gs32461; Mon, 2 Oct 2006 19:04:42 +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 440526F58E; Mon, 2 Oct 2006 19:03:22 +0200 (CEST) Message-ID: <452146C2.6020506@informatik.uni-wuerzburg.de> Date: Mon, 02 Oct 2006 19:05:06 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Issue A4 Preemption Marking Term References: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.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: 918f4bd8440e8de4700bcf6d658bc801 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, I think that the word "link" in "admissible link rate" indicates that the respective rate is link specific in contrast to the "border-to-border (b2b)" (received, admission-stop, excess traffic) rates (or estimates) that are measured at the egress per b2b aggregate. Thus, the "link" within the term avoids misunderstandings with other possible scopes (e.g. admissible rate for a specific ingress, admissible rate for specific b2b aggregates, ...). Initially, I had a hard time to understand the draft since the scope of the rates was not clear to me. If we know what we mean, we don't need the "link", but it makes it easier for new people to understand the architecture. Best wishes, Michael Jozef Babiarz wrote: > I like what Michael is suggesting with the following minor changes. > "admissible rate" drop the word link because only some of the traffic on > the link is being measured e.g., per service class. > I'm OK with "admission stop marking" or just "admission marking" meaning > this is when admission of additional flows should be stopped. > > For the second level I support using "supportable rate" and for the > marking "excess traffic marking" where the excess traffic is greater > then the configured supportable rate and may or may not be above the > actual link rate. I would expect that normally supportable rate would > loss that link rate and possible less than the forwarding rate of the > queue used. Preemption is an action of removing flows that some solution > may take to get ride of excess traffic and return to provide good QoS to > remaining traffic. > > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Monday, October 02, 2006 11:21 AM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Issue A4 Preemption Marking Term > > Hi, > > what do you think about the terms > > * admissible link rate and "admission stop marking" using an admission > stop bit > * tolerable link rate and "excess traffic marking" using an excess > traffic bit > * supportED link rate (now = physical or virtual link rate used for > interface traffic shaping (Phil), but I'm not sure whether this > expression is required at all: maybe just link rate?) > > Admission control is a requirement in our context, but preemption is > just an option when the tolerable link rate is exceeded (I think I read > that somewhere). Therefore, I don't like the term "preemption marking" > since this suggests preemption as mandatory. IF preemption is a > mandatory feature, the term preemption marking is fine. > > Regards, > > Michael > > philip.eardley@bt.com wrote: > >> Not sure I like this, as the idea of this (pre-emption) marking is >> that action is taken so the link should never be congested. >> >> Perhaps "severe pre-congestion marking"? >> >> -----Original Message----- >> *From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> *Sent:* 02 October 2006 15:52 >> *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >> *Cc:* pcn@ietf.org >> *Subject:* RE: [PCN] Issue A4 Preemption Marking Term >> >> Hi Kwock >> >> What about using the term "severe congestion marking"? >> >> Best Regards, >> >> Georgios >> >> >> > ------------------------------------------------------------------------ > >> *From:* Kwok-Ho Chan [mailto:khchan@nortel.com] >> *Sent:* maandag 2 oktober 2006 16:43 >> *To:* philip.eardley@bt.com >> *Cc:* pcn@ietf.org >> *Subject:* Re: [PCN] Issue A4 Preemption Marking Term >> >> Some other suggestions related to Issue A4 of: >> >> >> A4 "Pre-emption Marking term" Issue >> >> Pre-emption Marking may seem to indicate the requirement of >> pre-empting existing flows/sessions to allow additional new >> flows/sessions to be admitted. This scenario is not allowed in some >> markets due to regulations. Should a better term be used instead of >> Pre-emption Marking to indicate the need to reduce the offered traffic >> > > >> load to the congested portions of the network? >> >> Michael suggested "excess traffic mark" - what do you reckon? >> >> >> How about the terms of: >> "Admissible Rate Marking" for the marking indication of exceeding the >> "Admissible Rate" >> and >> "Supportable Rate Marking" for the marking indication of exceeding the >> > > >> "Supportable Rate" ? >> >> It is then up to the Policy Decision to take the appropriate action >> when the rate of traffic is >> not "Supportable" anymore. With Preemption being one of the possible >> policy decision actions. >> >> Thanks! >> -- Kwok -- >> >> At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >> >> Content-class: urn:content-classes:message >> Content-Type: multipart/alternative; >> boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" >> >> Thought I'd try to close a >> few more of the Issues - covering the Issues "A. Terminology Issues" >> listed at >> _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ >> >> >> >> >> A1 "PCN-Region Term" Issue >> >> Should the region running >> the PCN mechanism be called the PCN-Region or >> PCN-Domain? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> RFC2998 supports use >> of Region, RFC2474 supports use of >> Domain. >> >> Personally I don't mind, >> happy to stick with PCN-region as currently used in >> draft-chan-problem-statement. >> >> >> >> >> A2 "PIN Term" Issue >> >> Should we use the >> terminology PCN Interior Node or PCN Intermediate Node >> (function)? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> RFC2475 supports use >> of PCN Interior >> Node >> >> Personally I slightly >> prefer PCN Interior Node, though I don't mind much. So happy to stick >> with PCN Interior Node as currently used in >> draft-chan-problem-statement >> >> >> >> >> >> >> A3 "PEN Term" >> Issue >> >> Should we use the >> terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >> Border Node or PCN Gateway Node >> (function)? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> The term currently >> used in draft-chan-problem-statement is PCN End >> Node >> >> >> >> Personally I don't like the >> term PCN End Node - the problem is that it will probably get shortened >> > to > >> end node (already seen this happening on the list). I think this will >> > get > >> confusing as [1] the innocent may think it means 'end host'; [2] the >> deployment models will probably show how PCN fits into the 'big >> > picture' > >> of end-to-end QoS, in which case we'd have both end hosts & PCN End >> Nodes. >> >> >> >> I also think PCN Gateway >> Node (function) could be slightly confusing. The actual physical node >> where the "PCN End Node" function sits is typically the PCN-region's >> gateway node, but it could in some deployment situations be an end >> > host, > >> if the PCN-region extends out that far. >> >> >> >> PCN Boundary Node would be >> consistent with rfc2474 >> terminology. >> >> PCN Border Node is a >> similar possibility that Michael has suggested. >> >> >> >> PCN Edge Node allows us to >> continue to use the nice acronym PEN, with its hint of 'penning in' >> > the > >> PCN-region. >> >> >> >> I favour PCN Edge Node, and >> also ok with PCN Boundary / Border >> Node >> >> >> >> >> A4 "Pre-emption Marking term" Issue >> Pre-emption Marking may seem to indicate the requirement of >> pre-empting existing flows/sessions to allow additional new >> flows/sessions to be admitted. This scenario is not allowed in some >> markets due to regulations. Should a better term be used instead of >> Pre-emption Marking to indicate the need to reduce the offered traffic >> > > >> load to the congested portions of the network? >> Michael suggested "excess traffic mark" - what do you reckon? >> >> Best wishes >> phil >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> > > -- 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 From pcn-bounces@ietf.org Mon Oct 02 13:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURUR-0006ro-KI; Mon, 02 Oct 2006 13:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURUP-0006rS-Qk for pcn@ietf.org; Mon, 02 Oct 2006 13:22:01 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURUO-0007vn-3l for pcn@ietf.org; Mon, 02 Oct 2006 13:22:01 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92HLvx29676; Mon, 2 Oct 2006 13:21:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Issues A1, A2, A3, A4 Date: Mon, 2 Oct 2006 13:21:57 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C6451A3@zcarhxm1.corp.nortel.com> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD13@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issues A1, A2, A3, A4 thread-index: AcbmLG/WigOHnm5QRWyfx4HM9/h/cwAFeONA From: "Jozef Babiarz" To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0802757767==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0802757767== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E647.41C2A4FF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E647.41C2A4FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Phil on issue A3. We have at least two deployment model that we would like the PCN mechanism to be feasible in. One is the "edge-to-edge deployment model as explained in cl-architecture draft and the second being SIP controlled admission and preemption which I will send a draft out in few days.=20 =20 In the edge-to-edge case decisions are made in network edge nodes which is the end node for PCN and in the SIP controlled model, the decision is make in the SIP controlled endpoint which is an application or service control point. In SIP case the PCN end node is a phone, media gateway, multi media terminal, boundary gateway, etc.=20 =20 To be generic and so that it works for both models, I like PCN End Node. =20 Regards, Joe=20 QoS & Network Architecture=20 Telephone: 613-763-6098 (ESN 393-6098)=20 Email: babiarz@nortel.com=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, October 02, 2006 10:10 AM To: pcn@ietf.org Subject: [PCN] Issues A1, A2, A3, A4 =20 Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt=20 =20 A1 "PCN-Region Term" Issue=20 Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement.=20 =20 A2 "PIN Term" Issue=20 Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement =20 =20 A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node =20 Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes.=20 =20 I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far.=20 =20 PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested.=20 =20 PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region.=20 =20 I favour PCN Edge Node, and also ok with PCN Boundary / Border Node =20 =20 A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? =20 Best wishes phil ------_=_NextPart_001_01C6E647.41C2A4FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Phil on issue = A3.

We have at least two deployment = model that we would like the PCN mechanism to be feasible = in.

One is the “edge-to-edge = deployment model as explained in cl-architecture draft and the second being SIP = controlled admission and preemption which I will send a draft out in few days. =

 

In the edge-to-edge case decisions = are made in network edge nodes which is the end node for PCN and in the SIP controlled model, the decision is make in the SIP controlled endpoint = which is an application or service control point. In SIP case the PCN end node is = a phone, media gateway, multi media terminal, boundary gateway, etc. =

 

To be generic and so that it works = for both models, I like PCN End Node.  

 

Regards, = Joe
QoS & Network = Architecture
Telephone: 613-763-6098 (ESN = 393-6098)
Email: babiarz@nortel.com

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, October 02, = 2006 10:10 AM
To: pcn@ietf.org
Subject: [PCN] Issues A1, = A2, A3, A4

 

Thought I’d try to close a few more of =
the Issues – covering the Issues “A. Terminology =
Issues” listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
A1      =
"PCN-Region Term" Issue =

Should the region running the PCN mechanism =
be called the PCN-Region or =
PCN-Domain?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 RFC2998 supports use of Region, RFC2474 =
supports use of Domain.
Personally I don’t mind, happy to stick =
with PCN-region as currently used in draft-chan-problem-statement. =

 
A2      "PIN =
Term" Issue 
Should we use the terminology PCN Interior =
Node or PCN Intermediate Node =
(function)?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 RFC2475 supports use of PCN Interior =
Node
Personally I slightly prefer PCN Interior =
Node, though I don’t mind much. So happy to stick with PCN =
Interior Node as currently used in =
draft-chan-problem-statement
 
 
A3      "PEN =
Term" Issue
Should we use the terminology PCN End Node or =
PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway =
Node (function)?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 The term currently used in =
draft-chan-problem-statement is PCN End =
Node
 
Personally I don’t like the term PCN =
End Node – the problem is that it will probably get shortened to =
end node (already seen this happening on the list). I think this will =
get confusing as [1] the innocent may think it means ‘end =
host’; [2] the deployment models will probably show how PCN fits =
into the ‘big picture’ of end-to-end QoS, in which case =
we’d have both end hosts & PCN End Nodes. =

 
I also think PCN Gateway Node (function) =
could be slightly confusing. The actual physical node where the =
“PCN End Node” function sits is typically the =
PCN-region’s gateway node, but it could in some deployment =
situations be an end host, if the PCN-region extends out that far. =

 
PCN Boundary Node would be consistent with =
rfc2474 terminology.
PCN Border Node is a similar possibility that =
Michael has suggested. 
 
PCN Edge Node allows us to continue to use =
the nice acronym PEN, with its hint of ‘penning in’ the =
PCN-region. 
 
I favour PCN Edge Node, and also ok with PCN =
Boundary / Border Node
 

 

A4    “Pre-emption = Marking term” Issue

Pre-emption = Marking may seem to indicate the requirement of pre-empting existing flows/sessions = to allow additional new flows/sessions to be admitted.  This scenario = is not allowed in some markets due to regulations.  Should a better term = be used instead of Pre-emption Marking to indicate the need to reduce the = offered traffic load to the congested portions of the = network?

Michael suggested “excess traffic = mark” – what do you reckon?

 

Best wishes

phil

------_=_NextPart_001_01C6E647.41C2A4FF-- --===============0802757767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0802757767==-- From pcn-bounces@ietf.org Mon Oct 02 16:48:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUiT-0000Pg-8F; Mon, 02 Oct 2006 16:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUiS-0000OM-RW for pcn@ietf.org; Mon, 02 Oct 2006 16:48:44 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUUiR-0006X8-BT for pcn@ietf.org; Mon, 02 Oct 2006 16:48:44 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k92Kmex21663; Mon, 2 Oct 2006 16:48:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Issue A4 Preemption Marking Term Date: Mon, 2 Oct 2006 16:48:39 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650C645749@zcarhxm1.corp.nortel.com> In-Reply-To: <452146C2.6020506@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issue A4 Preemption Marking Term thread-index: AcbmRWCeuuKPAujhRty0JULO3euwQAAHmmQA From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Yes Michael I see your point. I'm OK with "admissible link rate". Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Monday, October 02, 2006 1:05 PM To: Babiarz, Jozef (CAR:0S03) Cc: philip.eardley@bt.com; pcn@ietf.org Subject: Re: [PCN] Issue A4 Preemption Marking Term Hi, I think that the word "link" in "admissible link rate" indicates that=20 the respective rate is link specific in contrast to the=20 "border-to-border (b2b)" (received, admission-stop, excess traffic)=20 rates (or estimates) that are measured at the egress per b2b aggregate.=20 Thus, the "link" within the term avoids misunderstandings with other=20 possible scopes (e.g. admissible rate for a specific ingress, admissible rate for specific b2b aggregates, ...). Initially, I had a hard time to=20 understand the draft since the scope of the rates was not clear to me.=20 If we know what we mean, we don't need the "link", but it makes it=20 easier for new people to understand the architecture. Best wishes, Michael Jozef Babiarz wrote: > I like what Michael is suggesting with the following minor changes. > "admissible rate" drop the word link because only some of the traffic on > the link is being measured e.g., per service class.=20 > I'm OK with "admission stop marking" or just "admission marking" meaning > this is when admission of additional flows should be stopped. > > For the second level I support using "supportable rate" and for the > marking "excess traffic marking" where the excess traffic is greater > then the configured supportable rate and may or may not be above the > actual link rate. I would expect that normally supportable rate would > loss that link rate and possible less than the forwarding rate of the > queue used. Preemption is an action of removing flows that some solution > may take to get ride of excess traffic and return to provide good QoS to > remaining traffic. > > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: Monday, October 02, 2006 11:21 AM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Issue A4 Preemption Marking Term > > Hi, > > what do you think about the terms > > * admissible link rate and "admission stop marking" using an admission > stop bit > * tolerable link rate and "excess traffic marking" using an excess=20 > traffic bit > * supportED link rate (now =3D physical or virtual link rate used for=20 > interface traffic shaping (Phil), but I'm not sure whether this=20 > expression is required at all: maybe just link rate?) > > Admission control is a requirement in our context, but preemption is=20 > just an option when the tolerable link rate is exceeded (I think I read=20 > that somewhere). Therefore, I don't like the term "preemption marking" > since this suggests preemption as mandatory. IF preemption is a=20 > mandatory feature, the term preemption marking is fine. > > Regards, > > Michael > > philip.eardley@bt.com wrote: > =20 >> Not sure I like this, as the idea of this (pre-emption) marking is=20 >> that action is taken so the link should never be congested. >> >> Perhaps "severe pre-congestion marking"? >> >> -----Original Message----- >> *From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> *Sent:* 02 October 2006 15:52 >> *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >> *Cc:* pcn@ietf.org >> *Subject:* RE: [PCN] Issue A4 Preemption Marking Term >> >> Hi Kwock >> >> What about using the term "severe congestion marking"? >> >> Best Regards, >> >> Georgios >> >> >> =20 > ------------------------------------------------------------------------ > =20 >> *From:* Kwok-Ho Chan [mailto:khchan@nortel.com] >> *Sent:* maandag 2 oktober 2006 16:43 >> *To:* philip.eardley@bt.com >> *Cc:* pcn@ietf.org >> *Subject:* Re: [PCN] Issue A4 Preemption Marking Term >> >> Some other suggestions related to Issue A4 of: >> >> >> A4 "Pre-emption Marking term" Issue >> >> Pre-emption Marking may seem to indicate the requirement of=20 >> pre-empting existing flows/sessions to allow additional new=20 >> flows/sessions to be admitted. This scenario is not allowed in some=20 >> markets due to regulations. Should a better term be used instead of=20 >> Pre-emption Marking to indicate the need to reduce the offered traffic >> =20 > > =20 >> load to the congested portions of the network? >> >> Michael suggested "excess traffic mark" - what do you reckon? >> >> >> How about the terms of: >> "Admissible Rate Marking" for the marking indication of exceeding the >> "Admissible Rate" >> and >> "Supportable Rate Marking" for the marking indication of exceeding the >> =20 > > =20 >> "Supportable Rate" ? >> >> It is then up to the Policy Decision to take the appropriate action=20 >> when the rate of traffic is >> not "Supportable" anymore. With Preemption being one of the possible=20 >> policy decision actions. >> >> Thanks! >> -- Kwok -- >> >> At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >> >> Content-class: urn:content-classes:message >> Content-Type: multipart/alternative; >> boundary=3D"----_=3D_NextPart_001_01C6E62C.6FE1DFFF" >> >> Thought I'd try to close a >> few more of the Issues - covering the Issues "A. Terminology Issues" >> listed at >> _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ >> >> =20 >> >> =20 >> A1 "PCN-Region Term" Issue >> >> Should the region running >> the PCN mechanism be called the PCN-Region or >> PCN-Domain? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> RFC2998 supports use >> of Region, RFC2474 supports use of >> Domain. >> >> Personally I don't mind, >> happy to stick with PCN-region as currently used in >> draft-chan-problem-statement. >> >> =20 >> >> =20 >> A2 "PIN Term" Issue >> >> Should we use the >> terminology PCN Interior Node or PCN Intermediate Node >> (function)? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> RFC2475 supports use >> of PCN Interior >> Node >> >> Personally I slightly >> prefer PCN Interior Node, though I don't mind much. So happy to stick >> with PCN Interior Node as currently used in >> draft-chan-problem-statement >> >> =20 >> >> =20 >> >> =20 >> A3 "PEN Term" >> Issue >> >> Should we use the >> terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >> Border Node or PCN Gateway Node >> (function)? >> >> Reference: >> draft-chan-problem-statement-00.txt section >> 2.1. >> >> The term currently >> used in draft-chan-problem-statement is PCN End >> Node >> >> =20 >> >> Personally I don't like the >> term PCN End Node - the problem is that it will probably get shortened >> =20 > to > =20 >> end node (already seen this happening on the list). I think this will >> =20 > get > =20 >> confusing as [1] the innocent may think it means 'end host'; [2] the >> deployment models will probably show how PCN fits into the 'big >> =20 > picture' > =20 >> of end-to-end QoS, in which case we'd have both end hosts & PCN End >> Nodes.=20 >> >> =20 >> >> I also think PCN Gateway >> Node (function) could be slightly confusing. The actual physical node >> where the "PCN End Node" function sits is typically the PCN-region's >> gateway node, but it could in some deployment situations be an end >> =20 > host, > =20 >> if the PCN-region extends out that far. >> >> =20 >> >> PCN Boundary Node would be >> consistent with rfc2474 >> terminology. >> >> PCN Border Node is a >> similar possibility that Michael has suggested. >> >> =20 >> >> PCN Edge Node allows us to >> continue to use the nice acronym PEN, with its hint of 'penning in' >> =20 > the > =20 >> PCN-region.=20 >> >> =20 >> >> I favour PCN Edge Node, and >> also ok with PCN Boundary / Border >> Node >> >> =20 >> >> >> A4 "Pre-emption Marking term" Issue >> Pre-emption Marking may seem to indicate the requirement of=20 >> pre-empting existing flows/sessions to allow additional new=20 >> flows/sessions to be admitted. This scenario is not allowed in some=20 >> markets due to regulations. Should a better term be used instead of=20 >> Pre-emption Marking to indicate the need to reduce the offered traffic >> =20 > > =20 >> load to the congested portions of the network? >> Michael suggested "excess traffic mark" - what do you reckon? >> >> Best wishes >> phil >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> =20 >> =20 > > =20 --=20 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 From pcn-bounces@ietf.org Wed Oct 04 03:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0qc-00054i-Ev; Wed, 04 Oct 2006 03:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0qb-00054b-6B for pcn@ietf.org; Wed, 04 Oct 2006 03:07:17 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0qY-000547-P0 for pcn@ietf.org; Wed, 04 Oct 2006 03:07:17 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 4 Oct 2006 09:07:02 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 09:07:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Issue A4 Preemption Marking Term X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Oct 2006 09:07:00 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8A0@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <9671A92C3C8B5744BC97F855F7CB64650C645749@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issue A4 Preemption Marking Term Thread-Index: AcbmZDPZZsT8fukIQuaBoXgzWCkL+gBHydDg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 04 Oct 2006 07:07:01.0189 (UTC) FILETIME=[B0576F50:01C6E783] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I agree too, Regards, Rudiger |I'm OK with "admissible link rate". | |Regards, Joe |QoS & Network Architecture |Telephone: 613-763-6098 (ESN 393-6098) |Email: babiarz@nortel.com |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 |Sent: Monday, October 02, 2006 1:05 PM |To: Babiarz, Jozef (CAR:0S03) |Cc: philip.eardley@bt.com; pcn@ietf.org |Subject: Re: [PCN] Issue A4 Preemption Marking Term | |Hi, | |I think that the word "link" in "admissible link rate" indicates that=20 |the respective rate is link specific in contrast to the=20 |"border-to-border (b2b)" (received, admission-stop, excess traffic)=20 |rates (or estimates) that are measured at the egress per b2b=20 |aggregate.=20 |Thus, the "link" within the term avoids misunderstandings with other=20 |possible scopes (e.g. admissible rate for a specific ingress,=20 |admissible | |rate for specific b2b aggregates, ...). Initially, I had a=20 |hard time to=20 |understand the draft since the scope of the rates was not clear to me.=20 |If we know what we mean, we don't need the "link", but it makes it=20 |easier for new people to understand the architecture. | |Best wishes, | | Michael _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 04 03:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV1KM-0001JC-N4; Wed, 04 Oct 2006 03:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV1KL-0001I1-0T for pcn@ietf.org; Wed, 04 Oct 2006 03:38:01 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV1KG-0003Lm-3T for pcn@ietf.org; Wed, 04 Oct 2006 03:38:00 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 08:37:54 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Oct 2006 08:37:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Issues A1, A2, A3, A4 Date: Wed, 4 Oct 2006 08:37:54 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD25@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650C6451A3@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Issues A1, A2, A3, A4 Thread-Index: AcbmLG/WigOHnm5QRWyfx4HM9/h/cwAFeONAAFEdhqA= From: To: , X-OriginalArrivalTime: 04 Oct 2006 07:37:54.0572 (UTC) FILETIME=[010B3CC0:01C6E788] X-Spam-Score: 0.8 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887402176==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0887402176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E788.00C7FA9F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E788.00C7FA9F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A possibility to solve this is to call it the "PCN Edge Node" and re-name what's in the cl-architecture draft the "gateway-to-gateway" deployment model =20 Any other opinions? =20 -----Original Message----- From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 Sent: 02 October 2006 18:22 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Issues A1, A2, A3, A4 =20 =20 Phil on issue A3. We have at least two deployment model that we would like the PCN mechanism to be feasible in. One is the "edge-to-edge deployment model as explained in cl-architecture draft and the second being SIP controlled admission and preemption which I will send a draft out in few days.=20 =20 In the edge-to-edge case decisions are made in network edge nodes which is the end node for PCN and in the SIP controlled model, the decision is make in the SIP controlled endpoint which is an application or service control point. In SIP case the PCN end node is a phone, media gateway, multi media terminal, boundary gateway, etc.=20 =20 To be generic and so that it works for both models, I like PCN End Node. =20 Regards, Joe=20 QoS & Network Architecture=20 Telephone: 613-763-6098 (ESN 393-6098)=20 Email: babiarz@nortel.com=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, October 02, 2006 10:10 AM To: pcn@ietf.org Subject: [PCN] Issues A1, A2, A3, A4 =20 Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt=20 =20 A1 "PCN-Region Term" Issue=20 Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement.=20 =20 A2 "PIN Term" Issue=20 Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement =20 =20 A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node =20 Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes.=20 =20 I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far.=20 =20 PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested.=20 =20 PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region.=20 =20 I favour PCN Edge Node, and also ok with PCN Boundary / Border Node =20 =20 A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? =20 Best wishes phil ------_=_NextPart_001_01C6E788.00C7FA9F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A possibility to solve this is to = call it the “PCN Edge = Node” and re-name what’s in the cl-architecture = draft the “gateway-to-gateway” deployment model

 

Any other = opinions?

 

-----Original Message-----
From: Jozef Babiarz [mailto:babiarz@nortel.com]
Sent: 02 October 2006 = 18:22
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] Issues = A1, A2, A3, A4

 

 

Phil on issue = A3.

We have at least = two deployment model that we would like the PCN mechanism to be feasible = in.

One is the “edge-to-edge deployment model as explained in cl-architecture = draft and the second being SIP controlled admission and preemption which I will = send a draft out in few days.

 

In the = edge-to-edge case decisions are made in network edge nodes which is the end node for PCN = and in the SIP controlled model, the decision is make in the SIP controlled = endpoint which is an application or service control point. In SIP case the PCN = end node is a phone, media gateway, multi media terminal, boundary gateway, etc. =

 

To be generic = and so that it works for both models, I like PCN End Node.  

 

Regards, = Joe
QoS & = Network Architecture
Telephone: = 613-763-6098 (ESN 393-6098)
Email: = babiarz@nortel.com

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, October 02, = 2006 10:10 AM
To: pcn@ietf.org
Subject: [PCN] Issues A1, = A2, A3, A4

 

Thought I’d try to close a few more of =
the Issues – covering the Issues “A. Terminology =
Issues” listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
A1      =
"PCN-Region Term" Issue 
Should =
the region running the PCN mechanism be called the PCN-Region or =
PCN-Domain?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 RFC2998 =
supports use of Region, RFC2474 supports use of =
Domain.
Personally I don’t mind, happy to stick =
with PCN-region as currently used in draft-chan-problem-statement. =

 
A2      "PIN =
Term" Issue 
Should we =
use the terminology PCN Interior Node or PCN Intermediate Node =
(function)?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 RFC2475 =
supports use of PCN Interior Node
Personally I slightly prefer PCN Interior =
Node, though I don’t mind much. So happy to stick with PCN =
Interior Node as currently used in =
draft-chan-problem-statement
 
 
A3      "PEN =
Term" Issue
Should we =
use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node =
or PCN Border Node or PCN Gateway Node =
(function)?
 =
Reference: draft-chan-problem-statement-00.txt section =
2.1.
 The term =
currently used in draft-chan-problem-statement is PCN End =
Node
 
Personally I don’t like the term PCN =
End Node – the problem is that it will probably get shortened to =
end node (already seen this happening on the list). I think this will =
get confusing as [1] the innocent may think it means ‘end =
host’; [2] the deployment models will probably show how PCN fits =
into the ‘big picture’ of end-to-end QoS, in which case =
we’d have both end hosts & PCN End Nodes. =

 
I also =
think PCN Gateway Node (function) could be slightly confusing. The =
actual physical node where the “PCN End Node” function sits =
is typically the PCN-region’s gateway node, but it could in some =
deployment situations be an end host, if the PCN-region extends out that =
far. 
 
PCN =
Boundary Node would be consistent with rfc2474 =
terminology.
PCN =
Border Node is a similar possibility that Michael has suggested. =

 
PCN Edge =
Node allows us to continue to use the nice acronym PEN, with its hint of =
‘penning in’ the PCN-region. 
 
I favour =
PCN Edge Node, and also ok with PCN Boundary / Border =
Node
 
=

 

A4    “Pre-emption Marking term” Issue

Pre-emption Marking may = seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted.  This scenario is not allowed in some markets due to regulations.  Should a better term = be used instead of Pre-emption Marking to indicate the need to reduce the = offered traffic load to the congested portions of the network?

Michael suggested “excess traffic mark” – what do you reckon?

 

Best wishes

phil

=00 ------_=_NextPart_001_01C6E788.00C7FA9F-- --===============0887402176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0887402176==-- From pcn-bounces@ietf.org Wed Oct 04 05:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV2jp-0001ki-3m; Wed, 04 Oct 2006 05:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV2jn-0001kb-R3 for pcn@ietf.org; Wed, 04 Oct 2006 05:08:23 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV2jk-0008HM-0q for pcn@ietf.org; Wed, 04 Oct 2006 05:08:23 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9497ome015175; Wed, 4 Oct 2006 11:08:10 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jozef Babiarz'" , , Subject: RE: [PCN] Issues A1, A2, A3, A4 Date: Wed, 4 Oct 2006 11:07:46 +0200 Message-ID: <000a01c6e794$9b9558f0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbmLG/WigOHnm5QRWyfx4HM9/h/cwAFeONAAFRswkA= In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650C6451A3@zcarhxm1.corp.nortel.com> X-Spam-Score: -5.619 () ALL_TRUSTED, AWL, BAYES_00, HTML_FONT_BIG, HTML_MESSAGE, HTML_NONELEMENT_00_10 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 04 Oct 2006 11:08:15 +0200 (MEST) X-Spam-Score: 0.2 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1216464483==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1216464483== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C6E7A5.5F1E28F0" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C6E7A5.5F1E28F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Phil I agree with Joe, I like PCN End Node. Furthermore, the term associated with A2, in order to also be generic and be able to cover well both models, I like the term: PCN Intermediate Node. Best regards, Georgios _____ From: Jozef Babiarz [mailto:babiarz@nortel.com] Sent: maandag 2 oktober 2006 19:22 To: philip.eardley@bt.com; pcn@ietf.org Subject: RE: [PCN] Issues A1, A2, A3, A4 Phil on issue A3. We have at least two deployment model that we would like the PCN mechanism to be feasible in. One is the "edge-to-edge deployment model as explained in cl-architecture draft and the second being SIP controlled admission and preemption which I will send a draft out in few days. In the edge-to-edge case decisions are made in network edge nodes which is the end node for PCN and in the SIP controlled model, the decision is make in the SIP controlled endpoint which is an application or service control point. In SIP case the PCN end node is a phone, media gateway, multi media terminal, boundary gateway, etc. To be generic and so that it works for both models, I like PCN End Node. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com _____ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 02, 2006 10:10 AM To: pcn@ietf.org Subject: [PCN] Issues A1, A2, A3, A4 Thought I'd try to close a few more of the Issues - covering the Issues "A. Terminology Issues" listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt A1 "PCN-Region Term" Issue Should the region running the PCN mechanism be called the PCN-Region or PCN-Domain? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2998 supports use of Region, RFC2474 supports use of Domain. Personally I don't mind, happy to stick with PCN-region as currently used in draft-chan-problem-statement. A2 "PIN Term" Issue Should we use the terminology PCN Interior Node or PCN Intermediate Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. RFC2475 supports use of PCN Interior Node Personally I slightly prefer PCN Interior Node, though I don't mind much. So happy to stick with PCN Interior Node as currently used in draft-chan-problem-statement A3 "PEN Term" Issue Should we use the terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN Border Node or PCN Gateway Node (function)? Reference: draft-chan-problem-statement-00.txt section 2.1. The term currently used in draft-chan-problem-statement is PCN End Node Personally I don't like the term PCN End Node - the problem is that it will probably get shortened to end node (already seen this happening on the list). I think this will get confusing as [1] the innocent may think it means 'end host'; [2] the deployment models will probably show how PCN fits into the 'big picture' of end-to-end QoS, in which case we'd have both end hosts & PCN End Nodes. I also think PCN Gateway Node (function) could be slightly confusing. The actual physical node where the "PCN End Node" function sits is typically the PCN-region's gateway node, but it could in some deployment situations be an end host, if the PCN-region extends out that far. PCN Boundary Node would be consistent with rfc2474 terminology. PCN Border Node is a similar possibility that Michael has suggested. PCN Edge Node allows us to continue to use the nice acronym PEN, with its hint of 'penning in' the PCN-region. I favour PCN Edge Node, and also ok with PCN Boundary / Border Node A4 "Pre-emption Marking term" Issue Pre-emption Marking may seem to indicate the requirement of pre-empting existing flows/sessions to allow additional new flows/sessions to be admitted. This scenario is not allowed in some markets due to regulations. Should a better term be used instead of Pre-emption Marking to indicate the need to reduce the offered traffic load to the congested portions of the network? Michael suggested "excess traffic mark" - what do you reckon? Best wishes phil ------=_NextPart_000_000B_01C6E7A5.5F1E28F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil
 
I agree with Joe, I like PCN End = Node.
Furthermore, the term associated with A2,=20
in order to also be generic and be able to = cover well both=20 models, I like the term:
PCN Intermediate Node.
 
Best regards,
Georgios
 

From: Jozef Babiarz = [mailto:babiarz@nortel.com]=20
Sent: maandag 2 oktober 2006 19:22
To:=20 philip.eardley@bt.com; pcn@ietf.org
Subject: RE: [PCN] Issues = A1, A2,=20 A3, A4

 

Phil on issue = A3.

We have at = least two=20 deployment model that we would like the PCN mechanism to be feasible=20 in.

One is the=20 “edge-to-edge deployment model as explained in cl-architecture = draft and the=20 second being SIP controlled admission and preemption which I will send a = draft=20 out in few days.

 

In the = edge-to-edge=20 case decisions are made in network edge nodes which is the end node for = PCN and=20 in the SIP controlled model, the decision is make in the SIP controlled = endpoint=20 which is an application or service control point. In SIP case the PCN = end node=20 is a phone, media gateway, multi media terminal, boundary gateway, etc.=20

 

To be generic = and so=20 that it works for both models, I like PCN End Node.=20  

 

Regards,=20 Joe=20
QoS & = Network=20 Architecture=20
Telephone: = 613-763-6098=20 (ESN 393-6098)=20
Email: = babiarz@nortel.com =

From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, October 02, 2006 = 10:10=20 AM
To: = pcn@ietf.org
Subject: [PCN] Issues A1, A2, A3, = A4

 

Thought I’d try to close a few more of the Issues – =
covering the Issues “A. Terminology Issues” listed at http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt 
 
A1      "PCN-Region Term" Issue =

Should the region =
running the PCN mechanism be called the PCN-Region or =
PCN-Domain?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 RFC2998 supports =
use of Region, RFC2474 supports use of =
Domain.
Personally I =
don’t mind, happy to stick with PCN-region as currently used in =
draft-chan-problem-statement. 
 
A2      "PIN Term" Issue =

Should we use the =
terminology PCN Interior Node or PCN Intermediate Node =
(function)?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 RFC2475 supports =
use of PCN Interior Node
Personally I slightly prefer PCN Interior Node, though I =
don’t mind much. So happy to stick with PCN Interior Node as =
currently used in =
draft-chan-problem-statement
 
 
A3      "PEN Term" =
Issue
Should we use the =
terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN =
Border Node or PCN Gateway Node =
(function)?
 Reference: =
draft-chan-problem-statement-00.txt section =
2.1.
 The term =
currently used in draft-chan-problem-statement is PCN End =
Node
 
Personally I =
don’t like the term PCN End Node – the problem is that it =
will probably get shortened to end node (already seen this happening on =
the list). I think this will get confusing as [1] the innocent may think =
it means ‘end host’; [2] the deployment models will probably =
show how PCN fits into the ‘big picture’ of end-to-end QoS, =
in which case we’d have both end hosts & PCN End Nodes. =

 
I also think =
PCN Gateway Node (function) could be slightly confusing. The actual =
physical node where the “PCN End Node” function sits is =
typically the PCN-region’s gateway node, but it could in some =
deployment situations be an end host, if the PCN-region extends out that =
far. 
 
PCN Boundary =
Node would be consistent with rfc2474 =
terminology.
PCN Border =
Node is a similar possibility that Michael has suggested. =

 
PCN Edge Node =
allows us to continue to use the nice acronym PEN, with its hint of =
‘penning in’ the PCN-region. =

 
I favour PCN =
Edge Node, and also ok with PCN Boundary / Border =
Node
 

 

A4    = “Pre-emption=20 Marking term” Issue

Pre-emption = Marking may=20 seem to indicate the requirement of pre-empting existing flows/sessions = to allow=20 additional new flows/sessions to be admitted.  This scenario is not = allowed=20 in some markets due to regulations.  Should a better term be used = instead=20 of Pre-emption Marking to indicate the need to reduce the offered = traffic load=20 to the congested portions of the network?

Michael suggested = “excess traffic=20 mark” – what do you reckon?

 

Best = wishes

phil

------=_NextPart_000_000B_01C6E7A5.5F1E28F0-- --===============1216464483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1216464483==-- From pcn-bounces@ietf.org Thu Oct 05 08:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRwK-0001HW-46; Thu, 05 Oct 2006 08:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRwJ-0001HR-Cb for pcn@ietf.org; Thu, 05 Oct 2006 08:02:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVRwD-0001HS-2b for pcn@ietf.org; Thu, 05 Oct 2006 08:02:59 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 123478E001B for ; Thu, 5 Oct 2006 14:02:03 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:02:02 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:02:02 +0200 Message-ID: <4524F43A.2070803@ericsson.com> Date: Thu, 05 Oct 2006 14:02:02 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 12:02:02.0232 (UTC) FILETIME=[1165FF80:01C6E876] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [PCN] Announcement of BOF chairs X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org The TSV ADs have appointed: Scott Bradner (sob@harvard.edu) Anna Charny (acharny@cisco.com) as chairs for this BOF. Best Regards Magnus Westerlund TSV AD _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 05 15:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZ1y-0006Vz-2z; Thu, 05 Oct 2006 15:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZ1w-0006Ub-JT for pcn@ietf.org; Thu, 05 Oct 2006 15:37:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZ1u-000359-8D for pcn@ietf.org; Thu, 05 Oct 2006 15:37:16 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 12:37:14 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="328499613:sNHT48730332" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95JbDMb000315; Thu, 5 Oct 2006 12:37:13 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k95Jb4Oh029864; Thu, 5 Oct 2006 12:37:13 -0700 (PDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 15:37:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Oct 2006 15:37:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: call for PCN BOF agenda slots and discussion items Thread-Index: AcbotaFjrdlxo6hMRpGMfwU+BFNY8Q== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 05 Oct 2006 19:37:03.0027 (UTC) FILETIME=[A1F0B830:01C6E8B5] DKIM-Signature: a=rsa-sha1; q=dns; l=996; t=1160077033; x=1160941033; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:call=20for=20PCN=20BOF=20agenda=20slots=20and=20discussion=20items; X=v=3Dcisco.com=3B=20h=3D6vkd/+fpxXqjymFOp891D4xd0jU=3D; b=C7EURmmXsmZNRwHuHEan2ok3gOUDna5U/z1WJDBicTe+3Id0BAllnxpihchP/f/fpdGnEY2a pIrVeBKDxf+R1sAxSeaalZiRKlc88m9o4ux7VPO5kNxqfWhER3MwXuUb; Authentication-Results: sj-dkim-5.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [PCN] call for PCN BOF agenda slots and discussion items X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear all, PCN BOF draft agenda has been posted to the list. We are soliciting agenda slot requests and agenda items for the BOF. Note that we are looking to discuss issues rather than make presentations about Internet drafts. Two issues currently raised on the list are: - should handling 911 calls in the PCN region be within the scope of the PCN WG (should it be created) - should PCN over MPLS be within the scope of the PCN WG (should it be created) A partial set of other issues raised on the list so far is available from http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt.=20 The site http://standards.nortel.com/pcn (courtesy Kwok Chan) also contains the proposed charter, BOF description and initial draft agenda, as well as the Problem Statement draft.=20 Please send us agenda requests by 6 pm ET October 15. Also a reminder that -00 draft submission deadline is 9:00 ET October 16. Best Regards, Anna and Scott PCN BOF Chairs _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 06 06:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVn7C-0008DL-Au; Fri, 06 Oct 2006 06:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVn7B-00087B-2X for pcn@ietf.org; Fri, 06 Oct 2006 06:39:37 -0400 Received: from hermes.hosts.co.uk ([85.233.160.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVn79-00076x-OB for pcn@ietf.org; Fri, 06 Oct 2006 06:39:37 -0400 Received: from [69.250.221.255] (helo=[192.168.1.3]) by hermes.hosts.co.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.63) (envelope-from ) id 1GVn70-0004ZD-As; Fri, 06 Oct 2006 11:39:26 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [PCN] call for PCN BOF agenda slots and discussion items Date: Fri, 6 Oct 2006 06:38:55 -0400 To: "Anna Charny \(acharny\)" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -1.4 (-) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > PCN BOF draft agenda has been posted to the list. We are soliciting > agenda slot requests and agenda items for the BOF. Note that we are > looking to discuss issues rather than make presentations about > Internet > drafts. > > Two issues currently raised on the list are: > > - should handling 911 calls in the PCN region be within the scope > of the > PCN WG (should it be created) > > - should PCN over MPLS be within the scope of the PCN WG (should it be > created) just a thought, but if someone is going to give a presentation on "should item X" be within scope of the WG, it would really be cool if they could also act as their own devil's advocate and toss up a reason or two as to why it should not. this "other view" could either come from what they saw posted on the list related to the subject, or their own opinion given that there are trade-offs in every decision/direction. my thought behind this is that it may shorten the given-and-take at the mike by getting to the heart of a potential debate as soon as possible. also, awhile back on the list, there was the thought of presenting some simulation work as a way of strengthening some earlier stated positions. my observations in the past when seeing simulation results is that presenters end up showing too many and the audience gets lost looking at the trees from the forest. it would be nice if we the audience could catch the point with as few simulation results as possible (like 1 or 2?? :-). and if further results exists, just point us to a website. cheers, -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 06 09:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqDa-0001sG-8x; Fri, 06 Oct 2006 09:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqDP-0001XL-2W for pcn@ietf.org; Fri, 06 Oct 2006 09:58:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVpzB-00079Q-9B for pcn@ietf.org; Fri, 06 Oct 2006 09:43:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2006 06:43:22 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="45095492:sNHT283653156" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96DhHVh027312; Fri, 6 Oct 2006 09:43:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k96DhGYJ009120; Fri, 6 Oct 2006 09:43:17 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 09:43:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] call for PCN BOF agenda slots and discussion items Date: Fri, 6 Oct 2006 09:43:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] call for PCN BOF agenda slots and discussion items Thread-Index: AcbpM7vFgivQIvQ0TjKZt6WZN8oq+AAGAxUQ From: "Anna Charny \(acharny\)" To: "ken carlberg" X-OriginalArrivalTime: 06 Oct 2006 13:43:16.0777 (UTC) FILETIME=[6085C190:01C6E94D] DKIM-Signature: a=rsa-sha1; q=dns; l=1841; t=1160142197; x=1161006197; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20call=20for=20PCN=20BOF=20agenda=20slots=20and=20discussi on=20items |To:=22ken=20carlberg=22=20; X=v=3Dcisco.com=3B=20h=3DJ4I/MIxDJnhbDJCnwbA5qkAbPFw=3D; b=NURvcmE1Wl87+nXo7/Bo52dhhsbOnoLGzyT5pElCIgRb0BO527jfIGW9clz2fqCyWmOwYP8E Fwz/iAE2QZTKgxv/RVlpqG/YwR+11z+vnlkcXg5xLbo8BdAcYiqpMtTR; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ken,=20 >just a thought, but if someone is going to give a presentation on "should >item X" be within scope of the WG, it would really be cool if they could=20 >also act as their own devil's advocate and toss up a reason or two as to >why it should not. this "other view" could either come from what they >saw posted on the list related to the subject, or their own opinion given >that there are trade-offs in every decision/direction. my thought behind >this is that it may shorten the given-and-take at the mike by getting to >the heart of a potential debate as soon as possible. Sounds like generically good advice for a balanced presentation of ones views :-) >also, awhile back on the list, there was the thought of presenting some >simulation work as a way of strengthening some earlier stated positions.=20 My understanding is that the promised simulations were not so much in favor of strengthening any particular positions but rather the primary goal of them was to demonstrate technical feasibility of and/or highlight problems with the currently proposed solutions.=20 >my observations in the past when seeing simulation results is that=20 >presenters end up showing too many and the audience gets lost looking at >the trees from the forest. it would be nice if we the audience could=20 >catch the point with as few simulation results as possible (like 1 or 2?? >:-). and if further results exists, just point us to a website. The plan was to post the simulations but actually not spend any time discussing them at the BOF. Note that the simulations are not currently on the proposed agenda. Of course if there are any questions on those that cannot be answered on the list or if a strong need to add it to the agenda becomes evident, that can change. =20 Regards, Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 10 19:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXR1l-0007wV-4p; Tue, 10 Oct 2006 19:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXR1k-0007rk-0y for pcn@ietf.org; Tue, 10 Oct 2006 19:28:48 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXR1i-0005Kv-O9 for pcn@ietf.org; Tue, 10 Oct 2006 19:28:47 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9ANM9K28584 for ; Tue, 10 Oct 2006 19:22:09 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 19:28:43 -0400 Message-Id: <6.2.5.6.0.20061010185719.0342f930@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Oct 2006 19:28:43 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Oct 2006 23:28:43.0850 (UTC) FILETIME=[D38ABAA0:01C6ECC3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [PCN] ProblemStatement Issue NEW: Notion of TRUST X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: I am working on a new draft to be submitted for the PCN BOF (reason for my silence lately :). For this new draft, I had some private conversations with couple of people on the notion of TRUST. IMHO, I think this is a fundamental issue and needs to be explored for the PCN BOF/WG. So far we have indicated we want to solve the Flow Admission Control and Flow "Preemption" problem for a controlled environment (please see section 4.1 of -00 ProblemStatement draft). But we have not state in detail of the different trust relationships. Hence I would like to indicate here that we may want to think about trust relationships between (please see section 2.1 of -00 ProblemStatement for terminology definitions): 1. PCN Interior Node (PIN) and PIN. 2. PCN End Node (PEN) and PIN. 3. User/Application and PEN. For this #3, I am further asking: (a) in this case is PEN really representing PCN as a whole? (b) is this really about trust between Application Layer and Packet Forwarding Network Layer? Are there any other trust relationships we need to consider? The scope/degree of these trust relationships? How may some of these trust relationships be established? I would like to open this up to the list and gain some insights on what may be acceptable assumptions, approaches related to this topic. Thanks! -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 11 02:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXY1k-0004ii-4m; Wed, 11 Oct 2006 02:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXY1b-0004ei-Dm for pcn@ietf.org; Wed, 11 Oct 2006 02:57:07 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXzL-0002Zq-1b for pcn@ietf.org; Wed, 11 Oct 2006 02:54:48 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 11 Oct 2006 08:54:39 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 08:54:39 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] ProblemStatement Issue NEW: Notion of TRUST X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Oct 2006 08:54:38 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8C3@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <6.2.5.6.0.20061010185719.0342f930@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] ProblemStatement Issue NEW: Notion of TRUST Thread-Index: Acbsw9vvA46yxc6sS8qTf9VtwFbrgAAPcnZw From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 11 Oct 2006 06:54:39.0615 (UTC) FILETIME=[1F3878F0:01C6ED02] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok, good point, the issue should be part of the problem statement. The topic is probably one of the most tricky parts of PCN. By=20 that I mean that we have a fair chance to over-engineer a=20 solution. But on the other hand, we can't afford to ignore=20 the topic. Regards, Rudiger |-----Original Message----- |From: Kwok-Ho Chan [mailto:khchan@nortel.com] |Sent: Wednesday, October 11, 2006 1:29 AM |To: pcn@ietf.org |Subject: [PCN] ProblemStatement Issue NEW: Notion of TRUST | | |Hi all: |I am working on a new draft to be submitted for the PCN BOF (reason=20 |for my silence lately :). | |For this new draft, I had some private conversations with couple of=20 |people on the notion of TRUST. |IMHO, I think this is a fundamental issue and needs to be explored=20 |for the PCN BOF/WG. | |So far we have indicated we want to solve the Flow Admission Control=20 |and Flow "Preemption" |problem for a controlled environment (please see section 4.1 of -00=20 |ProblemStatement draft). |But we have not state in detail of the different trust relationships. | |Hence I would like to indicate here that we may want to think about=20 |trust relationships |between (please see section 2.1 of -00 ProblemStatement for=20 |terminology definitions): |1. PCN Interior Node (PIN) and PIN. |2. PCN End Node (PEN) and PIN. |3. User/Application and PEN. | For this #3, I am further asking: | (a) in this case is PEN really representing PCN as a whole? | (b) is this really about trust between Application Layer and=20 |Packet Forwarding Network Layer? | |Are there any other trust relationships we need to consider? |The scope/degree of these trust relationships? |How may some of these trust relationships be established? | |I would like to open this up to the list and gain some insights on=20 |what may be acceptable |assumptions, approaches related to this topic. | |Thanks! |-- Kwok -- | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 11 11:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXftL-00087K-N1; Wed, 11 Oct 2006 11:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXftK-000865-Jp for pcn@ietf.org; Wed, 11 Oct 2006 11:21:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXfeg-0003dY-R4 for pcn@ietf.org; Wed, 11 Oct 2006 11:06:00 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9BF5ra22207; Wed, 11 Oct 2006 11:05:54 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 11:05:37 -0400 Message-Id: <6.2.5.6.0.20061011105434.060f62d8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Oct 2006 11:05:27 -0400 To: "Geib, Ruediger" From: "Kwok-Ho Chan" Subject: RE: [PCN] ProblemStatement Issue NEW: Notion of TRUST In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8C3@S4DE8PSAAFQ.mitte.t -com.de> References: <6.2.5.6.0.20061010185719.0342f930@nortel.com> <6439282641581441A36F7F6F83ED2ED2CBF8C3@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Oct 2006 15:05:37.0902 (UTC) FILETIME=[B5BA58E0:01C6ED46] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger: At this point, IMHO, we need to at least understand how the notion of trust may affect PCN. We may not have all the answers or may not include them in the charter. But we should open this up and make conscientious decisions. I believe this is the right thing to do for the BOF/WG. Also, by opening this up, we may learn of solutions out there that we don't know of. I would like to include the result of these discussions into future versions of the Problem Statement draft if appropriate. Thanks! -- Kwok -- At 02:54 AM 10/11/2006, Geib, Ruediger wrote: >Hi Kwok, > >good point, the issue should be part of the problem statement. > >The topic is probably one of the most tricky parts of PCN. By >that I mean that we have a fair chance to over-engineer a >solution. But on the other hand, we can't afford to ignore >the topic. > >Regards, > >Rudiger > >|-----Original Message----- >|From: Kwok-Ho Chan [mailto:khchan@nortel.com] >|Sent: Wednesday, October 11, 2006 1:29 AM >|To: pcn@ietf.org >|Subject: [PCN] ProblemStatement Issue NEW: Notion of TRUST >| >| >|Hi all: >|I am working on a new draft to be submitted for the PCN BOF (reason >|for my silence lately :). >| >|For this new draft, I had some private conversations with couple of >|people on the notion of TRUST. >|IMHO, I think this is a fundamental issue and needs to be explored >|for the PCN BOF/WG. >| >|So far we have indicated we want to solve the Flow Admission Control >|and Flow "Preemption" >|problem for a controlled environment (please see section 4.1 of -00 >|ProblemStatement draft). >|But we have not state in detail of the different trust relationships. >| >|Hence I would like to indicate here that we may want to think about >|trust relationships >|between (please see section 2.1 of -00 ProblemStatement for >|terminology definitions): >|1. PCN Interior Node (PIN) and PIN. >|2. PCN End Node (PEN) and PIN. >|3. User/Application and PEN. >| For this #3, I am further asking: >| (a) in this case is PEN really representing PCN as a whole? >| (b) is this really about trust between Application Layer and >|Packet Forwarding Network Layer? >| >|Are there any other trust relationships we need to consider? >|The scope/degree of these trust relationships? >|How may some of these trust relationships be established? >| >|I would like to open this up to the list and gain some insights on >|what may be acceptable >|assumptions, approaches related to this topic. >| >|Thanks! >|-- Kwok -- >| >| >|_______________________________________________ >|PCN mailing list >|PCN@ietf.org >|https://www1.ietf.org/mailman/listinfo/pcn >| _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 13 11:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPGP-0001cy-AP; Fri, 13 Oct 2006 11:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPGO-0001co-Qn for pcn@ietf.org; Fri, 13 Oct 2006 11:47:56 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYPGD-0006FC-S3 for pcn@ietf.org; Fri, 13 Oct 2006 11:47:56 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 16:47:44 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Oct 2006 16:47:43 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1160754463177; Fri, 13 Oct 2006 16:47:43 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.215]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id k9DFldHK031348; Fri, 13 Oct 2006 16:47:41 +0100 Message-Id: <5.2.1.1.2.20061013153021.0377e6a0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 13 Oct 2006 16:47:42 +0100 To: "Kwok-Ho Chan" From: Bob Briscoe Subject: RE: [PCN] ProblemStatement Issue NEW: Notion of TRUST Mime-Version: 1.0 X-Spam-Score: -0.034 () ALL_TRUSTED,HTML_10_20,HTML_MESSAGE,MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 13 Oct 2006 15:47:43.0816 (UTC) FILETIME=[EC1DBC80:01C6EEDE] X-Spam-Score: 1.5 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2138158863==" Errors-To: pcn-bounces@ietf.org --===============2138158863== Content-Type: text/html; charset="us-ascii" Kwok,

At 11:05 AM 10/11/2006, Kwok-Ho Chan wrote:
Ruediger:
I would like to include the result of these discussions into
future versions of the Problem Statement draft if appropriate.

Feel free to use the description of the trust problem I've already written in section 3 of <draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>. Although that draft describes a solution, chartering that we will solve this problem is a different matter...

Trusting whether an upstream response will follow from downstream congestion, is a hard problem that is currently not possible in the Internet architecture. No other IETF activity has given itself a bar this high (TCP and every other IETF transport assumes trust in the upstream sender's response to congestion).

Nonetheless, re-ECN claims to solve this problem. It claims to ensure that the sender can be trusted to respond correctly to downstream congestion, and everyone in the feedback loop can be trusted to pass on congestion feedback honestly (without using crypto). And the above border-cheating I-D addresses this problem specifically for the edge-edge deployment model of PCN.

However, re-ECN currently proposes to use the last undefined bit in the IPv4 header so it's unlikely to happen in the same timeframe as we are hoping to get PCN work to standards track.

So, the current approach proposed for chartering the PCN w-g is to assume trust with respect to responding to congestion, just like all other IETF work does.

But, the trust issue is particularly acute for inelastic flows (which is why we need admission control). A few non-complying flows can make /all/ other competing flows useless.

In practice, PCN is actually further ahead on this issue than any other IETF activity. But in the PCN charter we shouldn't commit ourselves to /having/ to be further ahead than the Internet architecture allows. However, we should include this very important issue in the problem statement. And we should say it is the standards activity most likely to be added if/when the group re-charters after it has achieved it's initial objectives.

In particular, we should discuss how to allow space for a solution like re-ECN, when standardising a protocol encoding for PCN (re-PCN if you like). I outlined a possible encoding in the above border-cheating draft.

If we did want to standardise re-PCN into bit 48 of the IP header, the process isn't even clear. I think we could define it for experimental use within a controlled region. That seems to fits the sprit of the recently approved BCP on experiments in the IP header <draft-fenner-iana-exp-2780-05.txt>. But I can't get a clear answer from anyone whether it does. Before the BCP was issued, I pointed out to Bill Fenner that the BCP doesn't give the assignment process for bit 48, and he decided it was best to continue not to mention it.


Bob


____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 --===============2138158863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============2138158863==-- From pcn-bounces@ietf.org Fri Oct 13 12:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPsp-0000RZ-AP; Fri, 13 Oct 2006 12:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYPso-0000RR-24 for pcn@ietf.org; Fri, 13 Oct 2006 12:27:38 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYPsj-0006TI-BE for pcn@ietf.org; Fri, 13 Oct 2006 12:27:37 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9DGKiA06394; Fri, 13 Oct 2006 12:20:44 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 12:27:18 -0400 Message-Id: <6.2.5.6.0.20061013122142.03c54058@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Oct 2006 12:27:18 -0400 To: "GOLDMAN, STUART O \(STUART\)" From: "Kwok-Ho Chan" Subject: RE: ProblemStatement Issue B.9:Call Preemption Not AllowedIssue. Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt In-Reply-To: <7D096A439A3D0D48A3D10872022CFD091B4A84@ILEXC1U02.ndc.lucen t.com> References: <6.2.5.6.0.20060920113532.03deadb8@nortel.com> <7D096A439A3D0D48A3D10872022CFD091B4A84@ILEXC1U02.ndc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Oct 2006 16:27:18.0656 (UTC) FILETIME=[73A19000:01C6EEE4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: pcn@ietf.org, Shahram Davari , ken carlberg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Stuart: Sorry for the delayed response. Yes. Preemption may not always be needed. This may be covered by the notion of preferential admission (based on some preferences metric), hence more part of Admission Control. And may be less in the "preemption" part. But these detailed fine lines may need to be described and agreed with the formation of the WG. Thanks! -- Kwok -- At 01:37 PM 9/20/2006, GOLDMAN, STUART O \(STUART\) wrote: >Kwok-Ho, >While you seem to have only mentioned preemption, there should be ways >to recognize a call deserving higher than normal preference and giving >it that preference to the remaining network resources without having to >preempt a call in progress. Yes? > >Stuart Goldman >Lucent Technologies >sgoldman@lucent.com >602 493 8438 > > >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortel.com] >Sent: Wednesday, September 20, 2006 8:54 AM >To: Shahram Davari >Cc: pcn@ietf.org; ken carlberg >Subject: RE: ProblemStatement Issue B.9:Call Preemption Not >AllowedIssue. Used to be Re: [PCN] >draft-chan-pcn-problem-statement-00.txt > >Shahram: >I totally agree. >The cell phone network was also jammed during 9/11. >I was trying to reach my brother who were stuck in the subway >~2 stops from WTC. >So I know exactly how this feels like. But I prefer to let the >Police and Firemen to >use this resource to help the general public at large. > >The question becomes: >- Does the Emergency Services want to use the same physical network >as the general public? >-- If Yes. Then should the problem statement becomes: > "Some controlled preemption functionality is allowed for >Emergency purposes in the general > public integrated (voice, video, data, etc) network. This >controlled preemption functionality > needs to be supported by the network mechanisms." >-- If Yes. Then we will need some guidance and help wrt the >regulations of the different jurisdictions. > Also if the different jurisdictions even wants to use the same >network infrastructure for both > emergency and public usage purposes. If it is technically possible. > >By this I am not saying a good solution exist or that I am promoting >a specific solution. >I am just agreeing that this problem needs to be addressed. >We may end up saying we can not solve this problem as of yet. But I >wish we can solve it. > >Regards. >-- Kwok -- > > >At 09:34 AM 9/20/2006, Shahram Davari wrote: > >Kwok, > > > >Indeed you raised a good subject. The requirements for emergency > >services should be part of the problem statement, and be dealt with > >in the proposed solution draft. ITU-T has quite extensive work on > >the requirements for Emergency services. > > > >On a side note, one of the problems identified during a recent > >school shooting in Canada was that the emergency and police couldn't > >use the phone or cell phones to communicate because the network was > >jammed due to high volume of calls between students and their families. > > > >Yours, > >Shahram > > > > > > > -----Original Message----- > > > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > > > Sent: Tuesday, September 19, 2006 5:26 PM > > > To: ken carlberg > > > Cc: pcn@ietf.org > > > Subject: ProblemStatement Issue B.9:Call Preemption Not Allowed >Issue. > > > Used to be Re: [PCN] draft-chan-pcn-problem-statement-00.txt > > > > > > > > > Ken: > > > Thank you for handling so many of our replies at the same time. :) > > > > > > YES, on your point of: > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > We are using the Problem-Statement draft to put out an > > > initial version of what > > > we are thinking, as this is still work in progress, there definitely > > > are area we > > > may have missed. > > > > > > Thank you for pointing out at least one of them. > > > > > > I will write some additional text for -01 version of the Problem > > > Statement draft to try > > > and describe the problem you have indicated (but I will try NOT to > > > indicate any solution > > > in the Problem Statement draft). > > > > > > And we will try to have some text in at least some of our Deployment > > > Model drafts > > > to see if there are good solutions to the problem you > > > indicated. There may be > > > more than one solution as there may be more than one Deployment >Model. > > > > > > Please Notice I have changed the subject of the E-Mail thread for > > > issue tracking purpose. > > > Please use this E-Mail Subject for continuing this discussion. > > > > > > Now I have additional questions concerning the use of Preemption for > > > handling Emergency > > > Services. Will Preemption be allowed for Emergency Services? > > > Does some of the > > > jurisdiction you have indicated want to use a separate network for > > > Emergency Services > > > purpose? Will combining Emergency Services with the normal > > > VoIP calls/sessions > > > be a good Problem Statement that we can add to our Problem > > > Statement draft? > > > > > > I am concentrating on Problem Statement instead of Solutions > > > for now because we > > > want to get the Problem Statement cleared away first for the > > > BOF purpose. > > > > > > Thanks! > > > -- Kwok -- > > > > > > At 12:13 PM 9/19/2006, ken carlberg wrote: > > > >Anna, > > > > > > > >>>maybe we have a different perspective of preemption. as I view >it, > > > >>>preemption is removing *existing* state (circuit in the PSTN > > > >>>world) in > > > >>>favor of new state. > > > >> > > > >>I guess that may be one thing that needs clarification. The way I > > > >>view > > > >>it (and I think the way draft-chan-pcn-problem-statement-00.txt >and > > > >>related docs view the issue) is that pre-emption should kick in > > > >>when for > > > >>whatever reason provisioning mechanisms fail there simply is not > > > >>enough > > > >>capacity to carry all calls. Setting aside the issue of >precedence > > > >>for > > > >>the moment, the expectation is that the level of traffic needed to > > > >>trigger premption is typicaly higher (perhaps substanially higher) > > > >>than > > > >>the level triggering to stop admission of new flows. That > > > means that > > > >>when preemption does get triggered, there would actually > > > not really be > > > >>any new state admitted. > > > > > > > >I'm sorry, but with that last sentence you lost me :-)...I kind of > > > >understood some of the things you were saying, but there were too > > > >many things you left out (why does one have an admission control at > > > >level X and a preemption level at X+N?, are you implying that the > > > >edge is keeping track of the flows it rejects?....that would seem > > > >quite granular in keeping measurements). > > > > > > > >I'm not sure its necessary to clarify the above. Its probably just > > > >best that we agree that future work should include a more detailed > > > >discussion of what is preemption in the context of your >architecture. > > > > > > > >>The degree of how far apart preemption and > > > >>admission thresholds are is of course a mater of > > > configuration, but I > > > >>would expect that they would be sufficiently apart to ensure that > > > >>you do > > > >>not just toggle preempted and new flows. Of course if there > > > are higher > > > >>precedence calls, then one might expect that a higher > > > precedence call > > > >>may be established while lower precedence calls may need to be > > > >>preempted? > > > >> > > > >>Perhaps this expectation should be made more transparent in the > > > >>drafts? > > > >> > > > >>>In the US and some other countries, this is not > > > >>>allowed in the PSTN. > > > >> > > > >>Just wanted to make sure I understand exactly what is not allowed. > > > >>Are > > > >>you saying that PSTN is not allowed to preempt a lower > > > precedence call > > > >>in order to establish a high recedence call? Or are you > > > referring to > > > >>the same precedence levels? > > > > > > > >as an example, in the US PSTN, all calls from the general public >are > > > >treated with the same level of precedence. the exception are >systems > > > >like GETS, but they simply increase the probability of call > > > >completion -- they do not use preemption. private systems based on > > > >MLPP, like Autovon in the DoD and NATO, do allow different levels >of > > > >priority and subsequent preemption if so needed. rfc-4190 and > > > >rfc-4542 provide background on these systems/services along with > > > >discussion in the context of IP (since this is the IETF :-) > > > > > > > >just to recap. I just wanted to point out that there are > > > >jurisdictions that do not allow preemption for voice communications > > > >used by the general public -- this definitely applies for a number >of > > > >PSTNs, and I'm sure it will trickle down to certain deployments of > > > >VoIP. Hence, I would recommend that the group consider other (re) > > > >actions other than preemption....which from the feedback of my > > > >original note, seems will be done. > > > > > > > >regards, > > > > > > > >-ken > > > > > > > > > > > >_______________________________________________ > > > >PCN mailing list > > > >PCN@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/pcn > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 13 12:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQ31-00073B-U2; Fri, 13 Oct 2006 12:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQ31-00072y-04 for pcn@ietf.org; Fri, 13 Oct 2006 12:38:11 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQ2x-0000TR-ES for pcn@ietf.org; Fri, 13 Oct 2006 12:38:10 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9DGc0205238; Fri, 13 Oct 2006 12:38:00 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 12:37:57 -0400 Message-Id: <6.2.5.6.0.20061013122755.03c53c80@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Oct 2006 12:37:57 -0400 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] Issue A4 Preemption Marking Term In-Reply-To: <452146C2.6020506@informatik.uni-wuerzburg.de> References: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.com> <452146C2.6020506@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Oct 2006 16:37:57.0711 (UTC) FILETIME=[F0899DF0:01C6EEE5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael: I think you bring up a good point. We will need to make sure the reader can easily know these "admissible/supportable rate" are for each router hop, and not the border-to-border notion. But the use of the word "link" may not be correct. This is because we don't want to indicate this rate is the physical link limit. Or associated with the physical link itself. We are talking more of the service limit, for example the scheduler's maximum service rate for the EF queue, Hence IMHO, we need to make sure the per each router hop notion is clear, and may want to do so without adding the "link" word to it. How about giving that a try for the next round? Thanks! -- Kwok -- At 01:05 PM 10/2/2006, Michael Menth wrote: >Hi, > >I think that the word "link" in "admissible link rate" indicates >that the respective rate is link specific in contrast to the >"border-to-border (b2b)" (received, admission-stop, excess traffic) >rates (or estimates) that are measured at the egress per b2b >aggregate. Thus, the "link" within the term avoids misunderstandings >with other possible scopes (e.g. admissible rate for a specific >ingress, admissible rate for specific b2b aggregates, ...). >Initially, I had a hard time to understand the draft since the scope >of the rates was not clear to me. If we know what we mean, we don't >need the "link", but it makes it easier for new people to understand >the architecture. > >Best wishes, > > Michael > >Jozef Babiarz wrote: >>I like what Michael is suggesting with the following minor changes. >>"admissible rate" drop the word link because only some of the traffic on >>the link is being measured e.g., per service class. I'm OK with >>"admission stop marking" or just "admission marking" meaning >>this is when admission of additional flows should be stopped. >> >>For the second level I support using "supportable rate" and for the >>marking "excess traffic marking" where the excess traffic is greater >>then the configured supportable rate and may or may not be above the >>actual link rate. I would expect that normally supportable rate would >>loss that link rate and possible less than the forwarding rate of the >>queue used. Preemption is an action of removing flows that some solution >>may take to get ride of excess traffic and return to provide good QoS to >>remaining traffic. >> >>Regards, Joe >>QoS & Network Architecture >>Telephone: 613-763-6098 (ESN 393-6098) >>Email: babiarz@nortel.com >> >>-----Original Message----- >>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>Sent: Monday, October 02, 2006 11:21 AM >>To: philip.eardley@bt.com >>Cc: pcn@ietf.org >>Subject: Re: [PCN] Issue A4 Preemption Marking Term >> >>Hi, >> >>what do you think about the terms >> >>* admissible link rate and "admission stop marking" using an >>admission stop bit >>* tolerable link rate and "excess traffic marking" using an excess >>traffic bit >>* supportED link rate (now = physical or virtual link rate used for >>interface traffic shaping (Phil), but I'm not sure whether this >>expression is required at all: maybe just link rate?) >> >>Admission control is a requirement in our context, but preemption >>is just an option when the tolerable link rate is exceeded (I think >>I read that somewhere). Therefore, I don't like the term >>"preemption marking" since this suggests preemption as mandatory. >>IF preemption is a mandatory feature, the term preemption marking is fine. >> >>Regards, >> >>Michael >> >>philip.eardley@bt.com wrote: >> >>>Not sure I like this, as the idea of this (pre-emption) marking is >>>that action is taken so the link should never be congested. >>> >>>Perhaps "severe pre-congestion marking"? >>> >>>-----Original Message----- >>>*From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>*Sent:* 02 October 2006 15:52 >>>*To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >>>*Cc:* pcn@ietf.org >>>*Subject:* RE: [PCN] Issue A4 Preemption Marking Term >>> >>>Hi Kwock >>> >>>What about using the term "severe congestion marking"? >>> >>>Best Regards, >>> >>>Georgios >>> >>> >>> >>------------------------------------------------------------------------ >> >>>*From:* Kwok-Ho Chan [mailto:khchan@nortel.com] >>>*Sent:* maandag 2 oktober 2006 16:43 >>>*To:* philip.eardley@bt.com >>>*Cc:* pcn@ietf.org >>>*Subject:* Re: [PCN] Issue A4 Preemption Marking Term >>> >>>Some other suggestions related to Issue A4 of: >>> >>> >>>A4 "Pre-emption Marking term" Issue >>> >>>Pre-emption Marking may seem to indicate the requirement of >>>pre-empting existing flows/sessions to allow additional new >>>flows/sessions to be admitted. This scenario is not allowed in >>>some markets due to regulations. Should a better term be used >>>instead of Pre-emption Marking to indicate the need to reduce the >>>offered traffic >>> >> >> >>>load to the congested portions of the network? >>> >>>Michael suggested "excess traffic mark" - what do you reckon? >>> >>> >>>How about the terms of: >>>"Admissible Rate Marking" for the marking indication of exceeding >>>the "Admissible Rate" >>>and >>>"Supportable Rate Marking" for the marking indication of exceeding the >>> >> >> >>>"Supportable Rate" ? >>> >>>It is then up to the Policy Decision to take the appropriate >>>action when the rate of traffic is >>>not "Supportable" anymore. With Preemption being one of the >>>possible policy decision actions. >>> >>>Thanks! >>>-- Kwok -- >>> >>>At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >>> >>>Content-class: urn:content-classes:message >>>Content-Type: multipart/alternative; >>>boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" >>> >>>Thought I'd try to close a >>>few more of the Issues - covering the Issues "A. Terminology Issues" >>>listed at >>>_http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ >>> >>> >>> >>> >>>A1 "PCN-Region Term" Issue >>> >>>Should the region running >>>the PCN mechanism be called the PCN-Region or >>>PCN-Domain? >>> >>> Reference: >>>draft-chan-problem-statement-00.txt section >>>2.1. >>> >>> RFC2998 supports use >>>of Region, RFC2474 supports use of >>>Domain. >>> >>>Personally I don't mind, >>>happy to stick with PCN-region as currently used in >>>draft-chan-problem-statement. >>> >>> >>> >>> >>>A2 "PIN Term" Issue >>> >>>Should we use the >>>terminology PCN Interior Node or PCN Intermediate Node >>>(function)? >>> >>> Reference: >>>draft-chan-problem-statement-00.txt section >>>2.1. >>> >>> RFC2475 supports use >>>of PCN Interior >>>Node >>> >>>Personally I slightly >>>prefer PCN Interior Node, though I don't mind much. So happy to stick >>>with PCN Interior Node as currently used in >>>draft-chan-problem-statement >>> >>> >>> >>> >>> >>> >>>A3 "PEN Term" >>>Issue >>> >>>Should we use the >>>terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >>>Border Node or PCN Gateway Node >>>(function)? >>> >>> Reference: >>>draft-chan-problem-statement-00.txt section >>>2.1. >>> >>> The term currently >>>used in draft-chan-problem-statement is PCN End >>>Node >>> >>> >>> >>>Personally I don't like the >>>term PCN End Node - the problem is that it will probably get shortened >>> >>to >> >>>end node (already seen this happening on the list). I think this will >>> >>get >> >>>confusing as [1] the innocent may think it means 'end host'; [2] the >>>deployment models will probably show how PCN fits into the 'big >>> >>picture' >> >>>of end-to-end QoS, in which case we'd have both end hosts & PCN End >>>Nodes. >>> >>> >>>I also think PCN Gateway >>>Node (function) could be slightly confusing. The actual physical node >>>where the "PCN End Node" function sits is typically the PCN-region's >>>gateway node, but it could in some deployment situations be an end >>> >>host, >> >>>if the PCN-region extends out that far. >>> >>> >>> >>>PCN Boundary Node would be >>>consistent with rfc2474 >>>terminology. >>> >>>PCN Border Node is a >>>similar possibility that Michael has suggested. >>> >>> >>> >>>PCN Edge Node allows us to >>>continue to use the nice acronym PEN, with its hint of 'penning in' >>> >>the >> >>>PCN-region. >>> >>> >>>I favour PCN Edge Node, and >>>also ok with PCN Boundary / Border >>>Node >>> >>> >>> >>> >>>A4 "Pre-emption Marking term" Issue >>>Pre-emption Marking may seem to indicate the requirement of >>>pre-empting existing flows/sessions to allow additional new >>>flows/sessions to be admitted. This scenario is not allowed in >>>some markets due to regulations. Should a better term be used >>>instead of Pre-emption Marking to indicate the need to reduce the >>>offered traffic >>> >> >> >>>load to the congested portions of the network? >>>Michael suggested "excess traffic mark" - what do you reckon? >>> >>>Best wishes >>>phil >>>_______________________________________________ >>>PCN mailing list >>>PCN@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pcn >>> >>> >>> >>------------------------------------------------------------------------ >> >>>_______________________________________________ >>>PCN mailing list >>>PCN@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pcn >>> >>> >> >> > >-- >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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 13 12:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQEE-0007fA-U2; Fri, 13 Oct 2006 12:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQED-0007Ww-9T for pcn@ietf.org; Fri, 13 Oct 2006 12:49:45 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQEA-0003He-Ev for pcn@ietf.org; Fri, 13 Oct 2006 12:49:45 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9DGnd206632; Fri, 13 Oct 2006 12:49:39 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 12:49:39 -0400 Message-Id: <6.2.5.6.0.20061013124333.03c53dc8@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Oct 2006 12:49:38 -0400 To: Bob Briscoe From: "Kwok-Ho Chan" Subject: RE: [PCN] ProblemStatement Issue NEW: Notion of TRUST In-Reply-To: <5.2.1.1.2.20061013153021.0377e6a0@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20061013153021.0377e6a0@pop3.jungle.bt.co.uk> Mime-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2006 16:49:39.0202 (UTC) FILETIME=[92A8A620:01C6EEE7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1475984412==" Errors-To: pcn-bounces@ietf.org --===============1475984412== Content-Type: multipart/alternative; boundary="=====================_18613414==.ALT" --=====================_18613414==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks Bob. We will take this guidance. We may just want to identify the problem PCN work may depend on, by drilling down a bit in the problem space (The main purpose of bringing this issue up). But will leave the solution space be open in PCN for now. Hopefully some additional work are done in other IETF WGs that PCN WG can use. But we will not discourage (actually should encourage) people to tell us how some of the TRUST notion issues can be solved. Thanks! -- Kwok -- At 11:47 AM 10/13/2006, Bob Briscoe wrote: >Kwok, > >At 11:05 AM 10/11/2006, Kwok-Ho Chan wrote: >>Ruediger: >>I would like to include the result of these discussions into >>future versions of the Problem Statement draft if appropriate. > >Feel free to use the description of the trust problem I've already >written in section 3 of ><draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>. >Although that draft describes a solution, chartering that we will >solve this problem is a different matter... > >Trusting whether an upstream response will follow from downstream >congestion, is a hard problem that is currently not possible in the >Internet architecture. No other IETF activity has given itself a bar >this high (TCP and every other IETF transport assumes trust in the >upstream sender's response to congestion). > >Nonetheless, re-ECN claims to solve this problem. It claims to >ensure that the sender can be trusted to respond correctly to >downstream congestion, and everyone in the feedback loop can be >trusted to pass on congestion feedback honestly (without using >crypto). And the above border-cheating I-D addresses this problem >specifically for the edge-edge deployment model of PCN. > >However, re-ECN currently proposes to use the last undefined bit in >the IPv4 header so it's unlikely to happen in the same timeframe as >we are hoping to get PCN work to standards track. > >So, the current approach proposed for chartering the PCN w-g is to >assume trust with respect to responding to congestion, just like all >other IETF work does. > >But, the trust issue is particularly acute for inelastic flows >(which is why we need admission control). A few non-complying flows >can make /all/ other competing flows useless. > >In practice, PCN is actually further ahead on this issue than any >other IETF activity. But in the PCN charter we shouldn't commit >ourselves to /having/ to be further ahead than the Internet >architecture allows. However, we should include this very important >issue in the problem statement. And we should say it is the >standards activity most likely to be added if/when the group >re-charters after it has achieved it's initial objectives. > >In particular, we should discuss how to allow space for a solution >like re-ECN, when standardising a protocol encoding for PCN (re-PCN >if you like). I outlined a possible encoding in the above >border-cheating draft. > >If we did want to standardise re-PCN into bit 48 of the IP header, >the process isn't even clear. I think we could define it for >experimental use within a controlled region. That seems to fits the >sprit of the recently approved BCP on experiments in the IP header >. But I can't get a clear answer >from anyone whether it does. Before the BCP was issued, I pointed >out to Bill Fenner that the BCP doesn't give the assignment process >for bit 48, and he decided it was best to continue not to mention it. > > >Bob > > >____________________________________________________________________________ >Notice: This contribution is the personal view of the author and >does not necessarily reflect the technical nor commercial direction of BT plc. >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 --=====================_18613414==.ALT Content-Type: text/html; charset="us-ascii" Thanks Bob.
We will take this guidance.
We may just want to identify the problem PCN work may depend on,
by drilling down a bit in the problem space (The main purpose of bringing this issue up).

But will leave the solution space be open in PCN for now.
Hopefully some additional work are done in other IETF WGs that
PCN WG can use.

But we will not discourage (actually should encourage) people to tell us
how some of the TRUST notion issues can be solved.
Thanks!
-- Kwok --

At 11:47 AM 10/13/2006, Bob Briscoe wrote:

Kwok,

At 11:05 AM 10/11/2006, Kwok-Ho Chan wrote:
Ruediger:
I would like to include the result of these discussions into
future versions of the Problem Statement draft if appropriate.

Feel free to use the description of the trust problem I've already written in section 3 of < draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>. Although that draft describes a solution, chartering that we will solve this problem is a different matter...

Trusting whether an upstream response will follow from downstream congestion, is a hard problem that is currently not possible in the Internet architecture. No other IETF activity has given itself a bar this high (TCP and every other IETF transport assumes trust in the upstream sender's response to congestion).

Nonetheless, re-ECN claims to solve this problem. It claims to ensure that the sender can be trusted to respond correctly to downstream congestion, and everyone in the feedback loop can be trusted to pass on congestion feedback honestly (without using crypto). And the above border-cheating I-D addresses this problem specifically for the edge-edge deployment model of PCN.

However, re-ECN currently proposes to use the last undefined bit in the IPv4 header so it's unlikely to happen in the same timeframe as we are hoping to get PCN work to standards track.

So, the current approach proposed for chartering the PCN w-g is to assume trust with respect to responding to congestion, just like all other IETF work does.

But, the trust issue is particularly acute for inelastic flows (which is why we need admission control). A few non-complying flows can make /all/ other competing flows useless.

In practice, PCN is actually further ahead on this issue than any other IETF activity. But in the PCN charter we shouldn't commit ourselves to /having/ to be further ahead than the Internet architecture allows. However, we should include this very important issue in the problem statement. And we should say it is the standards activity most likely to be added if/when the group re-charters after it has achieved it's initial objectives.

In particular, we should discuss how to allow space for a solution like re-ECN, when standardising a protocol encoding for PCN (re-PCN if you like). I outlined a possible encoding in the above border-cheating draft.

If we did want to standardise re-PCN into bit 48 of the IP header, the process isn't even clear. I think we could define it for experimental use within a controlled region. That seems to fits the sprit of the recently approved BCP on experiments in the IP header <draft-fenner-iana-exp-2780-05.txt>. But I can't get a clear answer from anyone whether it does. Before the BCP was issued, I pointed out to Bill Fenner that the BCP doesn't give the assignment process for bit 48, and he decided it was best to continue not to mention it.


Bob


____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196
--=====================_18613414==.ALT-- --===============1475984412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1475984412==-- From pcn-bounces@ietf.org Fri Oct 13 12:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQFZ-0008BW-SD; Fri, 13 Oct 2006 12:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQFX-0008BO-Uh for pcn@ietf.org; Fri, 13 Oct 2006 12:51:07 -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 1GYQFU-0003S1-1n for pcn@ietf.org; Fri, 13 Oct 2006 12:51:07 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id F41AB2A9D; Fri, 13 Oct 2006 18:51:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DB79F400A; Fri, 13 Oct 2006 18:51:02 +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 B1BC72A9D; Fri, 13 Oct 2006 18:51:02 +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 k9DGp2s22066; Fri, 13 Oct 2006 18:51:02 +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 39D296F58E; Fri, 13 Oct 2006 18:49:32 +0200 (CEST) Message-ID: <452FC418.30503@informatik.uni-wuerzburg.de> Date: Fri, 13 Oct 2006 18:51:36 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kwok-Ho Chan Subject: Re: [PCN] Issue A4 Preemption Marking Term References: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.com> <452146C2.6020506@informatik.uni-wuerzburg.de> <6.2.5.6.0.20061013122755.03c53c80@nortel.com> In-Reply-To: <6.2.5.6.0.20061013122755.03c53c80@nortel.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: db284e046c8702920c1c6125bc4d0b7a 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Kwok, well, I still think it is dangerous if the scope of the rates is missing in the terms because there are link- and b2b-specific rates and people usually like to jumble them. By clarifying what "admissible/tolerable link rate" means, confusion with physical limits can also be excluded. Maybe it is better to substitute "link" by "interface"? Best wishes, Michael Kwok-Ho Chan wrote: > Michael: > I think you bring up a good point. > We will need to make sure the reader can easily know these > "admissible/supportable rate" > are for each router hop, and not the border-to-border notion. > But the use of the word "link" may not be correct. > This is because we don't want to indicate this rate is the physical > link limit. > Or associated with the physical link itself. > We are talking more of the service limit, for example > the scheduler's maximum service rate for the EF queue, > > Hence IMHO, we need to make sure the per each router hop notion is clear, > and may want to do so without adding the "link" word to it. > How about giving that a try for the next round? > > Thanks! > -- Kwok -- > > > At 01:05 PM 10/2/2006, Michael Menth wrote: >> Hi, >> >> I think that the word "link" in "admissible link rate" indicates that >> the respective rate is link specific in contrast to the >> "border-to-border (b2b)" (received, admission-stop, excess traffic) >> rates (or estimates) that are measured at the egress per b2b >> aggregate. Thus, the "link" within the term avoids misunderstandings >> with other possible scopes (e.g. admissible rate for a specific >> ingress, admissible rate for specific b2b aggregates, ...). >> Initially, I had a hard time to understand the draft since the scope >> of the rates was not clear to me. If we know what we mean, we don't >> need the "link", but it makes it easier for new people to understand >> the architecture. >> >> Best wishes, >> >> Michael >> >> Jozef Babiarz wrote: >>> I like what Michael is suggesting with the following minor changes. >>> "admissible rate" drop the word link because only some of the >>> traffic on >>> the link is being measured e.g., per service class. I'm OK with >>> "admission stop marking" or just "admission marking" meaning >>> this is when admission of additional flows should be stopped. >>> >>> For the second level I support using "supportable rate" and for the >>> marking "excess traffic marking" where the excess traffic is greater >>> then the configured supportable rate and may or may not be above the >>> actual link rate. I would expect that normally supportable rate would >>> loss that link rate and possible less than the forwarding rate of the >>> queue used. Preemption is an action of removing flows that some >>> solution >>> may take to get ride of excess traffic and return to provide good >>> QoS to >>> remaining traffic. >>> >>> Regards, Joe >>> QoS & Network Architecture >>> Telephone: 613-763-6098 (ESN 393-6098) >>> Email: babiarz@nortel.com >>> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: >>> Monday, October 02, 2006 11:21 AM >>> To: philip.eardley@bt.com >>> Cc: pcn@ietf.org >>> Subject: Re: [PCN] Issue A4 Preemption Marking Term >>> >>> Hi, >>> >>> what do you think about the terms >>> >>> * admissible link rate and "admission stop marking" using an >>> admission stop bit >>> * tolerable link rate and "excess traffic marking" using an excess >>> traffic bit >>> * supportED link rate (now = physical or virtual link rate used for >>> interface traffic shaping (Phil), but I'm not sure whether this >>> expression is required at all: maybe just link rate?) >>> >>> Admission control is a requirement in our context, but preemption is >>> just an option when the tolerable link rate is exceeded (I think I >>> read that somewhere). Therefore, I don't like the term "preemption >>> marking" since this suggests preemption as mandatory. IF preemption >>> is a mandatory feature, the term preemption marking is fine. >>> >>> Regards, >>> >>> Michael >>> >>> philip.eardley@bt.com wrote: >>> >>>> Not sure I like this, as the idea of this (pre-emption) marking is >>>> that action is taken so the link should never be congested. >>>> >>>> Perhaps "severe pre-congestion marking"? >>>> >>>> -----Original Message----- >>>> *From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>> *Sent:* 02 October 2006 15:52 >>>> *To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >>>> *Cc:* pcn@ietf.org >>>> *Subject:* RE: [PCN] Issue A4 Preemption Marking Term >>>> >>>> Hi Kwock >>>> >>>> What about using the term "severe congestion marking"? >>>> >>>> Best Regards, >>>> >>>> Georgios >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> >>>> *From:* Kwok-Ho Chan [mailto:khchan@nortel.com] >>>> *Sent:* maandag 2 oktober 2006 16:43 >>>> *To:* philip.eardley@bt.com >>>> *Cc:* pcn@ietf.org >>>> *Subject:* Re: [PCN] Issue A4 Preemption Marking Term >>>> >>>> Some other suggestions related to Issue A4 of: >>>> >>>> >>>> A4 "Pre-emption Marking term" Issue >>>> >>>> Pre-emption Marking may seem to indicate the requirement of >>>> pre-empting existing flows/sessions to allow additional new >>>> flows/sessions to be admitted. This scenario is not allowed in some >>>> markets due to regulations. Should a better term be used instead of >>>> Pre-emption Marking to indicate the need to reduce the offered traffic >>>> >>> >>> >>>> load to the congested portions of the network? >>>> >>>> Michael suggested "excess traffic mark" - what do you reckon? >>>> >>>> >>>> How about the terms of: >>>> "Admissible Rate Marking" for the marking indication of exceeding >>>> the "Admissible Rate" >>>> and >>>> "Supportable Rate Marking" for the marking indication of exceeding the >>>> >>> >>> >>>> "Supportable Rate" ? >>>> >>>> It is then up to the Policy Decision to take the appropriate action >>>> when the rate of traffic is >>>> not "Supportable" anymore. With Preemption being one of the >>>> possible policy decision actions. >>>> >>>> Thanks! >>>> -- Kwok -- >>>> >>>> At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >>>> >>>> Content-class: urn:content-classes:message >>>> Content-Type: multipart/alternative; >>>> boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" >>>> >>>> Thought I'd try to close a >>>> few more of the Issues - covering the Issues "A. Terminology Issues" >>>> listed at >>>> _http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ >>>> >>>> >>>> >>>> >>>> A1 "PCN-Region Term" Issue >>>> >>>> Should the region running >>>> the PCN mechanism be called the PCN-Region or >>>> PCN-Domain? >>>> >>>> Reference: >>>> draft-chan-problem-statement-00.txt section >>>> 2.1. >>>> >>>> RFC2998 supports use >>>> of Region, RFC2474 supports use of >>>> Domain. >>>> >>>> Personally I don't mind, >>>> happy to stick with PCN-region as currently used in >>>> draft-chan-problem-statement. >>>> >>>> >>>> >>>> >>>> A2 "PIN Term" Issue >>>> >>>> Should we use the >>>> terminology PCN Interior Node or PCN Intermediate Node >>>> (function)? >>>> >>>> Reference: >>>> draft-chan-problem-statement-00.txt section >>>> 2.1. >>>> >>>> RFC2475 supports use >>>> of PCN Interior >>>> Node >>>> >>>> Personally I slightly >>>> prefer PCN Interior Node, though I don't mind much. So happy to stick >>>> with PCN Interior Node as currently used in >>>> draft-chan-problem-statement >>>> >>>> >>>> >>>> >>>> >>>> >>>> A3 "PEN Term" >>>> Issue >>>> >>>> Should we use the >>>> terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >>>> Border Node or PCN Gateway Node >>>> (function)? >>>> >>>> Reference: >>>> draft-chan-problem-statement-00.txt section >>>> 2.1. >>>> >>>> The term currently >>>> used in draft-chan-problem-statement is PCN End >>>> Node >>>> >>>> >>>> >>>> Personally I don't like the >>>> term PCN End Node - the problem is that it will probably get shortened >>>> >>> to >>> >>>> end node (already seen this happening on the list). I think this will >>>> >>> get >>> >>>> confusing as [1] the innocent may think it means 'end host'; [2] the >>>> deployment models will probably show how PCN fits into the 'big >>>> >>> picture' >>> >>>> of end-to-end QoS, in which case we'd have both end hosts & PCN End >>>> Nodes. >>>> >>>> >>>> I also think PCN Gateway >>>> Node (function) could be slightly confusing. The actual physical node >>>> where the "PCN End Node" function sits is typically the PCN-region's >>>> gateway node, but it could in some deployment situations be an end >>>> >>> host, >>> >>>> if the PCN-region extends out that far. >>>> >>>> >>>> >>>> PCN Boundary Node would be >>>> consistent with rfc2474 >>>> terminology. >>>> >>>> PCN Border Node is a >>>> similar possibility that Michael has suggested. >>>> >>>> >>>> >>>> PCN Edge Node allows us to >>>> continue to use the nice acronym PEN, with its hint of 'penning in' >>>> >>> the >>> >>>> PCN-region. >>>> >>>> >>>> I favour PCN Edge Node, and >>>> also ok with PCN Boundary / Border >>>> Node >>>> >>>> >>>> >>>> >>>> A4 "Pre-emption Marking term" Issue >>>> Pre-emption Marking may seem to indicate the requirement of >>>> pre-empting existing flows/sessions to allow additional new >>>> flows/sessions to be admitted. This scenario is not allowed in some >>>> markets due to regulations. Should a better term be used instead of >>>> Pre-emption Marking to indicate the need to reduce the offered traffic >>>> >>> >>> >>>> load to the congested portions of the network? >>>> Michael suggested "excess traffic mark" - what do you reckon? >>>> >>>> Best wishes >>>> phil >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pcn >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pcn >>>> >>>> >>> >>> >> >> -- >> 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 -- 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 From pcn-bounces@ietf.org Fri Oct 13 13:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQZR-0003SB-Q8; Fri, 13 Oct 2006 13:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQZQ-0003S2-72 for pcn@ietf.org; Fri, 13 Oct 2006 13:11:40 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQZO-00075t-Kg for pcn@ietf.org; Fri, 13 Oct 2006 13:11:40 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9DHBZN25936; Fri, 13 Oct 2006 13:11:36 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 13:11:35 -0400 Message-Id: <6.2.5.6.0.20061013130606.03c52b50@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Oct 2006 13:11:34 -0400 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] Issue A4 Preemption Marking Term In-Reply-To: <452FC418.30503@informatik.uni-wuerzburg.de> References: <9671A92C3C8B5744BC97F855F7CB64650C6450B3@zcarhxm1.corp.nortel.com> <452146C2.6020506@informatik.uni-wuerzburg.de> <6.2.5.6.0.20061013122755.03c53c80@nortel.com> <452FC418.30503@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 13 Oct 2006 17:11:35.0402 (UTC) FILETIME=[A32CD4A0:01C6EEEA] X-Spam-Score: 0.1 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael: Thank you for your guidance. I am still on the fence. Most likely write both options up and have it reviewed in context. Thanks! -- Kwok -- At 12:51 PM 10/13/2006, Michael Menth wrote: >Hi Kwok, > >well, I still think it is dangerous if the scope of the rates is >missing in the terms because there are link- and b2b-specific rates >and people usually like to jumble them. By clarifying what >"admissible/tolerable link rate" means, confusion with physical >limits can also be excluded. Maybe it is better to substitute "link" >by "interface"? > >Best wishes, > > Michael > >Kwok-Ho Chan wrote: >>Michael: >>I think you bring up a good point. >>We will need to make sure the reader can easily know these >>"admissible/supportable rate" >>are for each router hop, and not the border-to-border notion. >>But the use of the word "link" may not be correct. >>This is because we don't want to indicate this rate is the physical >>link limit. >>Or associated with the physical link itself. >>We are talking more of the service limit, for example >>the scheduler's maximum service rate for the EF queue, >> >>Hence IMHO, we need to make sure the per each router hop notion is clear, >>and may want to do so without adding the "link" word to it. >>How about giving that a try for the next round? >> >>Thanks! >>-- Kwok -- >> >> >>At 01:05 PM 10/2/2006, Michael Menth wrote: >>>Hi, >>> >>>I think that the word "link" in "admissible link rate" indicates >>>that the respective rate is link specific in contrast to the >>>"border-to-border (b2b)" (received, admission-stop, excess >>>traffic) rates (or estimates) that are measured at the egress per >>>b2b aggregate. Thus, the "link" within the term avoids >>>misunderstandings with other possible scopes (e.g. admissible rate >>>for a specific ingress, admissible rate for specific b2b >>>aggregates, ...). Initially, I had a hard time to understand the >>>draft since the scope of the rates was not clear to me. If we know >>>what we mean, we don't need the "link", but it makes it easier for >>>new people to understand the architecture. >>> >>>Best wishes, >>> >>> Michael >>> >>>Jozef Babiarz wrote: >>>>I like what Michael is suggesting with the following minor changes. >>>>"admissible rate" drop the word link because only some of the traffic on >>>>the link is being measured e.g., per service class. I'm OK with >>>>"admission stop marking" or just "admission marking" meaning >>>>this is when admission of additional flows should be stopped. >>>> >>>>For the second level I support using "supportable rate" and for the >>>>marking "excess traffic marking" where the excess traffic is greater >>>>then the configured supportable rate and may or may not be above the >>>>actual link rate. I would expect that normally supportable rate would >>>>loss that link rate and possible less than the forwarding rate of the >>>>queue used. Preemption is an action of removing flows that some solution >>>>may take to get ride of excess traffic and return to provide good QoS to >>>>remaining traffic. >>>> >>>>Regards, Joe >>>>QoS & Network Architecture >>>>Telephone: 613-763-6098 (ESN 393-6098) >>>>Email: babiarz@nortel.com >>>> >>>>-----Original Message----- >>>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>Sent: Monday, October 02, 2006 11:21 AM >>>>To: philip.eardley@bt.com >>>>Cc: pcn@ietf.org >>>>Subject: Re: [PCN] Issue A4 Preemption Marking Term >>>> >>>>Hi, >>>> >>>>what do you think about the terms >>>> >>>>* admissible link rate and "admission stop marking" using an >>>>admission stop bit >>>>* tolerable link rate and "excess traffic marking" using an >>>>excess traffic bit >>>>* supportED link rate (now = physical or virtual link rate used >>>>for interface traffic shaping (Phil), but I'm not sure whether >>>>this expression is required at all: maybe just link rate?) >>>> >>>>Admission control is a requirement in our context, but preemption >>>>is just an option when the tolerable link rate is exceeded (I >>>>think I read that somewhere). Therefore, I don't like the term >>>>"preemption marking" since this suggests preemption as mandatory. >>>>IF preemption is a mandatory feature, the term preemption marking is fine. >>>> >>>>Regards, >>>> >>>>Michael >>>> >>>>philip.eardley@bt.com wrote: >>>> >>>>>Not sure I like this, as the idea of this (pre-emption) marking >>>>>is that action is taken so the link should never be congested. >>>>> >>>>>Perhaps "severe pre-congestion marking"? >>>>> >>>>>-----Original Message----- >>>>>*From:* Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>*Sent:* 02 October 2006 15:52 >>>>>*To:* 'Kwok-Ho Chan'; Eardley,PL,Philip,CXR9 R >>>>>*Cc:* pcn@ietf.org >>>>>*Subject:* RE: [PCN] Issue A4 Preemption Marking Term >>>>> >>>>>Hi Kwock >>>>> >>>>>What about using the term "severe congestion marking"? >>>>> >>>>>Best Regards, >>>>> >>>>>Georgios >>>>> >>>>> >>>>------------------------------------------------------------------------ >>>> >>>>>*From:* Kwok-Ho Chan [mailto:khchan@nortel.com] >>>>>*Sent:* maandag 2 oktober 2006 16:43 >>>>>*To:* philip.eardley@bt.com >>>>>*Cc:* pcn@ietf.org >>>>>*Subject:* Re: [PCN] Issue A4 Preemption Marking Term >>>>> >>>>>Some other suggestions related to Issue A4 of: >>>>> >>>>> >>>>>A4 "Pre-emption Marking term" Issue >>>>> >>>>>Pre-emption Marking may seem to indicate the requirement of >>>>>pre-empting existing flows/sessions to allow additional new >>>>>flows/sessions to be admitted. This scenario is not allowed in >>>>>some markets due to regulations. Should a better term be used >>>>>instead of Pre-emption Marking to indicate the need to reduce >>>>>the offered traffic >>>> >>>> >>>>>load to the congested portions of the network? >>>>> >>>>>Michael suggested "excess traffic mark" - what do you reckon? >>>>> >>>>> >>>>>How about the terms of: >>>>>"Admissible Rate Marking" for the marking indication of >>>>>exceeding the "Admissible Rate" >>>>>and >>>>>"Supportable Rate Marking" for the marking indication of exceeding the >>>> >>>> >>>>>"Supportable Rate" ? >>>>> >>>>>It is then up to the Policy Decision to take the appropriate >>>>>action when the rate of traffic is >>>>>not "Supportable" anymore. With Preemption being one of the >>>>>possible policy decision actions. >>>>> >>>>>Thanks! >>>>>-- Kwok -- >>>>> >>>>>At 10:09 AM 10/2/2006, philip.eardley@bt.com wrote: >>>>> >>>>>Content-class: urn:content-classes:message >>>>>Content-Type: multipart/alternative; >>>>>boundary="----_=_NextPart_001_01C6E62C.6FE1DFFF" >>>>> >>>>>Thought I'd try to close a >>>>>few more of the Issues - covering the Issues "A. Terminology Issues" >>>>>listed at >>>>>_http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt_ >>>>> >>>>> >>>>> >>>>> >>>>>A1 "PCN-Region Term" Issue >>>>> >>>>>Should the region running >>>>>the PCN mechanism be called the PCN-Region or >>>>>PCN-Domain? >>>>> >>>>> Reference: >>>>>draft-chan-problem-statement-00.txt section >>>>>2.1. >>>>> >>>>> RFC2998 supports use >>>>>of Region, RFC2474 supports use of >>>>>Domain. >>>>> >>>>>Personally I don't mind, >>>>>happy to stick with PCN-region as currently used in >>>>>draft-chan-problem-statement. >>>>> >>>>> >>>>> >>>>> >>>>>A2 "PIN Term" Issue >>>>> >>>>>Should we use the >>>>>terminology PCN Interior Node or PCN Intermediate Node >>>>>(function)? >>>>> >>>>> Reference: >>>>>draft-chan-problem-statement-00.txt section >>>>>2.1. >>>>> >>>>> RFC2475 supports use >>>>>of PCN Interior >>>>>Node >>>>> >>>>>Personally I slightly >>>>>prefer PCN Interior Node, though I don't mind much. So happy to stick >>>>>with PCN Interior Node as currently used in >>>>>draft-chan-problem-statement >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>A3 "PEN Term" >>>>>Issue >>>>> >>>>>Should we use the >>>>>terminology PCN End Node or PCN Edge Node or PCN Boundary Node or PCN >>>>>Border Node or PCN Gateway Node >>>>>(function)? >>>>> >>>>> Reference: >>>>>draft-chan-problem-statement-00.txt section >>>>>2.1. >>>>> >>>>> The term currently >>>>>used in draft-chan-problem-statement is PCN End >>>>>Node >>>>> >>>>> >>>>> >>>>>Personally I don't like the >>>>>term PCN End Node - the problem is that it will probably get shortened >>>>to >>>> >>>>>end node (already seen this happening on the list). I think this will >>>>get >>>> >>>>>confusing as [1] the innocent may think it means 'end host'; [2] the >>>>>deployment models will probably show how PCN fits into the 'big >>>>picture' >>>> >>>>>of end-to-end QoS, in which case we'd have both end hosts & PCN End >>>>>Nodes. >>>>> >>>>> >>>>>I also think PCN Gateway >>>>>Node (function) could be slightly confusing. The actual physical node >>>>>where the "PCN End Node" function sits is typically the PCN-region's >>>>>gateway node, but it could in some deployment situations be an end >>>>host, >>>> >>>>>if the PCN-region extends out that far. >>>>> >>>>> >>>>> >>>>>PCN Boundary Node would be >>>>>consistent with rfc2474 >>>>>terminology. >>>>> >>>>>PCN Border Node is a >>>>>similar possibility that Michael has suggested. >>>>> >>>>> >>>>> >>>>>PCN Edge Node allows us to >>>>>continue to use the nice acronym PEN, with its hint of 'penning in' >>>>the >>>> >>>>>PCN-region. >>>>> >>>>> >>>>>I favour PCN Edge Node, and >>>>>also ok with PCN Boundary / Border >>>>>Node >>>>> >>>>> >>>>> >>>>> >>>>>A4 "Pre-emption Marking term" Issue >>>>>Pre-emption Marking may seem to indicate the requirement of >>>>>pre-empting existing flows/sessions to allow additional new >>>>>flows/sessions to be admitted. This scenario is not allowed in >>>>>some markets due to regulations. Should a better term be used >>>>>instead of Pre-emption Marking to indicate the need to reduce >>>>>the offered traffic >>>> >>>> >>>>>load to the congested portions of the network? >>>>>Michael suggested "excess traffic mark" - what do you reckon? >>>>> >>>>>Best wishes >>>>>phil >>>>>_______________________________________________ >>>>>PCN mailing list >>>>>PCN@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pcn >>>>> >>>>> >>>>------------------------------------------------------------------------ >>>> >>>>>_______________________________________________ >>>>>PCN mailing list >>>>>PCN@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pcn >>>>> >>>> >>> >>>-- >>>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 > >-- >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 From pcn-bounces@ietf.org Fri Oct 13 15:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSj5-0003RM-AS; Fri, 13 Oct 2006 15:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSj3-0003RA-Po for pcn@ietf.org; Fri, 13 Oct 2006 15:29:45 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYSiy-000675-1w for pcn@ietf.org; Fri, 13 Oct 2006 15:29:45 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 20:29:34 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Oct 2006 20:29:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Summary Date: Fri, 13 Oct 2006 20:29:33 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD7D@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4513E837.4020301@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Summary Thread-Index: AcbeTOrJ8JeTO6aJQl2vz26aMtmszAPvUY7w From: To: , X-OriginalArrivalTime: 13 Oct 2006 19:29:34.0349 (UTC) FILETIME=[E9CFE3D0:01C6EEFD] X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael Thanks for all your comments, it was great to have a detailed perspective and suggestions from someone reading it fresh. On your email below, here's what I've been doing so far, completing before the draft deadline. I tried to find a happy medium between what you wrote and what's in the draft at the moment. Hopefully it's clearer and snappier than the previous version of the draft. I more or less kept existing S1.1.0 - because wanted to outline the specific scenario (ie in line with intserv over diffserv). Then I used most of what you wrote instead of the existing 1.1.1 & 1.1.2. I also shuffled a couple of bits from section 1 to later in the doc. On a technical point, I deliberately removed the phrase in what you wrote (in pre-emption paragraph) "the rate of the border-to-border-CL-aggregate should be reduced by its border-to-border-excess-rate under the assumption that no packet loss occurred" - because this isn't mentioned in the main section 3, and anyway is very risky as the scenario is when link or probably multiple links have failed so it's quite likely that pkts are being dropped.=20 On a terminology, I kept with what the draft currently uses. I think one of the things the WG will do [if formed] is agree on terminology, and I didn't want to pre-empt (!) this discussion=20 Thanks phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 22 September 2006 14:42 To: pcn@ietf.org Subject: [PCN] Summary Summary A "controlled load (CL) region" consists of ingress and egress gateways=20 (routers) and of interior routers. An admission control (AC) function=20 explicitly admits flows that want to use the CL service of the CL region and that enter and leave the region at its ingress and egress routers.=20 The ingress and egress gateways are also called border routers and the=20 overall CL traffic between two border routers is called a=20 "border-to-border (b2b) CL aggregate". The flows need traffic=20 descriptors that are enforced by a policing function at the ingress=20 routers and they may also be used for the admission decision. Each link in such a CL region is associated with a configurable=20 "admissible CL link rate" and a configurable "supportable CL link rate"=20 whereby the supportable CL link rate is usually significantly larger=20 than the admissible CL link rate. When a link carries more traffic than=20 its admissible link CL rate, no additional flows should be admitted to=20 the network. Although flows are only admitted as long as the admissible=20 CL link rate is not exceeded, the admitted traffic on a link can exceed=20 the supportable CL link rate, e.g., due to changed flow behavior or due=20 to redirected traffic after failures. In such a case, counter actions=20 may be taken to reduce the traffic on the link, e.g., by preempting=20 already admitted CL flows in order to restore the QoS of the CL service. The AC function for a new flow entering the network at ingress router R0 and leaving it at egress router R1 relies on feedback from the egress=20 router R1 about the existing b2b CL aggregate between R0 and R1. This=20 feedback is generated as follows. All routers meter the rate of the CL=20 traffic on their outgoing links and mark the packets with "admission=20 saturation" if the admissible CL link rate is exceeded. Egress router R1 controls the admission saturation marks for each of its b2b CL aggregates separately, and if the packets from R0 are admission=20 saturation marked, no further flows from R0 to R1 should be admitted.=20 This must be signaled from the egress R1 to the ingress R0. As the=20 inter-arrival time of CL packets on a link varies, the rate of the CL=20 traffic on the link is also subject to fluctuations. As a consequence,=20 the admissible CL link rate may be sometimes exceeded. To get more=20 stable information about the admission saturation for a b2b aggregate,=20 the egress routers measure the fraction of the traffic that is=20 associated with an admission saturation mark, and provide a "b2b=20 admission saturation estimate" based on a moving average. If this value=20 is large (close to 1), no further flows should be admitted. A potential preemption function relies on the feedback from the egress=20 routers about the b2b CL aggregates. This feedback is generated as=20 follows. All routers meter the rate of the CL traffic on their outgoing=20 links and mark only those packets with "excess traffic" that exceed the respective supportable CL link rate.=20 The egress routers measure for each b2b CL aggregate the rate of all=20 received packets ("b2b received rate") and the rate of received packets=20 with an excess traffic mark ("b2b excess rate"). If the b2b excess rate=20 of an b2b CL aggregate is larger than zero, the rate of the b2b CL=20 aggregate should be reduced by its b2b excess rate under the assumption=20 that no packet loss occurred; otherwise, the b2b sent rate is required from the corresponding ingress router to calculate the required traffic=20 rate reduction: (sent rate - (received rate - excess rate)). Thus, the following mapping of the terminology is used (here : Section=20 1.2 of the draft): http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture- 03.txt=20 admissible link rate: configured-admission-rate supportable link rate: configured-preemption-rate admission saturation mark: admission mark excess traffic mark: preemption mark b2b CL aggregate: CL-region-aggregate b2b admission saturation estimate: congestion-level-estimate b2b sent rate: ingress-aggregate-rate b2b received rate: no equivalent b2b excess traffic rate: no equivalent An equivalent for sustainable-aggregate-rate is intentionally avoided as this is only what it means if packets of the respective aggregate are preemption marked. I like the new notation better than the old one for the following reasons: - The attributes "b2b" and "link" show the scope of the measured=20 quantities which is of extreme importance for the understanding of how=20 the measurement-based AC works. - "admissible" and "supportable" express a threshold rather than an=20 action (admission, preemption). - The mark "excess traffic" just indicates that the admissible link rate is exceeded, but it does not imply any action like preemption. - The mark "admission saturation" indicates that no further flows should be admitted whereas the mark "admission" can lead to confusion. - This motivates also the "b2b admission saturation estimate". I do not propose this nomenclature as the best one and that it should be copied, but I'd like to point out that the terminology can be made more=20 precise. Kind regards, Michael --=20 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 13 15:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSk2-0003bU-1O; Fri, 13 Oct 2006 15:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSk0-0003bP-Tu for pcn@ietf.org; Fri, 13 Oct 2006 15:30:44 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYSjw-0006Ic-CJ for pcn@ietf.org; Fri, 13 Oct 2006 15:30:44 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 20:30:39 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Oct 2006 20:30:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Simplicity, Scalability, Robustness Date: Fri, 13 Oct 2006 20:30:37 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD7E@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4513E83B.7060204@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Simplicity, Scalability, Robustness Thread-Index: AcbeTOnRpvziTviMRyK1RMVSqGQG+APsYNyA From: To: , X-OriginalArrivalTime: 13 Oct 2006 19:30:37.0784 (UTC) FILETIME=[0F9F4D80:01C6EEFE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael Thanks for this as well. I'm basically proposing to include it in the new version of the cl-architecture draft. Suggesting instead of the bullet "Networks are dimensioned ..." (which I'm not completely comfortable with), a bullet about PCN controlling the load dynamically:- o The admitted load is controlled dynamically. Therefore it adapts as the traffic matrix changes, and also if the network topology changes (eg after a link failure). Hence an operator can be less conservative when deploying network capacity, and less accurate in their prediction of the traffic matrix. Also, controlling the load using statically provisioned capacity per ingress (regardless of the egress of a flow), as is typical in the DiffServ architecture [RFC2475], can lead to focussed overload: many flows happen to focus on a particular link and then all flows through the congested link fail catastrophically (Section 6.2). thanks phil -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 22 September 2006 14:42 To: pcn@ietf.org Subject: [PCN] Simplicity, Scalability, Robustness The proposed network admission control (NAC) method is simple, scalable, and robust because - Per flow states are only required at the ingress routers to prevent=20 non-admitted CL traffic from entering the CL region, other network=20 entities are not aware of individual flows. - Each router has a separate admission saturation and excess traffic=20 marker for each of its links. These markers operate on the overall CL=20 traffic of the respective link. Therefore, there are no scalability=20 concerns. - The information of these measurements is implicitly signaled to the=20 respective egress routers by the marks in the packet headers and no=20 protocol actions are required. - The egress routers measure the rates of all received, admission=20 saturation marked, and excess traffic marked packets separately for each ingress router. These meters operate on the overall CL traffic of the=20 respective link. Therefore, there are no scalability concerns as long as the number of ingress routers is sufficiently small (or at least not=20 overwhelmingly large). - Feedback signaling is required between all pairs of ingress and egress routers and the signaled information is on the basis of the=20 corresponding b2b CL aggregate, i.e., it is also unaware of individual=20 flows. - The admissible link rates can be chosen small enough and the=20 supportable link rates can be chosen large enough that admitted traffic=20 can be carried after a rerouting in failure cases. This is an important=20 feature as QoS violations in core networks due to link failures are more likely than QoS violations due to increased traffic volume. - Networks are dimensioned in such a way that packet delay and loss or=20 excessive call blocking are unlikely. Thus, the effect of admission=20 control is usually not visible. It can be viewed as an insurance to=20 prevent congestion in exceptional scenarios such as excessive user load=20 or redirected traffic due to single link failures (see point above). - The preemption function complements AC to recover from sudden=20 unexpected surges of already admitted CL traffic on the links. Such=20 scenarios are very unlikely but not impossible. They can be caused by=20 large network failures that redirect lots of admitted CL traffic to=20 other links, by malfunction of the measurement-based AC in the presence=20 of a flash crowd of new admission requests, or by malfunction of the=20 measurement-based AC in the presence of admitted flows that send for a=20 while with an atypically low rate and increase their rates in a=20 concerted way. --=20 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 13 16:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTYY-0002sT-9U; Fri, 13 Oct 2006 16:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTYW-0002sE-Fc for pcn@ietf.org; Fri, 13 Oct 2006 16:22:57 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYTYR-00032y-0L for pcn@ietf.org; Fri, 13 Oct 2006 16:22:56 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 21:22:28 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Oct 2006 21:22:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Date: Fri, 13 Oct 2006 21:22:27 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD7F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4510E339.6030607@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt Thread-Index: AcbcgDUG8P/y4c9HSd2x9L2hhBk4GwSg9/LA From: To: , X-OriginalArrivalTime: 13 Oct 2006 20:22:28.0336 (UTC) FILETIME=[4DA7DF00:01C6EF05] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Whilst updating the draft I'm looking at this idea of yours -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: 20 September 2006 07:44 To: Anna Charny (acharny) Cc: pcn@ietf.org Subject: Re: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt [snip] > > 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? > =20 This proposal tries to cope with flash crowds, i.e. with many almost=20 simultaneous admission requests. The problem is that the AC can respect=20 the impact of newly admitted flows only after some time when their=20 typical sent rate influences the admission marking in the routers. I=20 think that there should be a mechanism to find out the minimum rate=20 between two border routers that is still admissible. The sum of the=20 overall declared rates of new flows should not consume more than this=20 rate. A flow is new as long as its typical rate has not yet hat an=20 impact on the packet marking, and to keep things simple, for an initial=20 time of maybe 10 s. [phil] your idea sounds interesting, but not quite sure how it works - how do you find out the minimum rate between two border routers that is still admissible? This doesn't seem easy to me. You can't just subtract the current ingress rate from some static maximum capacity for the aggregate between the two border routers. Because this capacity depends on what all the other aggregates are doing that share some of the same links as this aggregate.=20 I think you suggested in another email [sorry if I got this wrong, it's getting late here..] sending a msg from ingress to egress that quizzed each router en route about how much capacity it has left (below the configured-admission-rate [aka admissible-link-rate]). I'm not sure I like this - we're trying to have a solution that makes minimal impact on existing routers, processing this sort of msg would be a significant change? Thanks phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 16 03:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMUa-0002Sp-5v; Mon, 16 Oct 2006 03:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMUZ-0002Sk-Fi for pcn@ietf.org; Mon, 16 Oct 2006 03:02:31 -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 1GZMUX-0001AO-Vg for pcn@ietf.org; Mon, 16 Oct 2006 03:02:31 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DAA28537C; Mon, 16 Oct 2006 09:02:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CE3B5559E; Mon, 16 Oct 2006 09:02:20 +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 A25EC5196; Mon, 16 Oct 2006 09:02:20 +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 k9G72Ks14084; Mon, 16 Oct 2006 09:02:20 +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 81ABE6F58E; Mon, 16 Oct 2006 09:00:47 +0200 (CEST) Message-ID: <45332EA1.8020203@informatik.uni-wuerzburg.de> Date: Mon, 16 Oct 2006 09:02:57 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD7F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD7F@E03MVZ1-UKDY.domain1.systemhost.net> 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: b4a0a5f5992e2a4954405484e7717d8c Cc: pcn@ietf.org Subject: [PCN] Protection against flash crowds: slow-admission marking 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Phil, yes, I proposed "quizzing" the routers along the way for their unused CL capacity. When only little capacity is left, the ingress slows down its admission rate to, e.g. (1 Mbit/s)/10 s. Note that this does not require the routers to keep any states. But if quizzing still too complex, "slow-admission marking" by intermediate PCN nodes could be used: 1) no marking: there is lot's of capacity on all links and new flows can be admitted as fast as possible 2) slow-admission marking: only little admissible capacity is left and the link runs the risk being overloaded by a flash crowd when a large rate of new flows is admitted within a short interval, therefore, additional flows should be admitted only slowly. 3) stop-admission marking: the admissible link capacity is consumed and no more flows over this link should be admitted 4) excess-traffic marking: the link carries too much traffic and flows should be preempted Example: a) slow-admission threshold: 10 Mbit/s b) admissible link capacity: 20 Mbit/s c) tolerable link capacity 40 Mbit/s d) physical link bandwidth: 50 Mbit/s a) If the CL traffic rate on a link exceeds the slow-admission threshold, all packets are slow-admission marked; the egress signals the information back to the respective ingress routers which slow down their admission rate for the specific egress to, e.g., 1 (Mbit/s)/10 s. As a consequence, flash crowds cannot swamp a medium loaded system. b) If the CL traffic rate on a link exceeds the admissible link capacity, all packets are stop-admission marked; the egress signals the information back to the respective ingress routers and the they stop admitting further calls to the specific egress. c) If the CL traffic rate on a link exceeds the tolerable link capacity, all excess packets are excess-traffic marked; the egress signals the information back to the respective ingress routers and the they preempt the necessary number of calls to the specific egress. d) If the CL traffic rate on a link exceeds the physical link capacity, packet loss and heavy delay occurs. As 1), 3), and 4) already exist, two bits are needed for encoding the marking anyway, therefore, the implementation of 2) wouldn't need another bit. As slow-admission marking is technically the same as stop-admission marking, this solution should be compliant with the existing philosophy. Best wishes, Michael > Thanks > phil > -- 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 From pcn-bounces@ietf.org Mon Oct 16 03:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMg3-0007oS-K6; Mon, 16 Oct 2006 03:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMg2-0007oN-EJ for pcn@ietf.org; Mon, 16 Oct 2006 03:14:22 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMg0-0003Fq-UL for pcn@ietf.org; Mon, 16 Oct 2006 03:14:22 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 16 Oct 2006 09:14:15 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 09:14:15 +0200 Content-class: urn:content-classes:message Subject: RE: [PCN] Protection against flash crowds: slow-admission marking MIME-Version: 1.0 Date: Mon, 16 Oct 2006 09:14:14 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8D7@S4DE8PSAAFQ.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Protection against flash crowds: slow-admission marking Thread-Index: Acbw8RxNyduhuKYYTSuekFOiUWFrvgAAC/ow From: "Geib, Ruediger" To: X-OriginalArrivalTime: 16 Oct 2006 07:14:15.0280 (UTC) FILETIME=[B0097700:01C6F0F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Michael, I mentioned earlier that I also prefer PCN to work without signaling=20 between backbone routers.=20 I'm open to a discussion on mechanisms and code point consumption on=20 IP level. One of my main concerns is to allow operation of PCN=20 within an MPLS domain. There, the overall codepoint space to=20 differentiate traffic or to congestion mark it is 3 bits or=20 8 Codepoints. That means no matter what is specified for PCN on=20 IP level, a simplified and interoperable implementation should=20 be possible on MPLS level. Regards, R=FCdiger -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: Monday, October 16, 2006 9:03 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: [PCN] Protection against flash crowds: slow-admission marking Dear Phil, yes, I proposed "quizzing" the routers along the way for their unused CL = capacity. When only little capacity is left, the ingress slows down its=20 admission rate to, e.g. (1 Mbit/s)/10 s. Note that this does not require = the routers to keep any states. But if quizzing still too complex, "slow-admission marking" by=20 intermediate PCN nodes could be used: 1) no marking: there is lot's of capacity on all links and new flows can = be admitted as fast as possible 2) slow-admission marking: only little admissible capacity is left and=20 the link runs the risk being overloaded by a flash crowd when a large=20 rate of new flows is admitted within a short interval, therefore,=20 additional flows should be admitted only slowly. 3) stop-admission marking: the admissible link capacity is consumed and=20 no more flows over this link should be admitted 4) excess-traffic marking: the link carries too much traffic and flows=20 should be preempted Example: a) slow-admission threshold: 10 Mbit/s b) admissible link capacity: 20 Mbit/s c) tolerable link capacity 40 Mbit/s d) physical link bandwidth: 50 Mbit/s a) If the CL traffic rate on a link exceeds the slow-admission=20 threshold, all packets are slow-admission marked; the egress signals the = information back to the respective ingress routers which slow down their = admission rate for the specific egress to, e.g., 1 (Mbit/s)/10 s. As a=20 consequence, flash crowds cannot swamp a medium loaded system. b) If the CL traffic rate on a link exceeds the admissible link=20 capacity, all packets are stop-admission marked; the egress signals the=20 information back to the respective ingress routers and the they stop=20 admitting further calls to the specific egress. c) If the CL traffic rate on a link exceeds the tolerable link capacity, = all excess packets are excess-traffic marked; the egress signals the=20 information back to the respective ingress routers and the they preempt=20 the necessary number of calls to the specific egress. d) If the CL traffic rate on a link exceeds the physical link capacity,=20 packet loss and heavy delay occurs. As 1), 3), and 4) already exist, two bits are needed for encoding the=20 marking anyway, therefore, the implementation of 2) wouldn't need=20 another bit. As slow-admission marking is technically the same as=20 stop-admission marking, this solution should be compliant with the=20 existing philosophy. Best wishes, Michael > Thanks > phil > =20 --=20 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 16 04:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZNR5-0005hz-Uk; Mon, 16 Oct 2006 04:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZNR5-0005gI-4q for pcn@ietf.org; Mon, 16 Oct 2006 04:02:59 -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 1GZNLM-0003Z1-Dp for pcn@ietf.org; Mon, 16 Oct 2006 03:57:05 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B8B6819E1; Mon, 16 Oct 2006 09:57:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id AC84F198F; Mon, 16 Oct 2006 09:57:01 +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 4BF861466; Mon, 16 Oct 2006 09:57:01 +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 k9G7v1s14523; Mon, 16 Oct 2006 09:57:01 +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 4F0B06F58E; Mon, 16 Oct 2006 09:55:28 +0200 (CEST) Message-ID: <45333B71.7040400@informatik.uni-wuerzburg.de> Date: Mon, 16 Oct 2006 09:57:37 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" , pcn@ietf.org Subject: Re: [PCN] Protection against flash crowds: slow-admission marking References: <6439282641581441A36F7F6F83ED2ED2CBF8D7@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8D7@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Geib, Ruediger wrote: > Hello Michael, > > I mentioned earlier that I also prefer PCN to work without signaling=20 > between backbone routers.=20 > > I'm open to a discussion on mechanisms and code point consumption on=20 > IP level. One of my main concerns is to allow operation of PCN=20 > within an MPLS domain. There, the overall codepoint space to=20 > differentiate traffic or to congestion mark it is 3 bits or=20 > 8 Codepoints. That means no matter what is specified for PCN on=20 > IP level, a simplified and interoperable implementation should=20 > be possible on MPLS level. > =20 Well, as I also see this problem, I pointed out that so far 3 code=20 points have been consumed for 1) no marking, 3) stop-admission marking, and 4) excess-traffic marking. Slow-admission marking (2) would add only a fourth code point such that=20 altogether two bits are required. And the existing solution also=20 requires two bits. Best regards, Michael > Regards, > > R=FCdiger > > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Monday, October 16, 2006 9:03 AM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: [PCN] Protection against flash crowds: slow-admission marking > > > Dear Phil, > > yes, I proposed "quizzing" the routers along the way for their unused C= L=20 > capacity. When only little capacity is left, the ingress slows down its= =20 > admission rate to, e.g. (1 Mbit/s)/10 s. Note that this does not requir= e=20 > the routers to keep any states. > > But if quizzing still too complex, "slow-admission marking" by=20 > intermediate PCN nodes could be used: > > 1) no marking: there is lot's of capacity on all links and new flows ca= n=20 > be admitted as fast as possible > 2) slow-admission marking: only little admissible capacity is left and=20 > the link runs the risk being overloaded by a flash crowd when a large=20 > rate of new flows is admitted within a short interval, therefore,=20 > additional flows should be admitted only slowly. > 3) stop-admission marking: the admissible link capacity is consumed and= =20 > no more flows over this link should be admitted > 4) excess-traffic marking: the link carries too much traffic and flows=20 > should be preempted > > Example: > a) slow-admission threshold: 10 Mbit/s > b) admissible link capacity: 20 Mbit/s > c) tolerable link capacity 40 Mbit/s > d) physical link bandwidth: 50 Mbit/s > > a) If the CL traffic rate on a link exceeds the slow-admission=20 > threshold, all packets are slow-admission marked; the egress signals th= e=20 > information back to the respective ingress routers which slow down thei= r=20 > admission rate for the specific egress to, e.g., 1 (Mbit/s)/10 s. As a=20 > consequence, flash crowds cannot swamp a medium loaded system. > b) If the CL traffic rate on a link exceeds the admissible link=20 > capacity, all packets are stop-admission marked; the egress signals the= =20 > information back to the respective ingress routers and the they stop=20 > admitting further calls to the specific egress. > c) If the CL traffic rate on a link exceeds the tolerable link capacity= ,=20 > all excess packets are excess-traffic marked; the egress signals the=20 > information back to the respective ingress routers and the they preempt= =20 > the necessary number of calls to the specific egress. > d) If the CL traffic rate on a link exceeds the physical link capacity,= =20 > packet loss and heavy delay occurs. > > > As 1), 3), and 4) already exist, two bits are needed for encoding the=20 > marking anyway, therefore, the implementation of 2) wouldn't need=20 > another bit. As slow-admission marking is technically the same as=20 > stop-admission marking, this solution should be compliant with the=20 > existing philosophy. > > Best wishes, > > Michael > > =20 >> Thanks >> phil >> =20 >> =20 > > =20 --=20 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 From pcn-bounces@ietf.org Mon Oct 16 04:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOK0-0003Bh-4J; Mon, 16 Oct 2006 04:59:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOJz-0003Bc-Ae for pcn@ietf.org; Mon, 16 Oct 2006 04:59:43 -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 1GZOJx-0000m4-No for pcn@ietf.org; Mon, 16 Oct 2006 04:59:43 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0428D7166; Mon, 16 Oct 2006 10:59:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EBE117165; Mon, 16 Oct 2006 10:59:40 +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 B789A715B; Mon, 16 Oct 2006 10:59:40 +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 k9G8xes15036; Mon, 16 Oct 2006 10:59:40 +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 E8B6A6F58E; Mon, 16 Oct 2006 10:58:07 +0200 (CEST) Message-ID: <45334A20.9060705@informatik.uni-wuerzburg.de> Date: Mon, 16 Oct 2006 11:00:16 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Geib, Ruediger" Subject: Re: [PCN] Protection against flash crowds: slow-admission marking References: <6439282641581441A36F7F6F83ED2ED2CBF8D7@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8D7@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, once more again regarding the number of additional code points. I don't=20 think that all four markings need to be mandatory. There may be networks=20 operating only with stop-admission marking to perform admission control.=20 Others wish to have preemption and need, therefore, excess-traffic=20 marking. And those expecting flash crowds can implement slow-admission=20 marking in addition. Thus, there is a tradeoff between the number of=20 used features and the code point consumption. Best regards, Michael Geib, Ruediger wrote: > Hello Michael, > > I mentioned earlier that I also prefer PCN to work without signaling=20 > between backbone routers.=20 > > I'm open to a discussion on mechanisms and code point consumption on=20 > IP level. One of my main concerns is to allow operation of PCN=20 > within an MPLS domain. There, the overall codepoint space to=20 > differentiate traffic or to congestion mark it is 3 bits or=20 > 8 Codepoints. That means no matter what is specified for PCN on=20 > IP level, a simplified and interoperable implementation should=20 > be possible on MPLS level. > > Regards, > > R=FCdiger > > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Monday, October 16, 2006 9:03 AM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: [PCN] Protection against flash crowds: slow-admission marking > > > Dear Phil, > > yes, I proposed "quizzing" the routers along the way for their unused C= L=20 > capacity. When only little capacity is left, the ingress slows down its= =20 > admission rate to, e.g. (1 Mbit/s)/10 s. Note that this does not requir= e=20 > the routers to keep any states. > > But if quizzing still too complex, "slow-admission marking" by=20 > intermediate PCN nodes could be used: > > 1) no marking: there is lot's of capacity on all links and new flows ca= n=20 > be admitted as fast as possible > 2) slow-admission marking: only little admissible capacity is left and=20 > the link runs the risk being overloaded by a flash crowd when a large=20 > rate of new flows is admitted within a short interval, therefore,=20 > additional flows should be admitted only slowly. > 3) stop-admission marking: the admissible link capacity is consumed and= =20 > no more flows over this link should be admitted > 4) excess-traffic marking: the link carries too much traffic and flows=20 > should be preempted > > Example: > a) slow-admission threshold: 10 Mbit/s > b) admissible link capacity: 20 Mbit/s > c) tolerable link capacity 40 Mbit/s > d) physical link bandwidth: 50 Mbit/s > > a) If the CL traffic rate on a link exceeds the slow-admission=20 > threshold, all packets are slow-admission marked; the egress signals th= e=20 > information back to the respective ingress routers which slow down thei= r=20 > admission rate for the specific egress to, e.g., 1 (Mbit/s)/10 s. As a=20 > consequence, flash crowds cannot swamp a medium loaded system. > b) If the CL traffic rate on a link exceeds the admissible link=20 > capacity, all packets are stop-admission marked; the egress signals the= =20 > information back to the respective ingress routers and the they stop=20 > admitting further calls to the specific egress. > c) If the CL traffic rate on a link exceeds the tolerable link capacity= ,=20 > all excess packets are excess-traffic marked; the egress signals the=20 > information back to the respective ingress routers and the they preempt= =20 > the necessary number of calls to the specific egress. > d) If the CL traffic rate on a link exceeds the physical link capacity,= =20 > packet loss and heavy delay occurs. > > > As 1), 3), and 4) already exist, two bits are needed for encoding the=20 > marking anyway, therefore, the implementation of 2) wouldn't need=20 > another bit. As slow-admission marking is technically the same as=20 > stop-admission marking, this solution should be compliant with the=20 > existing philosophy. > > Best wishes, > > Michael > > =20 >> Thanks >> phil >> =20 >> =20 > > =20 --=20 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 From pcn-bounces@ietf.org Mon Oct 16 05:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOtd-0006R5-Dm; Mon, 16 Oct 2006 05:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOtb-0006Qx-E7 for pcn@ietf.org; Mon, 16 Oct 2006 05:36:31 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOtY-00034T-Rr for pcn@ietf.org; Mon, 16 Oct 2006 05:36:31 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 16 Oct 2006 11:36:25 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:36:24 +0200 Content-class: urn:content-classes:message Subject: RE: [PCN] Protection against flash crowds: slow-admission marking MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2006 11:36:24 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8DC@S4DE8PSAAFQ.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 in-reply-to: <45334A20.9060705@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Protection against flash crowds: slow-admission marking Thread-Index: AcbxAa2aRdv3880lSayC/ZYig70USwABCttw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 16 Oct 2006 09:36:24.0705 (UTC) FILETIME=[8BF86F10:01C6F106] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Michael, I share the philosophy expressed by your statement. The resulting=20 drafts hopefully separate between "basic" and "optional"=20 PCN features. Regards, R=FCdiger |-----Original Message----- |From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |Sent: Monday, October 16, 2006 11:00 AM |To: Geib, R=FCdiger |Cc: pcn@ietf.org |Subject: Re: [PCN] Protection against flash crowds: slow-admission |marking | | |Hi Ruediger, | |once more again regarding the number of additional code=20 |points. I don't=20 |think that all four markings need to be mandatory. There may=20 |be networks=20 |operating only with stop-admission marking to perform=20 |admission control.=20 |Others wish to have preemption and need, therefore, excess-traffic=20 |marking. And those expecting flash crowds can implement slow-admission=20 |marking in addition. Thus, there is a tradeoff between the number of=20 |used features and the code point consumption. | |Best regards, | | Michael | |Geib, Ruediger wrote: |> Hello Michael, |> |> I mentioned earlier that I also prefer PCN to work without signaling=20 |> between backbone routers.=20 |> |> I'm open to a discussion on mechanisms and code point consumption on=20 |> IP level. One of my main concerns is to allow operation of PCN=20 |> within an MPLS domain. There, the overall codepoint space to=20 |> differentiate traffic or to congestion mark it is 3 bits or=20 |> 8 Codepoints. That means no matter what is specified for PCN on=20 |> IP level, a simplified and interoperable implementation should=20 |> be possible on MPLS level. |> |> Regards, |> |> R=FCdiger |> |> |> -----Original Message----- |> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] |> Sent: Monday, October 16, 2006 9:03 AM |> To: philip.eardley@bt.com |> Cc: pcn@ietf.org |> Subject: [PCN] Protection against flash crowds:=20 |slow-admission marking |> |> |> Dear Phil, |> |> yes, I proposed "quizzing" the routers along the way for=20 |their unused CL=20 |> capacity. When only little capacity is left, the ingress=20 |slows down its=20 |> admission rate to, e.g. (1 Mbit/s)/10 s. Note that this does=20 |not require=20 |> the routers to keep any states. |> |> But if quizzing still too complex, "slow-admission marking" by=20 |> intermediate PCN nodes could be used: |> |> 1) no marking: there is lot's of capacity on all links and=20 |new flows can=20 |> be admitted as fast as possible |> 2) slow-admission marking: only little admissible capacity=20 |is left and=20 |> the link runs the risk being overloaded by a flash crowd=20 |when a large=20 |> rate of new flows is admitted within a short interval, therefore,=20 |> additional flows should be admitted only slowly. |> 3) stop-admission marking: the admissible link capacity is=20 |consumed and=20 |> no more flows over this link should be admitted |> 4) excess-traffic marking: the link carries too much traffic=20 |and flows=20 |> should be preempted |> |> Example: |> a) slow-admission threshold: 10 Mbit/s |> b) admissible link capacity: 20 Mbit/s |> c) tolerable link capacity 40 Mbit/s |> d) physical link bandwidth: 50 Mbit/s |> |> a) If the CL traffic rate on a link exceeds the slow-admission=20 |> threshold, all packets are slow-admission marked; the egress=20 |signals the=20 |> information back to the respective ingress routers which=20 |slow down their=20 |> admission rate for the specific egress to, e.g., 1=20 |(Mbit/s)/10 s. As a=20 |> consequence, flash crowds cannot swamp a medium loaded system. |> b) If the CL traffic rate on a link exceeds the admissible link=20 |> capacity, all packets are stop-admission marked; the egress=20 |signals the=20 |> information back to the respective ingress routers and the they stop=20 |> admitting further calls to the specific egress. |> c) If the CL traffic rate on a link exceeds the tolerable=20 |link capacity,=20 |> all excess packets are excess-traffic marked; the egress signals the=20 |> information back to the respective ingress routers and the=20 |they preempt=20 |> the necessary number of calls to the specific egress. |> d) If the CL traffic rate on a link exceeds the physical=20 |link capacity,=20 |> packet loss and heavy delay occurs. |> |> |> As 1), 3), and 4) already exist, two bits are needed for=20 |encoding the=20 |> marking anyway, therefore, the implementation of 2) wouldn't need=20 |> another bit. As slow-admission marking is technically the same as=20 |> stop-admission marking, this solution should be compliant with the=20 |> existing philosophy. |> |> Best wishes, |> |> Michael |> |> =20 |>> Thanks |>> phil |>> =20 |>> =20 |> |> =20 | |--=20 |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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 17 12:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrSc-0003Qd-Pl; Tue, 17 Oct 2006 12:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrSa-0003QW-VO for pcn@ietf.org; Tue, 17 Oct 2006 12:06:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrSW-0000Og-KP for pcn@ietf.org; Tue, 17 Oct 2006 12:06:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Oct 2006 09:06:28 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HG6S9K023595; Tue, 17 Oct 2006 12:06:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9HG6RDc011487; Tue, 17 Oct 2006 12:06:28 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 12:06:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Oct 2006 12:06:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update on the PCN BOF in Sand Diego Thread-Index: AcbyBi/Fy4ljcxkqQJi3kP/bDVN4og== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 17 Oct 2006 16:06:22.0215 (UTC) FILETIME=[3062E170:01C6F206] DKIM-Signature: a=rsa-sha1; q=dns; l=3319; t=1161101188; x=1161965188; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:Update=20on=20the=20PCN=20BOF=20in=20Sand=20Diego |To:; X=v=3Dcisco.com=3B=20h=3Dz3ULm6yAMhE33Y8SqSC7Y6PlsqM=3D; b=V8cnTo6pswrbfQzvQBLQkzT0wB33VM614XRT6+ejEkm88sF3/hOovWMr8LFq+hggOpgW5RVG 06jpR4T+SIrn4Btjm+15I4unavhbP5hdNijmXW+gqOSVXpPArRsTxu5y; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [PCN] Update on the PCN BOF in Sand Diego X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1953206344==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1953206344== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F206.302BE1C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F206.302BE1C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 1) The new San Diego IETF agenda lists the PCN BOF in the 9-11:30am slot on Monday 11/6. =20 2) Here is an updated Draft Agenda for the PCN BOF. We believe it accommodates all requests we received so far. We need to finalize the agenda by October 25, so if you have any further slot requests or feel that a previous request has not been accommodated, please let us know by October 23. Draft Agenda: 1. Agenda dashing and administrativia (5 min) 2. Overview and Introduction (20 min) 3. Key Open Items Issues (10 min) 4. Overview of existing work (10 min) 5. Open Discussion on PCN (20 min) 6. Proposed Charter (20 min) 7. Discussion of Proposed Charter (20 min) 8. Summary and conclusions (10 min) Anna and Scott, PCN BOF Chairs ------_=_NextPart_001_01C6F206.302BE1C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
 
1) The = new San Diego=20 IETF agenda lists the PCN BOF in the 9-11:30am slot on Monday=20 11/6.
 
2)=20 Here is an=20 updated Draft Agenda for the PCN BOF.  We believe it accommodates = all=20 requests we received so far.   We need to finalize the agenda = by=20 October 25, so if you have any further slot requests or feel that a = previous=20 request has not been accommodated, please let us know by October=20 23.

Draft Agenda:

1. Agenda dashing and administrativia (5=20 min)

2. Overview and Introduction (20 = min)

3. Key Open Items Issues (10 = min)

4. Overview of existing work (10 = min)

5. Open Discussion on PCN (20 = min)

6. Proposed Charter (20 min)

7. Discussion of Proposed Charter (20 = min)

8. Summary and conclusions (10 = min)

Anna and = Scott,=20 PCN BOF=20 Chairs

------_=_NextPart_001_01C6F206.302BE1C0-- --===============1953206344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============1953206344==-- From pcn-bounces@ietf.org Tue Oct 17 20:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzLC-0008Tl-Gg; Tue, 17 Oct 2006 20:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzLB-0008Tg-BF for pcn@ietf.org; Tue, 17 Oct 2006 20:31:25 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzL9-00054D-Ut for pcn@ietf.org; Tue, 17 Oct 2006 20:31:25 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9I0VLP09490 for ; Tue, 17 Oct 2006 20:31:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PCN] New Deployment Model Date: Tue, 17 Oct 2006 20:31:19 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650CAB914A@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Deployment Model Thread-Index: AcbyTLroBF+OTla1QlaQwh8STcj0Ew== From: "Jozef Babiarz" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0357973275==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0357973275== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F24C.BB4432F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F24C.BB4432F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt Title : SIP Controlled Admission and Preemption Author(s) : J. Babiarz, et al. Filename : draft-babiarz-pcn-sip-cap-00.txt Pages : 20 Date : 2006-10-16 =09 This framework defines a method of providing Explicit Congestion Control to real-time inelastic traffic like voice and video through the use of session admission control and preemption mechanisms. This approach uses the Pre-Congestion Notification Marking (PCN) [1] mechanism. PCN marking is deployed in routers to measure and convey two levels of onset of congestion with the SIP controlled endpoints responding to the marking. This approach is different from what is defined in An edge-to-edge Deployment Model for Pre-Congestion Notification [3], as here the admission and preemption control function resides in the application (either in the endpoint or the application server that controls the endpoint. This framework is focused on using Session Initiated Protocol (SIP) as the application signaling protocol but other application signaling protocols could be extended for this purpose. Looking forward to having a discussion of this approach on the list.=20 Regards, Joe Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com ------_=_NextPart_001_01C6F24C.BB4432F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [PCN] New Deployment Model

A New Internet-Draft is available from the = on-line Internet-Drafts directories.

A URL for this Internet-Draft = is:

http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt=

        Title   =         : SIP Controlled Admission = and Preemption

        Author(s)       : J. = Babiarz, et al.

        Filename        = : draft-babiarz-pcn-sip-cap-00.txt

        Pages   =         : 20

        Date    =         : = 2006-10-16

       

   This framework defines a method of providing Explicit = Congestion

   Control to real-time inelastic traffic like voice and = video through

   the use of session admission control and preemption = mechanisms.  This

   approach uses the Pre-Congestion Notification Marking = (PCN) [1]

   mechanism.  PCN marking is deployed in routers to = measure and convey

   two levels of onset of congestion with the SIP = controlled endpoints

   responding to the marking.  This approach is = different from what is

   defined in An edge-to-edge Deployment Model for = Pre-Congestion

   Notification [3], as here the admission and preemption = control

   function resides in the application (either in the = endpoint or the

   application server that controls the endpoint.  = This framework is

   focused on using Session Initiated Protocol (SIP) as = the application

   signaling protocol but other application signaling = protocols could be

   extended for this purpose.

Looking forward to having a discussion of this approach on = the list.

Regards, Joe

Telephone: 613-763-6098 (ESN 393-6098)

Email: = babiarz@nortel.com

------_=_NextPart_001_01C6F24C.BB4432F7-- --===============0357973275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --===============0357973275==-- From pcn-bounces@ietf.org Thu Oct 19 02:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaRYc-000431-88; Thu, 19 Oct 2006 02:39:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaRYb-0003yR-14 for pcn@ietf.org; Thu, 19 Oct 2006 02:39:09 -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 1GaRYY-0003S1-5u for pcn@ietf.org; Thu, 19 Oct 2006 02:39:08 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 214081B20; Thu, 19 Oct 2006 08:39:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0C13D17AC; Thu, 19 Oct 2006 08:39:01 +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 438DE1C12; Thu, 19 Oct 2006 08:38:59 +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 k9J6cxs18240; Thu, 19 Oct 2006 08:38:59 +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 602616F58E; Thu, 19 Oct 2006 08:37:24 +0200 (CEST) Message-ID: <45371DA6.7090807@informatik.uni-wuerzburg.de> Date: Thu, 19 Oct 2006 08:39:34 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jozef Babiarz , pcn@ietf.org Subject: Re: [PCN] New Deployment Model References: <9671A92C3C8B5744BC97F855F7CB64650CAB914A@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650CAB914A@zcarhxm1.corp.nortel.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: 8de5f93cb2b4e3bee75302e9eacc33db Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Jozef, I read your draft. Here are my comments. 4.1 If the admissible rate is exceeded, ALL packets running over this element must be marked. If the supportable rate is exceeded, only a fraction of the packets is marked accordingly, to allow the end systems to determine the strength of the overload. General comments: * As SIP is an end-to-end solution, this application requires all PCN clouds to have the same semantic for the encoding. I can imagine other admission control support, e.g., using RSVP based on traffic descriptors. If the SIP control is agnostic to that and admits new calls only based on PCN-feedback, this might become a problem. * Another problem might be that only SIP controlled applications react to overload while other applications using the same service class are not responsive. Best wishes, Michael Jozef Babiarz wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > A URL for this Internet-Draft is: > > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_ > > Title : SIP Controlled Admission and Preemption > > Author(s) : J. Babiarz, et al. > > Filename : draft-babiarz-pcn-sip-cap-00.txt > > Pages : 20 > > Date : 2006-10-16 > > > > This framework defines a method of providing Explicit Congestion > > Control to real-time inelastic traffic like voice and video through > > the use of session admission control and preemption mechanisms. This > > approach uses the Pre-Congestion Notification Marking (PCN) [1] > > mechanism. PCN marking is deployed in routers to measure and convey > > two levels of onset of congestion with the SIP controlled endpoints > > responding to the marking. This approach is different from what is > > defined in An edge-to-edge Deployment Model for Pre-Congestion > > Notification [3], as here the admission and preemption control > > function resides in the application (either in the endpoint or the > > application server that controls the endpoint. This framework is > > focused on using Session Initiated Protocol (SIP) as the application > > signaling protocol but other application signaling protocols could be > > extended for this purpose. > > Looking forward to having a discussion of this approach on the list. > > ///Regards, Joe/ > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > -- 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 From pcn-bounces@ietf.org Thu Oct 19 06:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVDu-00077o-8t; Thu, 19 Oct 2006 06:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVDs-00077i-FU for pcn@ietf.org; Thu, 19 Oct 2006 06:34:00 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaVDm-0005PI-UC for pcn@ietf.org; Thu, 19 Oct 2006 06:34:00 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9JAXhM15105; Thu, 19 Oct 2006 06:33:43 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.102.177.210] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 06:33:41 -0400 Message-Id: <6.2.5.6.0.20061019061545.0359b6b0@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Oct 2006 06:33:40 -0400 To: menth@informatik.uni-wuerzburg.de From: "Kwok-Ho Chan" Subject: Re: [PCN] New Deployment Model In-Reply-To: <45371DA6.7090807@informatik.uni-wuerzburg.de> References: <9671A92C3C8B5744BC97F855F7CB64650CAB914A@zcarhxm1.corp.nortel.com> <45371DA6.7090807@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Oct 2006 10:33:42.0044 (UTC) FILETIME=[0C05FDC0:01C6F36A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael: Please see in-line below. -- Kwok -- At 02:39 AM 10/19/2006, Michael Menth wrote: >Dear Jozef, > >I read your draft. Here are my comments. > >4.1 If the admissible rate is exceeded, ALL packets running over >this element must be marked. If the supportable rate is exceeded, >only a fraction of the packets is marked accordingly, to allow the >end systems to determine the strength of the overload. > >General comments: >* As SIP is an end-to-end solution, this application requires all >PCN clouds to have the same semantic for the encoding. I can imagine >other admission control support, e.g., using RSVP based on traffic >descriptors. If the SIP control is agnostic to that and admits new >calls only based on PCN-feedback, this might become a problem. SIP proxy can also be used. Hence this is not just an end-to-end solution. The PCN encoding will need to use the agreed on meaning when it reach the PENs. But if some domain in the middle does not support PCN, and instead use some other admission method, that domain will need to indicate the PCN condition (think of this domain be represented as one hop of PCN). This view may help the interfacing between different methods. Also, the use of PCN will allow the network to change routes, etc in the middle (PINs). Hence the SIP control will be agnostic to the exact packet route used and the route's exact method. For example if QoS routing is employed in the middle. That QoS routing capable region may not cause PCN Marking by reacting and solving any QoS problem before indicating using PCN Marking is needed. >* Another problem might be that only SIP controlled applications >react to overload while other applications using the same service >class are not responsive. Yes. The PCN capable traffic will need to be separated from the other traffic. This is also true with ECN (RFC 3168) with TCP. What happens if some end points are not good citizens? This becomes a fairness issue. Hope this helps. >Best wishes, > > Michael > > >Jozef Babiarz wrote: >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >>A URL for this Internet-Draft is: >> >>_http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_ >> >> Title : SIP Controlled Admission and Preemption >> >> Author(s) : J. Babiarz, et al. >> >> Filename : draft-babiarz-pcn-sip-cap-00.txt >> >> Pages : 20 >> >> Date : 2006-10-16 >> >> >> >> This framework defines a method of providing Explicit Congestion >> >> Control to real-time inelastic traffic like voice and video through >> >> the use of session admission control and preemption mechanisms. This >> >> approach uses the Pre-Congestion Notification Marking (PCN) [1] >> >> mechanism. PCN marking is deployed in routers to measure and convey >> >> two levels of onset of congestion with the SIP controlled endpoints >> >> responding to the marking. This approach is different from what is >> >> defined in An edge-to-edge Deployment Model for Pre-Congestion >> >> Notification [3], as here the admission and preemption control >> >> function resides in the application (either in the endpoint or the >> >> application server that controls the endpoint. This framework is >> >> focused on using Session Initiated Protocol (SIP) as the application >> >> signaling protocol but other application signaling protocols could be >> >> extended for this purpose. >> >>Looking forward to having a discussion of this approach on the list. >> >>///Regards, Joe/ >> >>Telephone: 613-763-6098 (ESN 393-6098) >> >>Email: babiarz@nortel.com >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www1.ietf.org/mailman/listinfo/pcn >> > >-- >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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 20 00:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalnF-0007KU-NZ; Fri, 20 Oct 2006 00:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GalnE-0007Hq-OF for pcn@ietf.org; Fri, 20 Oct 2006 00:15:36 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GalnB-0008Fg-Ao for pcn@ietf.org; Fri, 20 Oct 2006 00:15:36 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9K48n220200; Fri, 20 Oct 2006 00:08:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] New Deployment Model Date: Fri, 20 Oct 2006 00:15:29 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650CB7321D@zcarhxm1.corp.nortel.com> In-Reply-To: <45371DA6.7090807@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Deployment Model Thread-Index: AcbzSUemK7Bgx2GCRZS3ZHMHnaQJbwAroEcQ From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, see my explanation below, I hope they help. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Thursday, October 19, 2006 2:40 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: Re: [PCN] New Deployment Model Dear Jozef, I read your draft. Here are my comments. 4.1 If the admissible rate is exceeded, ALL packets running over this=20 element must be marked. If the supportable rate is exceeded, only a=20 fraction of the packets is marked accordingly, to allow the end systems=20 to determine the strength of the overload. [Joe] To block admission of new sessions, it is desirable that all packets in that service calls are marked by the element that is experience that bandwidth utilization above admissible level. The main reason being that during session setup SIP controlled endpoints are sending probe packets to test the path and if the network element in questions did not mark all packets belonging to the service class, the endpoint most like would not see any marking and would admit new session.=20 Now if the supportable rate is exceeded, one packet every n bytes of excess traffic is marked. What I'm suggestion is that the network element that experience traffic above the supportable rate selects the flow to be removed by marking a packet similar to what ECN does for TCP flows to reduce sending rate. In this deployment model normal there is only one flow per endpoint so trying to measure the level of overload is not that practical. For deployments scenarios where edge node has many flows excess rate may be measured by counting the number of market packets and multiplying by n bytes over counting time. =20 General comments: * As SIP is an end-to-end solution, this application requires all PCN=20 clouds to have the same semantic for the encoding. I can imagine other=20 admission control support, e.g., using RSVP based on traffic=20 descriptors. If the SIP control is agnostic to that and admits new calls only based on PCN-feedback, this might become a problem. [Joe] Yes both endpoints need to use the same semantics or be aware that semantic are different. This approach allows other admission control methods to be used in different network segments. Should RSVP be used, in one network segment the reservation would need to be completed before SIP session would be allowed to continue or if a different approach was used the probe packets would need to be received by the other endpoint before session setup could be completed. Can you explain a situation which would cause a problem? * Another problem might be that only SIP controlled applications react=20 to overload while other applications using the same service class are=20 not responsive. [Joe] Yes, this is an issue. One approach is to use the Not-ECT "00" codepoint to represent flows that are not control by this mechanize or to use a different DS codepoint. This is an issue that needs to be discussed on how best it can be resolved. =20 Best wishes, Michael Jozef Babiarz wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > A URL for this Internet-Draft is: > > _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_ > > Title : SIP Controlled Admission and Preemption > > Author(s) : J. Babiarz, et al. > > Filename : draft-babiarz-pcn-sip-cap-00.txt > > Pages : 20 > > Date : 2006-10-16 > > =20 > > This framework defines a method of providing Explicit Congestion > > Control to real-time inelastic traffic like voice and video through > > the use of session admission control and preemption mechanisms. This > > approach uses the Pre-Congestion Notification Marking (PCN) [1] > > mechanism. PCN marking is deployed in routers to measure and convey > > two levels of onset of congestion with the SIP controlled endpoints > > responding to the marking. This approach is different from what is > > defined in An edge-to-edge Deployment Model for Pre-Congestion > > Notification [3], as here the admission and preemption control > > function resides in the application (either in the endpoint or the > > application server that controls the endpoint. This framework is > > focused on using Session Initiated Protocol (SIP) as the application > > signaling protocol but other application signaling protocols could be > > extended for this purpose. > > Looking forward to having a discussion of this approach on the list. > > ///Regards, Joe/ > > Telephone: 613-763-6098 (ESN 393-6098) > > Email: babiarz@nortel.com > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =20 --=20 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 From pcn-bounces@ietf.org Fri Oct 20 09:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauU7-0004HP-ST; Fri, 20 Oct 2006 09:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauU6-0004F7-Nh for pcn@ietf.org; Fri, 20 Oct 2006 09:32:26 -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 1GauU3-0007Wj-23 for pcn@ietf.org; Fri, 20 Oct 2006 09:32:26 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 012341C33; Fri, 20 Oct 2006 15:32:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E90F71C2E; Fri, 20 Oct 2006 15:32:19 +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 7BBC71BE8; Fri, 20 Oct 2006 15:32:19 +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 k9KDWJs01779; Fri, 20 Oct 2006 15:32:19 +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 8FBE56F58E; Fri, 20 Oct 2006 15:30:42 +0200 (CEST) Message-ID: <4538D003.6020902@informatik.uni-wuerzburg.de> Date: Fri, 20 Oct 2006 15:32:51 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] New Deployment Model References: <9671A92C3C8B5744BC97F855F7CB64650CB7321D@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650CB7321D@zcarhxm1.corp.nortel.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: 0e9ebc0cbd700a87c0637ad0e2c91610 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Jozef, see inline! Jozef Babiarz wrote: > Michael, see my explanation below, I hope they help. > > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Thursday, October 19, 2006 2:40 AM > To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org > Subject: Re: [PCN] New Deployment Model > > Dear Jozef, > > I read your draft. Here are my comments. > > 4.1 If the admissible rate is exceeded, ALL packets running over this > element must be marked. If the supportable rate is exceeded, only a > fraction of the packets is marked accordingly, to allow the end systems > to determine the strength of the overload. > > [Joe] To block admission of new sessions, it is desirable that all > packets in that service calls are marked by the element that is > experience that bandwidth utilization above admissible level. The main > reason being that during session setup SIP controlled endpoints are > sending probe packets to test the path and if the network element in > questions did not mark all packets belonging to the service class, the > endpoint most like would not see any marking and would admit new > session. > Now if the supportable rate is exceeded, one packet every n bytes of > excess traffic is marked. What I'm suggestion is that the network > element that experience traffic above the supportable rate selects the > flow to be removed by marking a packet similar to what ECN does for TCP > flows to reduce sending rate. In this deployment model normal there is > only one flow per endpoint so trying to measure the level of overload is > not that practical. For deployments scenarios where edge node has many > flows excess rate may be measured by counting the number of market > packets and multiplying by n bytes over counting time. > > General comments: > * As SIP is an end-to-end solution, this application requires all PCN > clouds to have the same semantic for the encoding. I can imagine other > admission control support, e.g., using RSVP based on traffic > descriptors. If the SIP control is agnostic to that and admits new calls > > only based on PCN-feedback, this might become a problem. > > [Joe] Yes both endpoints need to use the same semantics or be aware that > semantic are different. This approach allows other admission control > methods to be used in different network segments. Should RSVP be used, > in one network segment the reservation would need to be completed before > SIP session would be allowed to continue or if a different approach was > used the probe packets would need to be received by the other endpoint > before session setup could be completed. Can you explain a situation > which would cause a problem? > I don't know how this should work. Does the probe packet trigger a reservation request through the RSVP-controlled cloud? Probably, we are here already right in the middle of a discussion how to achieve end-to-end QoS while PCN is a local solution for a PCN domain. I can imagine that different domains have different QoS protocols/mechanisms and that there must be another protocol talking with these domains to find out whether a flow can be admitted end-to-end. From my perspective, SIP should be based on such an end-to-end protocol, otherwise the solution can be safely applied only within a PCN-domain, e.g., within a comany, or SIP proxies must be used as workaround as Kwok mentioned in his last email. Best wishes, Michael > * Another problem might be that only SIP controlled applications react > to overload while other applications using the same service class are > not responsive. > > [Joe] Yes, this is an issue. One approach is to use the Not-ECT "00" > codepoint to represent flows that are not control by this mechanize or > to use a different DS codepoint. This is an issue that needs to be > discussed on how best it can be resolved. > > Best wishes, > > Michael > > > Jozef Babiarz wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> A URL for this Internet-Draft is: >> >> _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_ >> >> Title : SIP Controlled Admission and Preemption >> >> Author(s) : J. Babiarz, et al. >> >> Filename : draft-babiarz-pcn-sip-cap-00.txt >> >> Pages : 20 >> >> Date : 2006-10-16 >> >> >> >> This framework defines a method of providing Explicit Congestion >> >> Control to real-time inelastic traffic like voice and video through >> >> the use of session admission control and preemption mechanisms. >> > This > >> approach uses the Pre-Congestion Notification Marking (PCN) [1] >> >> mechanism. PCN marking is deployed in routers to measure and >> > convey > >> two levels of onset of congestion with the SIP controlled endpoints >> >> responding to the marking. This approach is different from what is >> >> defined in An edge-to-edge Deployment Model for Pre-Congestion >> >> Notification [3], as here the admission and preemption control >> >> function resides in the application (either in the endpoint or the >> >> application server that controls the endpoint. This framework is >> >> focused on using Session Initiated Protocol (SIP) as the >> > application > >> signaling protocol but other application signaling protocols could >> > be > >> extended for this purpose. >> >> Looking forward to having a discussion of this approach on the list. >> >> ///Regards, Joe/ >> >> Telephone: 613-763-6098 (ESN 393-6098) >> >> Email: babiarz@nortel.com >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> >> > > -- 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 From pcn-bounces@ietf.org Fri Oct 20 10:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav68-0000Ri-Vf; Fri, 20 Oct 2006 10:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav68-0000Rd-2a for pcn@ietf.org; Fri, 20 Oct 2006 10:11:44 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gav60-0005t6-WC for pcn@ietf.org; Fri, 20 Oct 2006 10:11:44 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9KEBXe06751; Fri, 20 Oct 2006 10:11:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] New Deployment Model Date: Fri, 20 Oct 2006 10:11:32 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650CB735CC@zcarhxm1.corp.nortel.com> In-Reply-To: <4538D003.6020902@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New Deployment Model Thread-Index: Acb0TDfrOiGhre3vShiOIrU7xLrSlwAAQ/TA From: "Jozef Babiarz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael wrote: I don't know how this should work. Does the probe packet trigger a reservation request through the RSVP-controlled cloud?=20 [Joe] No. SIP triggers reservation request in RSVP-controlled cloud. The assumption is SIP precondition (RFC 3312) is used in both RSVP and this approach. Alerting of the called party (admission) is delayed until all conditions are met.=20 Probably, we are here already right in the middle of a discussion how to achieve end-to-end QoS while PCN is a local solution for a PCN domain.=20 [Joe] I do not view PCN being only a local solution. Yes for simplicity, our initial trust is to focus on a single domain and delay all the trust issues between different domains, but PCN like ECN can be end-to-end. I can imagine that different domains have different QoS protocols/mechanisms and that there must be another protocol talking with these domains to find out whether a flow can be admitted end-to-end. From my perspective, SIP should be based on such an end-to-end protocol, otherwise the solution can be safely applied only within a PCN-domain, e.g., within a company, or SIP proxies must be used as workaround as Kwok mentioned in his last email. [Joe] I think we are in agreement. If a domain use other than the PCN method for admission control, that domain needs a method to inform SIP that it can or can not support that new session. Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Friday, October 20, 2006 9:33 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] New Deployment Model Dear Jozef, see inline! Jozef Babiarz wrote: > Michael, see my explanation below, I hope they help. > > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: Thursday, October 19, 2006 2:40 AM > To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org > Subject: Re: [PCN] New Deployment Model > > Dear Jozef, > > I read your draft. Here are my comments. > > 4.1 If the admissible rate is exceeded, ALL packets running over this=20 > element must be marked. If the supportable rate is exceeded, only a=20 > fraction of the packets is marked accordingly, to allow the end systems=20 > to determine the strength of the overload. > > [Joe] To block admission of new sessions, it is desirable that all > packets in that service calls are marked by the element that is > experience that bandwidth utilization above admissible level. The main > reason being that during session setup SIP controlled endpoints are > sending probe packets to test the path and if the network element in > questions did not mark all packets belonging to the service class, the > endpoint most like would not see any marking and would admit new > session.=20 > Now if the supportable rate is exceeded, one packet every n bytes of > excess traffic is marked. What I'm suggestion is that the network > element that experience traffic above the supportable rate selects the > flow to be removed by marking a packet similar to what ECN does for TCP > flows to reduce sending rate. In this deployment model normal there is > only one flow per endpoint so trying to measure the level of overload is > not that practical. For deployments scenarios where edge node has many > flows excess rate may be measured by counting the number of market > packets and multiplying by n bytes over counting time. =20 > > General comments: > * As SIP is an end-to-end solution, this application requires all PCN=20 > clouds to have the same semantic for the encoding. I can imagine other > admission control support, e.g., using RSVP based on traffic=20 > descriptors. If the SIP control is agnostic to that and admits new calls > > only based on PCN-feedback, this might become a problem. > > [Joe] Yes both endpoints need to use the same semantics or be aware that > semantic are different. This approach allows other admission control > methods to be used in different network segments. Should RSVP be used, > in one network segment the reservation would need to be completed before > SIP session would be allowed to continue or if a different approach was > used the probe packets would need to be received by the other endpoint > before session setup could be completed. Can you explain a situation > which would cause a problem? > =20 I don't know how this should work. Does the probe packet trigger a=20 reservation request through the RSVP-controlled cloud? Probably, we are=20 here already right in the middle of a discussion how to achieve=20 end-to-end QoS while PCN is a local solution for a PCN domain. I can=20 imagine that different domains have different QoS protocols/mechanisms=20 and that there must be another protocol talking with these domains to=20 find out whether a flow can be admitted end-to-end. From my perspective, SIP should be based on such an end-to-end protocol, otherwise the=20 solution can be safely applied only within a PCN-domain, e.g., within a=20 comany, or SIP proxies must be used as workaround as Kwok mentioned in=20 his last email. Best wishes, Michael > * Another problem might be that only SIP controlled applications react > to overload while other applications using the same service class are=20 > not responsive. > > [Joe] Yes, this is an issue. One approach is to use the Not-ECT "00" > codepoint to represent flows that are not control by this mechanize or > to use a different DS codepoint. This is an issue that needs to be > discussed on how best it can be resolved. =20 > > Best wishes, > > Michael > > > Jozef Babiarz wrote: > =20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> A URL for this Internet-Draft is: >> >> _http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt_ >> >> Title : SIP Controlled Admission and Preemption >> >> Author(s) : J. Babiarz, et al. >> >> Filename : draft-babiarz-pcn-sip-cap-00.txt >> >> Pages : 20 >> >> Date : 2006-10-16 >> >> =20 >> >> This framework defines a method of providing Explicit Congestion >> >> Control to real-time inelastic traffic like voice and video through >> >> the use of session admission control and preemption mechanisms. >> =20 > This > =20 >> approach uses the Pre-Congestion Notification Marking (PCN) [1] >> >> mechanism. PCN marking is deployed in routers to measure and >> =20 > convey > =20 >> two levels of onset of congestion with the SIP controlled endpoints >> >> responding to the marking. This approach is different from what is >> >> defined in An edge-to-edge Deployment Model for Pre-Congestion >> >> Notification [3], as here the admission and preemption control >> >> function resides in the application (either in the endpoint or the >> >> application server that controls the endpoint. This framework is >> >> focused on using Session Initiated Protocol (SIP) as the >> =20 > application > =20 >> signaling protocol but other application signaling protocols could >> =20 > be > =20 >> extended for this purpose. >> >> Looking forward to having a discussion of this approach on the list. >> >> ///Regards, Joe/ >> >> Telephone: 613-763-6098 (ESN 393-6098) >> >> Email: babiarz@nortel.com >> >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> =20 >> =20 > > =20 --=20 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 From pcn-bounces@ietf.org Mon Oct 23 04:17:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbv0P-00032x-Tl; Mon, 23 Oct 2006 04:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbv0M-00032A-UQ; Mon, 23 Oct 2006 04:17:55 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbv0A-0005yR-U7; Mon, 23 Oct 2006 04:17:54 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 09:17:37 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Oct 2006 09:17:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6F67B.B18DAA23" Date: Mon, 23 Oct 2006 09:17:34 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CD84@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: updated draft-briscoe-tsvwg-cl-architecture-04.txt Thread-Index: Acb0WSF4TV5FGueyRy+wkFJbXr87wgCIix1w From: To: X-OriginalArrivalTime: 23 Oct 2006 08:17:35.0525 (UTC) FILETIME=[B20D1550:01C6F67B] X-Spam-Score: 0.7 (/) X-Scan-Signature: bab7ecbf9d9a8789530a24b23fbf0269 Cc: pcn@ietf.org Subject: [PCN] updated draft-briscoe-tsvwg-cl-architecture-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F67B.B18DAA23 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6F67B.B18DAA23" ------_=_NextPart_002_01C6F67B.B18DAA23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Attached is updated draft draft-briscoe-tsvwg-cl-architecture-04.txt. Please post. =20 Thanks, Philip Eardley=20 ------_=_NextPart_002_01C6F67B.B18DAA23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Attached is updated draft = draft-briscoe-tsvwg-cl-architecture-04.txt.  Please post.

 

Thanks,

Philip Eardley

=00 ------_=_NextPart_002_01C6F67B.B18DAA23-- ------_=_NextPart_001_01C6F67B.B18DAA23 Content-Type: text/plain; name="draft-briscoe-tsvwg-cl-architecture-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-briscoe-tsvwg-cl-architecture-04.txt Content-Disposition: attachment; filename="draft-briscoe-tsvwg-cl-architecture-04.txt" VFNWV0cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEIuIEJyaXNjb2UgCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQLiBFYXJkbGV5ICAKZHJhZnQtYnJpc2NvZS10c3Z3Zy1jbC1h cmNoaXRlY3R1cmUtMDQudHh0ICAgICAgICAgICAgICAgICBELiBTb25naHVyc3QgIApFeHBpcmVz OiBBcHJpbCAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBCVCAKIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEYuIExlIEZhdWNoZXVyIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIENoYXJueSAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMsIEluYyAK IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEouIEJhYmlhcnogCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBLLiBDaGFuIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBEdWRsZXkgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vcnRl bCAKIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEcuIEthcmFnaWFubmlzIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBVbml2ZXJzaXR5IG9mIFR3ZW50ZSAvIEVyaWNzc29uIAogCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBCYWRlciAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEwuIFdl c3RiZXJnIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRXJpY3Nzb24gCiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMjUgT2N0b2JlciwgMjAwNiAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgIEFuIGVkZ2UtdG8tZWRnZSBE ZXBsb3ltZW50IE1vZGVsIGZvciBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb246ICAKICAgICAg ICAgICAgICAgICBBZG1pc3Npb24gQ29udHJvbCBvdmVyIGEgRGlmZlNlcnYgUmVnaW9uIAogICAg ICAgICAgICAgICAgZHJhZnQtYnJpc2NvZS10c3Z3Zy1jbC1hcmNoaXRlY3R1cmUtMDQudHh0IAoK ClN0YXR1cyBvZiB0aGlzIE1lbW8gCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJh ZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkgCiAgIGFwcGxpY2FibGUgcGF0ZW50 IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlIAogICBoYXZl IGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJl Y29tZXMgCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2Vj dGlvbiA2IG9mIEJDUCA3OS4gCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyAKICAgVGFzayBGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCAKICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAg IERyYWZ0cy4gCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IAogICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSAKICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mi LiAKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCAKICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQg CiAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQg TW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCAK ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIAoKICAgVGhpcyBJbnRlcm5l dC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgNiwgMjAwNi4gCgpDb3B5cmlnaHQgTm90 aWNlIAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuICBBbGwg UmlnaHRzIFJlc2VydmVkLiAKCkFic3RyYWN0ICAKClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg ZGVwbG95bWVudCBtb2RlbCBmb3IgcHJlLWNvbmdlc3Rpb24gCm5vdGlmaWNhdGlvbiAoUENOKSBv cGVyYXRpbmcgaW4gYSBsYXJnZSBEaWZmU2Vydi1iYXNlZCByZWdpb24gb2YgdGhlIApJbnRlcm5l dC4gUENOLWJhc2VkIGFkbWlzc2lvbiBjb250cm9sIHByb3RlY3RzIHRoZSBxdWFsaXR5IG9mIHNl cnZpY2UgCm9mIGV4aXN0aW5nIGZsb3dzIGluIG5vcm1hbCBjaXJjdW1zdGFuY2VzLCB3aGlsc3Qg aWYgbmVjZXNzYXJ5IChlZyAKYWZ0ZXIgYSBsYXJnZSBmYWlsdXJlKSBwcmUtZW1wdGlvbiBvZiBz b21lIGZsb3dzIHByZXNlcnZlcyB0aGUgcXVhbGl0eSAKb2Ygc2VydmljZSBvZiB0aGUgcmVtYWlu aW5nIGZsb3dzLiBFYWNoIGxpbmsgaGFzIGEgY29uZmlndXJlZC0KYWRtaXNzaW9uLXJhdGUgYW5k IGEgY29uZmlndXJlZC1wcmUtZW1wdGlvbi1yYXRlLCBhbmQgYSByb3V0ZXIgbWFya3MgCnBhY2tl dHMgdGhhdCBleGNlZWQgdGhlc2UgcmF0ZXMuIEhlbmNlIHJvdXRlcnMgZ2l2ZSBhbiBlYXJseSB3 YXJuaW5nIG9mIAp0aGVpciBvd24gcG90ZW50aWFsIGNvbmdlc3Rpb24sIGJlZm9yZSBwYWNrZXRz IG5lZWQgdG8gYmUgZHJvcHBlZC4gCkdhdGV3YXlzIGFyb3VuZCB0aGUgZWRnZXMgb2YgdGhlIFBD Ti1yZWdpb24gY29udmVydCBtZWFzdXJlbWVudHMgb2YgCnBhY2tldCByYXRlcyBhbmQgdGhlaXIg bWFya2luZ3MgaW50byBkZWNpc2lvbnMgYWJvdXQgd2hldGhlciB0byBhZG1pdCAKbmV3IGZsb3dz LCBhbmQgKGlmIG5lY2Vzc2FyeSkgaW50byB0aGUgcmF0ZSBvZiBleGNlc3MgdHJhZmZpYyB0aGF0 IApzaG91bGQgYmUgcHJlLWVtcHRlZC4gUGVyLWZsb3cgYWRtaXNzaW9uIHN0YXRlcyBhcmUga2Vw dCBhdCB0aGUgCmdhdGV3YXlzIG9ubHksIHdoaWxlIHRoZSBQQ04gbWFya2VycyB0aGF0IGFyZSBy ZXF1aXJlZCBmb3IgYWxsIHJvdXRlcnMgCm9wZXJhdGUgb24gdGhlIGFnZ3JlZ2F0ZSB0cmFmZmlj IC0gaGVuY2UgdGhlcmUgaXMgbm8gc2NhbGFiaWxpdHkgaW1wYWN0IApvbiBpbnRlcmlvciByb3V0 ZXJzLiAgCgpBdXRob3JzJyBOb3RlIChUTyBCRSBERUxFVEVEIEJZIFRIRSBSRkMgRURJVE9SIFVQ T04gUFVCTElDQVRJT04pIAoKICAgVGhpcyBkb2N1bWVudCBpcyBwb3N0ZWQgYXMgYW4gSW50ZXJu ZXQtRHJhZnQgd2l0aCB0aGUgaW50ZW50aW9uIG9mIAogICBldmVudHVhbGx5IGJlY29taW5nIGFu IElORk9STUFUSU9OQUwgUkZDLiAKCiAKCiAgICAKCiAgICAKCiAgICAKCiAgICAKCiAgICAKCgoK IAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAg ICAgICAgICAgW1BhZ2UgMl0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9k ZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKVGFibGUgb2YgQ29udGVu dHMgCgogICAgCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjUgCiAgICAgIDEuMS4gU3VtbWFyeS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgCiAgICAgIDEuMi4gS2V5IGJlbmVmaXRz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggCiAgICAgIDEuMy4g VGVybWlub2xvZ3kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkg CiAgICAgIDEuNC4gRXhpc3RpbmcgdGVybWlub2xvZ3kuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjExIAogICAgICAxLjUuIFN0YW5kYXJkaXNhdGlvbiByZXF1aXJlbWVudHMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSAKICAgICAgMS42LiBTdHJ1Y3R1cmUgb2YgcmVzdCBv ZiB0aGUgZG9jdW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIgCiAgIDIuIEtleSBhc3BlY3Rz IG9mIHRoZSBkZXBsb3ltZW50IG1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzIAogICAg ICAyLjEuIEtleSBnb2Fscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjEzIAogICAgICAyLjIuIEtleSBhc3N1bXB0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xNCAKICAgMy4gRGVwbG95bWVudCBtb2RlbC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNyAKICAgICAgMy4xLiBBZG1pc3Npb24gY29u dHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgCiAgICAgICAgIDMu MS4xLiBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gZm9yIEFkbWlzc2lvbiBNYXJraW5nLi4x NyAKICAgICAgICAgMy4xLjIuIE1lYXN1cmVtZW50cyB0byBzdXBwb3J0IGFkbWlzc2lvbiBjb250 cm9sLi4uLi4uLi4uLjE3IAogICAgICAgICAzLjEuMy4gSG93IGVkZ2UtdG8tZWRnZSBhZG1pc3Np b24gY29udHJvbCBzdXBwb3J0cyBlbmQtdG8tZW5kIAogICAgICAgICBRb1Mgc2lnbmFsbGluZy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4IAogICAgICAgICAzLjEu NC4gVXNlIGNhc2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4IAog ICAgICAzLjIuIEZsb3cgcHJlLWVtcHRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4yMCAKICAgICAgICAgMy4yLjEuIEFsZXJ0aW5nIGFuIGluZ3Jlc3MgZ2F0ZXdheSB0 aGF0IGZsb3cgcHJlLWVtcHRpb24gbWF5IGJlIAogICAgICAgICBuZWVkZWQuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwIAogICAgICAgICAzLjIuMi4g RGV0ZXJtaW5pbmcgdGhlIHJpZ2h0IGFtb3VudCBvZiBDTCB0cmFmZmljIHRvIGRyb3AuMjMgCiAg ICAgICAgIDMuMi4zLiBVc2UgY2FzZSBmb3IgZmxvdyBwcmUtZW1wdGlvbi4uLi4uLi4uLi4uLi4u Li4uLi4uLjI0IAogICAgICAzLjMuIEJvdGggYWRtaXNzaW9uIGNvbnRyb2wgYW5kIHByZS1lbXB0 aW9uLi4uLi4uLi4uLi4uLi4uLi4yNSAKICAgNC4gU3VtbWFyeSBvZiBGdW5jdGlvbmFsaXR5Li4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgCiAgICAgIDQuMS4gSW5ncmVzcyBn YXRld2F5cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI3IAogICAgICA0 LjIuIEludGVyaW9yIHJvdXRlcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4yOCAKICAgICAgNC4zLiBFZ3Jlc3MgZ2F0ZXdheXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjggCiAgICAgIDQuNC4gRmFpbHVyZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjkgCiAgIDUuIExpbWl0YXRpb25zIGFuZCBzb21l IHBvdGVudGlhbCBzb2x1dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLjMxIAogICAgICA1LjEuIEVD TVAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMxIAog ICAgICA1LjIuIEJlYXQgZG93biBlZmZlY3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4zMyAKICAgICAgNS4zLiBCaS1kaXJlY3Rpb25hbCBzZXNzaW9ucy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMzUgCiAgICAgIDUuNC4gR2xvYmFsIGZhaXJuZXNzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM3IAogICAgICA1LjUuIEZsYXNoIGNy b3dkcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM5IAogICAgICA1 LjYuIFByZS1lbXB0aW5nIHRvbyBmYXN0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li40MSAKICAgICAgNS43LiBPdGhlciBwb3RlbnRpYWwgZXh0ZW5zaW9ucy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uNDIgCiAgICAgICAgIDUuNy4xLiBUdW5uZWxsaW5nLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQyIAogICAgICAgICA1LjcuMi4gTXVsdGktZG9t YWluIGFuZCBtdWx0aS1vcGVyYXRvciB1c2FnZS4uLi4uLi4uLi4uLi40MyAKICAgICAgICAgNS43 LjMuIFByZWZlcmVudGlhbCBkcm9wcGluZyBvZiBwcmUtZW1wdGlvbiBtYXJrZWQgcGFja2V0czQ0 IAogICAgICAgICA1LjcuNC4gQWRhcHRpdmUgYmFuZHdpZHRoIGZvciB0aGUgQ29udHJvbGxlZCBM b2FkIHNlcnZpY2UuNDQgCiAgICAgICAgIDUuNy41LiBDb250cm9sbGVkIExvYWQgc2VydmljZSB3 aXRoIGVuZC10by1lbmQgUHJlLUNvbmdlc3Rpb24gCiAgICAgICAgIE5vdGlmaWNhdGlvbi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDUgCiAgICAgICAgIDUuNy42 LiBNUExTLVRFLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNDUgCiAg IDYuIFJlbGF0aW9uc2hpcCB0byBvdGhlciBRb1MgbWVjaGFuaXNtcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQ2IAogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAy MDA3ICAgICAgICAgICAgICAgICBbUGFnZSAzXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVw bG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICAg ICA2LjEuIEludFNlcnYgQ29udHJvbGxlZCBMb2FkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi40NiAKICAgICAgNi4yLiBJbnRlZ3JhdGVkIHNlcnZpY2VzIG9wZXJhdGlvbiBvdmVyIERp ZmZTZXJ2Li4uLi4uLi4uLi4uNDYgCiAgICAgIDYuMy4gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ2IAogICAgICA2LjQuIEVDTi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ3IAogICAgICA2LjUu IFJURUNOLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ3 IAogICAgICA2LjYuIFJNRC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjQ4IAogICAgICA2LjcuIFJTVlAgQWdncmVnYXRpb24gb3ZlciBNUExTLVRFLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi40OCAKICAgICAgNi44LiBPdGhlciBOZXR3b3JrIEFkbWlz c2lvbiBDb250cm9sIEFwcHJvYWNoZXMuLi4uLi4uLi4uLi4uNDggCiAgIDcuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQ5IAogICA4 LiBBY2tub3dsZWRnZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjQ5IAogICA5LiBDb21tZW50cyBzb2xpY2l0ZWQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjUwIAogICAxMC4gQ2hhbmdlcyBmcm9tIGVhcmxpZXIgdmVyc2lvbnMg b2YgdGhlIGRyYWZ0Li4uLi4uLi4uLi4uLi4uLi41MCAKICAgMTEuIEFwcGVuZGljZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41MiAKICAgICAgMTEuMS4g QXBwZW5kaXggQTogRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24uLi4uLi4uLi4uNTIg CiAgICAgIDExLjIuIEFwcGVuZGl4IEI6IFdoYXQgaXMgZGlzdHJpYnV0ZWQgbWVhc3VyZW1lbnQt YmFzZWQgYWRtaXNzaW9uIAogICAgICBjb250cm9sPy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUzIAogICAgICAxMS4zLiBBcHBlbmRpeCBDOiBDYWxj dWxhdGluZyB0aGUgRXhwb25lbnRpYWxseSB3ZWlnaHRlZCBtb3ZpbmcgCiAgICAgIGF2ZXJhZ2Ug KEVXTUEpLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTQgCiAg IDEyLiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uNTYgCiAgIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNjEgCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYzIAogICBEaXNjbGFpbWVyIG9mIFZhbGlk aXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYzIAogICBDb3B5cmln aHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYz IAogICAgCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBF eHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA0XSAKDApJbnRlcm5l dC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2Jl ciAyMDA2IAogICAgCgoxLiBJbnRyb2R1Y3Rpb24gCgoxLjEuIFN1bW1hcnkgIAoKICAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBkZXBsb3ltZW50IG1vZGVsIHRvIGFjaGlldmUgYW4gZW5kLXRv LWVuZCAKICAgQ29udHJvbGxlZCBMb2FkIHNlcnZpY2UgYnkgdXNpbmcgKHdpdGhpbiBhIGxhcmdl IHJlZ2lvbiBvZiB0aGUgCiAgIEludGVybmV0KSBEaWZmU2VydiBhbmQgZWRnZS10by1lZGdlIGRp c3RyaWJ1dGVkIG1lYXN1cmVtZW50LWJhc2VkIAogICBhZG1pc3Npb24gY29udHJvbCBhbmQgZmxv dyBwcmUtZW1wdGlvbi4gQ29udHJvbGxlZCBsb2FkIHNlcnZpY2UgaXMgYSAKICAgcXVhbGl0eSBv ZiBzZXJ2aWNlIChRb1MpIGNsb3NlbHkgYXBwcm94aW1hdGluZyB0aGUgUW9TIHRoYXQgdGhlIHNh bWUgCiAgIGZsb3cgd291bGQgcmVjZWl2ZSBmcm9tIGEgbGlnaHRseSBsb2FkZWQgbmV0d29yayBl bGVtZW50IFtSRkMyMjExXS4gCiAgIENvbnRyb2xsZWQgTG9hZCAoQ0wpIGlzIHVzZWZ1bCBmb3Ig aW5lbGFzdGljIGZsb3dzIHN1Y2ggYXMgdGhvc2UgZm9yIAogICByZWFsLXRpbWUgbWVkaWEuIAoK ICAgSW4gbGluZSB3aXRoIHRoZSAiSW50U2VydiBvdmVyIERpZmZTZXJ2IiBmcmFtZXdvcmsgZGVm aW5lZCBpbiAKICAgW1JGQzI5OThdLCB0aGUgQ0wgc2VydmljZSBpcyBzdXBwb3J0ZWQgZW5kLXRv LWVuZCBhbmQgUlNWUCBzaWduYWxsaW5nIAogICBbUkZDMjIwNV0gaXMgdXNlZCBlbmQtdG8tZW5k LCBvdmVyIGFuIGVkZ2UtdG8tZWRnZSBEaWZmU2VydiByZWdpb24uIAogICBXZSBjYWxsIHRoZSBE aWZmU2VydiByZWdpb24gdGhlICJDTC1yZWdpb24iLiAKCiBfX18gICAgX19fICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyAgICBfX19fICAgIF9fXyAKfCAgIHwgIHwg ICB8ICB8SW5ncmVzcyAgICAgICAgIEludGVyaW9yICAgICAgICAgRWdyZXNzfCAgfCAgICB8ICB8 ICAgfCAKfCAgIHwgIHwgICB8ICB8Z2F0ZXdheSAgICAgICAgIHJvdXRlcnMgICAgICAgICBnYXRl d2F5fCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8LS0tLS0tLSsgICstLS0tLS0tKyAg Ky0tLS0tLS0rICArLS0tLS0tfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8IFBDTi0g IHwgIHwgUENOLSAgfCAgfCBQQ04tICB8ICB8ICAgICAgfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwu LnwgICB8Li58bWFya2luZ3wuLnxtYXJraW5nfC4ufG1hcmtpbmd8Li58IE1ldGVyfC4ufCAgICB8 Li58ICAgfCAKfCAgIHwgIHwgICB8ICB8LS0tLS0tLSsgICstLS0tLS0tKyAgKy0tLS0tLS0rICAr LS0tLS0tfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8ICBcICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLyAgfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8ICAg XCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvICAgfCAgfCAgICB8ICB8ICAgfCAKfCAg IHwgIHwgICB8ICB8ICAgIFwgIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgIC8gICAgfCAgfCAg ICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8ICAgICBcICAoZm9yIGFkbWlzc2lvbiBjb250cm9s KSAgLyAgICAgfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8ICAgICAgLS08LS0tLS08 LS0tLTwtLS0tPC0tLS0tPC0tICAgICAgfCAgfCAgICB8ICB8ICAgfCAKfCAgIHwgIHwgICB8ICB8 ICAgICAgU3VzdGFpbmFibGUtQWdncmVnYXRlLVJhdGUgICAgICAgfCAgfCAgICB8ICB8ICAgfCAK fCAgIHwgIHwgICB8ICB8ICAgICAgICAoZm9yIGZsb3cgcHJlLWVtcHRpb24pICAgICAgICAgfCAg fCAgICB8ICB8ICAgfCAKfF9fX3wgIHxfX198ICB8X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19ffCAgfF9fX198ICB8X19ffCAKIApTeCAgICAgQWNjZXNzICAgICAgICAgICAg ICAgQ0wtcmVnaW9uICAgICAgICAgICAgICAgICAgIEFjY2VzcyAgICBSeCAKRW5kICAgIE5ldHdv cmsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXR3b3JrICAgRW5k IApIb3N0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBIb3N0IAogICAgICAgICAgICAgICAgPC0tLS0tLSBlZGdlLXRvLWVkZ2Ugc2ln bmFsbGluZyAtLS0tLT4gCiAgICAgICAgICAgICAgKGZvciBhZG1pc3Npb24gY29udHJvbCAmIGZs b3cgcHJlLWVtcHRpb24pIAogCjwtLS0tLS0tLS0tLS0tLS0tLS0tZW5kLXRvLWVuZCBRb1Mgc2ln bmFsbGluZyBwcm90b2NvbC0tLS0tLS0tLS0tLS0tLT4gCiAKRmlndXJlIDE6IE92ZXJhbGwgUW9T IGFyY2hpdGVjdHVyZSAoTkIgdGVybWlub2xvZ3kgZXhwbGFpbmVkIGxhdGVyKSAKIAogCkJyaXNj b2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICAg W1BhZ2UgNV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcg UENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgIAoKICAgRmlndXJlIDEgc2hvd3Mg YW4gZXhhbXBsZSBvZiBhbiBvdmVyYWxsIFFvUyBhcmNoaXRlY3R1cmUsIHdoZXJlIHRoZSAKICAg dHdvIGFjY2VzcyBuZXR3b3JrcyBhcmUgY29ubmVjdGVkIGJ5IGEgQ0wtcmVnaW9uLiBBbm90aGVy IHBvc3NpYmlsaXR5IAogICBpcyB0aGF0IHRoZXJlIGFyZSBzZXZlcmFsIENMLXJlZ2lvbnMgYmV0 d2VlbiB0aGUgYWNjZXNzIG5ldHdvcmtzIC0gCiAgIGVhY2ggd291bGQgb3BlcmF0ZSB0aGUgUHJl LUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIG1lY2hhbmlzbXMgCiAgIHNlcGFyYXRlbHkuIFRoZSBk b2N1bWVudCBhc3N1bWVzIFJTVlAgYXMgdGhlIGVuZC10by1lbmQgUW9TIAogICBzaWduYWxsaW5n IHByb3RvY29sLiBIb3dldmVyLCB0aGUgUlNWUCBzaWduYWxsaW5nIG1heSBpdHNlbGYgYmUgCiAg IG9yaWdpbmF0ZWQgb3IgdGVybWluYXRlZCBieSBwcm94aWVzIHN0aWxsIGNsb3NlciB0byB0aGUg ZWRnZSBvZiB0aGUgCiAgIG5ldHdvcmssIHN1Y2ggYXMgaG9tZSBodWJzIG9yIHRoZSBsaWtlLCB0 cmlnZ2VyZWQgaW4gdHVybiBieSAKICAgYXBwbGljYXRpb24gbGF5ZXIgc2lnbmFsbGluZy4gW1JG QzI5OThdIGFuZCBvdXIgYXBwcm9hY2ggYXJlIGNvbXBhcmVkIAogICBmdXJ0aGVyIGluIFNlY3Rp b24gNi4yLiAKCiAgIEZsb3dzIG11c3QgZW50ZXIgYW5kIGxlYXZlIHRoZSBDTC1yZWdpb24gdGhy b3VnaCBpdHMgaW5ncmVzcyBhbmQgCiAgIGVncmVzcyBnYXRld2F5cywgYW5kIHRoZXkgbmVlZCB0 cmFmZmljIGRlc2NyaXB0b3JzIHRoYXQgYXJlIHBvbGljZWQgCiAgIGJ5IHRoZSBpbmdyZXNzIGdh dGV3YXkgKE5CIHRoZSBwb2xpY2luZyBmdW5jdGlvbiBpcyBvdXQgb2YgdGhpcyAKICAgZG9jdW1l bnQncyBzY29wZSkuIFRoZSBvdmVyYWxsIENMLXRyYWZmaWMgYmV0d2VlbiB0d28gYm9yZGVyIHJv dXRlcnMgCiAgIGlzIGNhbGxlZCBhICJDTC1yZWdpb24tYWdncmVnYXRlIi4gCgogICBUaGUgZG9j dW1lbnQgaW50cm9kdWNlcyBhIG1lY2hhbmlzbSBmb3IgZmxvdyBhZG1pc3Npb24gY29udHJvbDog CiAgIHNob3VsZCBhIG5ldyBmbG93IGJlIGFkbWl0dGVkIGludG8gYSBzcGVjaWZpYyBDTC1yZWdp b24tYWdncmVnYXRlPyAKICAgQWRtaXNzaW9uIGNvbnRyb2wgcHJvdGVjdHMgdGhlIFFvUyBvZiBl eGlzdGluZyBDTC1mbG93cyBpbiBub3JtYWwgCiAgIGNpcmN1bXN0YW5jZXMuIEluIGFibm9ybWFs IGNpcmN1bXN0YW5jZXMsIGZvciBpbnN0YW5jZSBhIGRpc2FzdGVyIAogICBhZmZlY3RpbmcgbXVs dGlwbGUgaW50ZXJpb3Igcm91dGVycywgdGhlbiB0aGUgUW9TIG9uIGV4aXN0aW5nIENMIAogICBt aWNyb2Zsb3dzIG1heSBkZWdyYWRlIGV2ZW4gaWYgY2FyZSB3YXMgZXhlcmNpc2VkIHdoZW4gYWRt aXR0aW5nIAogICB0aG9zZSBtaWNyb2Zsb3dzIGJlZm9yZSB0aG9zZSBjaXJjdW1zdGFuY2VzLiBU aGVyZWZvcmUgd2UgYWxzbyAKICAgcHJvcG9zZSBhIG1lY2hhbmlzbSBmb3IgZmxvdyBwcmUtZW1w dGlvbjogaG93IG11Y2ggdHJhZmZpYywgaW4gYSAKICAgc3BlY2lmaWMgQ0wtcmVnaW9uLWFnZ3Jl Z2F0ZSwgc2hvdWxkIGJlIHByZS1lbXB0ZWQgaW4gb3JkZXIgdG8gCiAgIHByZXNlcnZlIHRoZSBR b1Mgb2YgdGhlIHJlbWFpbmluZyBDTC1mbG93cz8gRmxvdyBwcmUtZW1wdGlvbiBhbHNvIAogICBy ZXN0b3JlcyBRb1MgdG8gbG93ZXIgcHJpb3JpdHkgdHJhZmZpYy4gIAoKICAgQXMgYSBmdW5kYW1l bnRhbCBidWlsZGluZyBibG9jayB0byBlbmFibGUgdGhlc2UgdHdvIG1lY2hhbmlzbXMsIGVhY2gg CiAgIGxpbmsgb2YgdGhlIENMLXJlZ2lvbiBpcyBhc3NvY2lhdGVkIHdpdGggYSBjb25maWd1cmVk LWFkbWlzc2lvbi1yYXRlIAogICBhbmQgY29uZmlndXJlZC1wcmUtZW1wdGlvbi1yYXRlOyB0aGUg Zm9ybWVyIGlzIHVzdWFsbHkgc2lnbmlmaWNhbnRseSAKICAgbGFyZ2VyIHRoYW4gdGhlIGxhdHRl ci4gSWYgdHJhZmZpYyBpbiBhIHNwZWNpZmljIERpZmZTZXJ2IGNsYXNzICgiQ0wtCiAgIHRyYWZm aWMiKSBvbiB0aGUgbGluayBleGNlZWRzIHRoZXNlIHJhdGVzIHRoZW4gcGFja2V0cyBhcmUgbWFy a2VkIAogICB3aXRoICJBZG1pc3Npb24gTWFya2luZyIgb3IgIlByZS1lbXB0aW9uIE1hcmtpbmci LiBUaGUgYWxnb3JpdGhtcyAKICAgdGhhdCBkZXRlcm1pbmUgdGhlIG51bWJlciBvZiBwYWNrZXRz IG1hcmtlZCBhcmUgb3V0bGluZWQgaW4gU2VjdGlvbiAzIAogICBhbmQgZGV0YWlsZWQgaW4gW1BD Tl0uIFBDTiBtYXJraW5nIChQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24pIAogICBidWlsZHMg b24gdGhlIGNvbmNlcHRzIG9mIFJGQyAzMTY4LCAiVGhlIGFkZGl0aW9uIG9mIEV4cGxpY2l0IAog ICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiB0byBJUCIgKHdoaWNoIGlzIGJyaWVmbHkgc3VtbWFy aXNlZCBpbiAKICAgQXBwZW5kaXggQSkuIAoKCgoKCiAKIApCcmlzY29lICAgICAgICAgICAgICAg IEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDZdIAoMCkludGVy bmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3Rv YmVyIDIwMDYgCiAgICAKCiAgICAgICAgICAgICAgIAogICAgCiAgICAgICAgICAgICAgVHJhZmZp YyByYXRlIG9uIGxpbmsgXiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgRHJvcCBwYWNrZXRz IAogICAgICAgICAgICAgICAgICAgbGluayBiYW5kd2lkdGggLXwtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFByZS1lbXB0aW9uIE1hcmsgcGFj a2V0cyAKICAgICAgY29uZmlndXJlZC1wcmUtZW1wdGlvbi1yYXRlIC18LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBBZG1pc3Npb24gTWFyayBw YWNrZXRzIAogICAgICAgIGNvbmZpZ3VyZWQtYWRtaXNzaW9uLXJhdGUgLXwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgTm8gbWFya2luZyBvZiBwYWNrZXRz IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAKICAgIAogICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBQYWNrZXQgTWFya2luZyBieSBSb3V0ZXJzIAog ICAgCgogICBHYXRld2F5cyBvZiB0aGUgQ0wtcmVnaW9uIG1ha2UgbWVhc3VyZW1lbnRzIG9mIHBh Y2tldCByYXRlcyBhbmQgdGhlaXIgCiAgIFBDTiBtYXJraW5ncyBhbmQgY29udmVydCB0aGVtIGlu dG8gZGVjaXNpb25zIGFib3V0IHdoZXRoZXIgdG8gYWRtaXQgCiAgIG5ldyBmbG93cywgYW5kIChp ZiBuZWNlc3NhcnkpIGludG8gdGhlIHJhdGUgb2YgZXhjZXNzIHRyYWZmaWMgdGhhdCAKICAgc2hv dWxkIGJlIHByZS1lbXB0ZWQuIFRoZXNlIG1lY2hhbmlzbXMgYXJlIGRldGFpbGVkIGluIFNlY3Rp b24gMyBhbmQgCiAgIGJyaWVmbHkgb3V0bGluZWQgaW4gdGhlIG5leHQgZmV3IHBhcmFncmFwaHMu ICAKCiAgIFRoZSBhZG1pc3Npb24gY29udHJvbCBtZWNoYW5pc20gZm9yIGEgbmV3IGZsb3cgZW50 ZXJpbmcgdGhlIG5ldHdvcmsgCiAgIGF0IGluZ3Jlc3MgZ2F0ZXdheSBHMCBhbmQgbGVhdmluZyBp dCBhdCBlZ3Jlc3MgZ2F0ZXdheSBHMSByZWxpZXMgb24gCiAgIGZlZWRiYWNrIGZyb20gdGhlIGVn cmVzcyBnYXRld2F5IEcxIGFib3V0IHRoZSBleGlzdGluZyBDTC1yZWdpb24tCiAgIGFnZ3JlZ2F0 ZSBiZXR3ZWVuIEcwIGFuZCBHMS4gVGhpcyBmZWVkYmFjayBpcyBnZW5lcmF0ZWQgYXMgZm9sbG93 cy4gCiAgIEFsbCByb3V0ZXJzIG1ldGVyIHRoZSByYXRlIG9mIHRoZSBDTC10cmFmZmljIG9uIHRo ZWlyIG91dGdvaW5nIGxpbmtzIAogICBhbmQgbWFyayB0aGUgcGFja2V0cyB3aXRoIHRoZSBBZG1p c3Npb24gTWFyayBpZiB0aGUgY29uZmlndXJlZC0KICAgYWRtaXNzaW9uLXJhdGUgaXMgZXhjZWVk ZWQuIEVncmVzcyBnYXRld2F5IEcxIG1lYXN1cmVzIHRoZSBBZG1pc3Npb24gCiAgIE1hcmtzIGZv ciBlYWNoIG9mIGl0cyBDTC1yZWdpb24tYWdncmVnYXRlcyBzZXBhcmF0ZWx5LiBJZiB0aGUgCiAg IGZyYWN0aW9uIG9mIHRyYWZmaWMgb24gYSBDTC1yZWdpb24tYWdncmVnYXRlIHRoYXQgaXMgQWRt aXNzaW9uIE1hcmtlZCAKICAgZXhjZWVkcyBzb21lIHRocmVzaG9sZCwgbm8gZnVydGhlciBmbG93 cyBzaG91bGQgYmUgYWRtaXR0ZWQgaW50byB0aGlzIAogICBDTC1yZWdpb24tYWdncmVnYXRlLiBC ZWNhdXNlIHNvdXJjZXMgdmFyeSB0aGVpciBkYXRhIHJhdGVzIChhbW9uZ3N0IAogICBvdGhlciBy ZWFzb25zKSB0aGUgcmF0ZSBvZiB0aGUgQ0wtdHJhZmZpYyBvbiBhIGxpbmsgbWF5IGZsdWN0dWF0 ZSAKICAgYWJvdmUgYW5kIGJlbG93IHRoZSBjb25maWd1cmVkLWFkbWlzc2lvbi1yYXRlLiBIZW5j ZSB0byBnZXQgbW9yZSAKICAgc3RhYmxlIGluZm9ybWF0aW9uLCB0aGUgZWdyZXNzIGdhdGV3YXkg bWVhc3VyZXMgdGhlIGZyYWN0aW9uIGFzIGEgCiAgIG1vdmluZyBhdmVyYWdlLCBjYWxsZWQgdGhl IENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUuIFRoaXMgaXMgCiAgIHNpZ25hbGxlZCBmcm9tIHRo ZSBlZ3Jlc3MgRzEgdG8gdGhlIGluZ3Jlc3MgRzAsIHRvIGVuYWJsZSB0aGUgaW5ncmVzcyAKICAg dG8gYmxvY2sgbmV3IGZsb3dzLiAgCgogICBBZG1pc3Npb24gY29udHJvbCBzZWVtcyBtb3N0IHVz ZWZ1bCBmb3IgRGlmZlNlcnYncyBDb250cm9sbGVkIGxvYWQgCiAgIHNlcnZpY2UuIEluIG9yZGVy IHRvIHN1cHBvcnQgQ0wgdHJhZmZpYyB3ZSB3b3VsZCBleHBlY3QgUENOIHRvIAogICBzdXBwbGVt ZW50IHRoZSBleGlzdGluZyBzY2hlZHVsaW5nIGJlaGF2aW91ciBFeHBlZGl0ZWQgRm9yd2FyZGlu ZyAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAg ICAgICAgICAgICAgW1BhZ2UgN10gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQg TW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgKEVGKS4gU2lu Y2UgUENOIGdpdmVzIGFuICJlYXJseSB3YXJuaW5nIiBvZiBwb3RlbnRpYWwgY29uZ2VzdGlvbiAK ICAgKGhlbmNlICJwcmUtY29uZ2VzdGlvbiBub3RpZmljYXRpb24iKSwgYWRtaXNzaW9uIGNvbnRy b2wgY2FuIGtpY2sgaW4gCiAgIGJlZm9yZSB0aGVyZSBpcyBhbnkgc2lnbmlmaWNhbnQgYnVpbGQg dXAgb2YgcGFja2V0cyBpbiByb3V0ZXJzIC0gCiAgIHdoaWNoIGlzIGV4YWN0bHkgdGhlIHBlcmZv cm1hbmNlIHJlcXVpcmVkIGZvciBDTC4gSG93ZXZlciwgUENOIGlzIG5vdCAKICAgb25seSBpbnRl bmRlZCB0byBzdXBwbGVtZW50IEVGLiBQQ04gaXMgc3BlY2lmaWVkIChpbiBbUENOXSkgYXMgYSAK ICAgYnVpbGRpbmcgYmxvY2sgd2hpY2ggY2FuIHN1cHBsZW1lbnQgdGhlIHNjaGVkdWxpbmcgYmVo YXZpb3VyIG9mIG90aGVyIAogICBQSEJzLiAKCiAgIFRoZSBmdW5jdGlvbiB0byBwcmUtZW1wdCBm bG93cyAob3IgYWxsb3cgdGhlIHBvdGVudGlhbCB0byBwcmUtZW1wdCAKICAgdGhlbSkgcmVsaWVz IG9uIGZlZWRiYWNrIGZyb20gdGhlIGVncmVzcyBnYXRld2F5IGFib3V0IHRoZSBDTC1yZWdpb24t CiAgIGFnZ3JlZ2F0ZXMuIFRoaXMgZmVlZGJhY2sgaXMgZ2VuZXJhdGVkIGFzIGZvbGxvd3MuIEFs bCByb3V0ZXJzIG1ldGVyIAogICB0aGUgcmF0ZSBvZiB0aGUgQ0wtdHJhZmZpYyBvbiB0aGVpciBv dXRnb2luZyBsaW5rcywgYW5kIGlmIHRoZSByYXRlIAogICBpcyBpbiBleGNlc3Mgb2YgdGhlIGNv bmZpZ3VyZWQtcHJlLWVtcHRpb24tcmF0ZSB0aGVuIHBhY2tldHMgCiAgIGFtb3VudGluZyB0byB0 aGUgZXhjZXNzIHJhdGUgYXJlIFByZS1lbXB0aW9uIE1hcmtlZC4gSWYgdGhlIGVncmVzcyAKICAg Z2F0ZXdheSBHMSBzZWVzIGEgUHJlLWVtcHRpb24gTWFya2VkIHBhY2tldCB0aGVuIGl0IG1lYXN1 cmVzLCBmb3IgCiAgIHRoaXMgQ0wtcmVnaW9uLWFnZ3JlZ2F0ZSwgdGhlIHJhdGUgb2YgYWxsIHJl Y2VpdmVkIHBhY2tldHMgdGhhdCAKICAgYXJlbid0IFByZS1lbXB0aW9uIE1hcmtlZC4gVGhpcyBp cyB0aGUgcmF0ZSBvZiBDTC10cmFmZmljIHRoYXQgdGhlIAogICBuZXR3b3JrIGNhbiBhY3R1YWxs eSBzdXBwb3J0IGZyb20gRzAgdG8gRzEsIGFuZCB3ZSB0aHVzIGNhbGwgaXQgdGhlIAogICBTdXN0 YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZS4gVGhlIGluZ3Jlc3MgZ2F0ZXdheSBHMCBjb21wYXJlcyB0 aGUgCiAgIFN1c3RhaW5hYmxlLUFnZ3JlZ2F0ZS1SYXRlIHdpdGggdGhlIHJhdGUgdGhhdCBpdCBp cyBzZW5kaW5nIHRvd2FyZHMgCiAgIEcxLCBhbmQgaGVuY2UgZGV0ZXJtaW5lcyB0aGUgcmVxdWly ZWQgdHJhZmZpYyByYXRlIHJlZHVjdGlvbi4gVGhlIAogICBkb2N1bWVudCBhc3N1bWVzIGZsb3cg cHJlLWVtcHRpb24gYXMgdGhlIHdheSBvZiByZWFjdGluZyB0byB0aGlzIAogICBpbmZvcm1hdGlv biwgaWUgc3RvcHBpbmcgc3VmZmljaWVudCBmbG93cyB0byByZWR1Y2UgdGhlIHJhdGUgdG8gdGhl IAogICBTdXN0YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZS4gSG93ZXZlciwgdGhpcyBpc24ndCBtYW5k YXRlZCwgZm9yIAogICBpbnN0YW5jZSBwb2xpY3kgb3IgcmVndWxhdGlvbiBtYXkgcHJldmVudCBw cmUtZW1wdGlvbiBvZiBzb21lIGZsb3dzIC0gCiAgIHN1Y2ggY29uc2lkZXJhdGlvbnMgYXJlIG91 dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAKCjEuMi4gS2V5IGJlbmVmaXRzIAoKICAgV2Ug YmVsaWV2ZSB0aGF0IHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBzaW1wbGUsIAogICBzY2FsYWJsZSwgYW5kIHJvYnVzdCBiZWNhdXNlOiAKCiAgIG8gUGVyIGZs b3cgc3RhdGUgaXMgb25seSByZXF1aXJlZCBhdCB0aGUgaW5ncmVzcyBnYXRld2F5cyB0byBwcmV2 ZW50IAogICAgICBub24tYWRtaXR0ZWQgQ0wgdHJhZmZpYyBmcm9tIGVudGVyaW5nIHRoZSBQQ04t cmVnaW9uLiBPdGhlciAKICAgICAgbmV0d29yayBlbnRpdGllcyBhcmUgbm90IGF3YXJlIG9mIGlu ZGl2aWR1YWwgZmxvd3MuIAoKICAgbyBGb3IgZWFjaCBvZiBpdHMgbGlua3MgYSByb3V0ZXIgaGFz IEFkbWlzc2lvbiBNYXJraW5nIGFuZCBQcmUtCiAgICAgIGVtcHRpb24gTWFya2luZyBiZWhhdmlv dXJzLiBUaGVzZSBtYXJrZXJzIG9wZXJhdGUgb24gdGhlIG92ZXJhbGwgCiAgICAgIENMIHRyYWZm aWMgb2YgdGhlIHJlc3BlY3RpdmUgbGluay4gVGhlcmVmb3JlLCB0aGVyZSBhcmUgbm8gCiAgICAg IHNjYWxhYmlsaXR5IGNvbmNlcm5zLiAKCiAgIG8gVGhlIGluZm9ybWF0aW9uIG9mIHRoZXNlIG1l YXN1cmVtZW50cyBpcyBpbXBsaWNpdGx5IHNpZ25hbGxlZCB0byAKICAgICAgdGhlIGVncmVzcyBn YXRld2F5cyBieSB0aGUgbWFya3MgaW4gdGhlIHBhY2tldCBoZWFkZXJzLiBObyAKICAgICAgcHJv dG9jb2wgYWN0aW9ucyAoZXhwbGljaXQgbWVzc2FnZXMpIGFyZSByZXF1aXJlZC4gCgoKCiAKIApC cmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAg ICAgIFtQYWdlIDhdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVz aW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIG8gVGhlIGVncmVzcyBnYXRl d2F5cyBtYWtlIHNlcGFyYXRlIG1lYXN1cmVtZW50cyBmb3IgZWFjaCBpbmdyZXNzIAogICAgICBn YXRld2F5IG9mIHBhY2tldHMuIEVhY2ggbWV0ZXIgb3BlcmF0ZXMgb24gdGhlIG92ZXJhbGwgQ0wg dHJhZmZpYyAKICAgICAgb2YgYSBwYXJ0aWN1bGFyIENMLXJlZ2lvbi1hZ2dyZWdhdGUuIFRoZXJl Zm9yZSwgdGhlcmUgYXJlIG5vIAogICAgICBzY2FsYWJpbGl0eSBjb25jZXJucyBhcyBsb25nIGFz IHRoZSBudW1iZXIgb2YgaW5ncmVzcyBnYXRld2F5cyBpcyAKICAgICAgbm90IG92ZXJ3aGVsbWlu Z2x5IGxhcmdlLiAKCiAgIG8gRmVlZGJhY2sgc2lnbmFsbGluZyBpcyByZXF1aXJlZCBiZXR3ZWVu IGFsbCBwYWlycyBvZiBpbmdyZXNzIGFuZCAKICAgICAgZWdyZXNzIGdhdGV3YXlzIGFuZCB0aGUg c2lnbmFsbGVkIGluZm9ybWF0aW9uIGlzIG9uIHRoZSBiYXNpcyBvZiAKICAgICAgdGhlIGNvcnJl c3BvbmRpbmcgQ0wtcmVnaW9uLWFnZ3JlZ2F0ZSwgaS5lLiBpdCBpcyBhbHNvIHVuYXdhcmUgb2Yg CiAgICAgIGluZGl2aWR1YWwgZmxvd3MuIAoKICAgbyBUaGUgY29uZmlndXJlZC1hZG1pc3Npb24t cmF0ZXMgY2FuIGJlIGNob3NlbiBzbWFsbCBlbm91Z2ggdGhhdCAKICAgICAgYWRtaXR0ZWQgdHJh ZmZpYyBjYW4gc3RpbGwgYmUgY2FycmllZCBhZnRlciBhIHJlcm91dGluZyBpbiBtb3N0IAogICAg ICBmYWlsdXJlIGNhc2VzLiBUaGlzIGlzIGFuIGltcG9ydGFudCBmZWF0dXJlIGFzIFFvUyB2aW9s YXRpb25zIGluIAogICAgICBjb3JlIG5ldHdvcmtzIGR1ZSB0byBsaW5rIGZhaWx1cmVzIGFyZSBt b3JlIGxpa2VseSB0aGFuIFFvUyAKICAgICAgdmlvbGF0aW9ucyBkdWUgdG8gaW5jcmVhc2VkIHRy YWZmaWMgdm9sdW1lLiAKCiAgIG8gVGhlIGFkbWl0dGVkIGxvYWQgaXMgY29udHJvbGxlZCBkeW5h bWljYWxseS4gVGhlcmVmb3JlIGl0IGFkYXB0cyAKICAgICAgYXMgdGhlIHRyYWZmaWMgbWF0cml4 IGNoYW5nZXMsIGFuZCBhbHNvIGlmIHRoZSBuZXR3b3JrIHRvcG9sb2d5IAogICAgICBjaGFuZ2Vz IChlZyBhZnRlciBhIGxpbmsgZmFpbHVyZSkuIEhlbmNlIGFuIG9wZXJhdG9yIGNhbiBiZSBsZXNz IAogICAgICBjb25zZXJ2YXRpdmUgd2hlbiBkZXBsb3lpbmcgbmV0d29yayBjYXBhY2l0eSwgYW5k IGxlc3MgYWNjdXJhdGUgaW4gCiAgICAgIHRoZWlyIHByZWRpY3Rpb24gb2YgdGhlIHRyYWZmaWMg bWF0cml4LiBBbHNvLCBjb250cm9sbGluZyB0aGUgbG9hZCAKICAgICAgdXNpbmcgc3RhdGljYWxs eSBwcm92aXNpb25lZCBjYXBhY2l0eSBwZXIgaW5ncmVzcyAocmVnYXJkbGVzcyBvZiAKICAgICAg dGhlIGVncmVzcyBvZiBhIGZsb3cpLCBhcyBpcyB0eXBpY2FsIGluIHRoZSBEaWZmU2VydiBhcmNo aXRlY3R1cmUgCiAgICAgIFtSRkMyNDc1XSwgY2FuIGxlYWQgdG8gZm9jdXNzZWQgb3ZlcmxvYWQ6 IG1hbnkgZmxvd3MgaGFwcGVuIHRvIAogICAgICBmb2N1cyBvbiBhIHBhcnRpY3VsYXIgbGluayBh bmQgdGhlbiBhbGwgZmxvd3MgdGhyb3VnaCB0aGUgCiAgICAgIGNvbmdlc3RlZCBsaW5rIGZhaWwg Y2F0YXN0cm9waGljYWxseSAoU2VjdGlvbiA2LjIpLiAKCiAgIG8gVGhlIHByZS1lbXB0aW9uIGZ1 bmN0aW9uIGNvbXBsZW1lbnRzIGFkbWlzc2lvbiBjb250cm9sLiBJdCBhbGxvd3MgCiAgICAgIHRo ZSBuZXR3b3JrIHRvIHJlY292ZXIgZnJvbSBzdWRkZW4gdW5leHBlY3RlZCBzdXJnZXMgb2YgQ0wt dHJhZmZpYyAKICAgICAgb24gc29tZSBsaW5rcywgdGh1cyByZXN0b3JpbmcgUW9TIHRvIHRoZSBy ZW1haW5pbmcgZmxvd3MuIFN1Y2ggCiAgICAgIHNjZW5hcmlvcyBhcmUgdmVyeSB1bmxpa2VseSBi dXQgbm90IGltcG9zc2libGUuIFRoZXkgY2FuIGJlIGNhdXNlZCAKICAgICAgYnkgbGFyZ2UgbmV0 d29yayBmYWlsdXJlcyB0aGF0IHJlZGlyZWN0IGxvdHMgb2YgYWRtaXR0ZWQgQ0wtCiAgICAgIHRy YWZmaWMgdG8gb3RoZXIgbGlua3MsIG9yIGJ5IG1hbGZ1bmN0aW9uIG9mIHRoZSBtZWFzdXJlbWVu dC1iYXNlZCAKICAgICAgYWRtaXNzaW9uIGNvbnRyb2wgaW4gdGhlIHByZXNlbmNlIG9mIGFkbWl0 dGVkIGZsb3dzIHRoYXQgc2VuZCBmb3IgCiAgICAgIGEgd2hpbGUgd2l0aCBhbiBhdHlwaWNhbGx5 IGxvdyByYXRlIGFuZCBpbmNyZWFzZSB0aGVpciByYXRlcyBpbiBhIAogICAgICBjb3JyZWxhdGVk IHdheS4gCgogICAgCgogICAgCgoxLjMuIFRlcm1pbm9sb2d5IAoKICAgRURJVE9SJ1MgTk9URTog VGVybWlub2xvZ3kgaW4gdGhpcyBkb2N1bWVudCBpcyAoaG9wZWZ1bGx5KSBjb25zaXN0ZW50IAog ICB3aXRoIHRoYXQgaW4gW1BDTl0uIEhvd2V2ZXIsIGl0IG1heSBub3QgYmUgY29uc2lzdGVudCB3 aXRoIHRoZSAKCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIw MDcgICAgICAgICAgICAgICAgIFtQYWdlIDldIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBs b3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIHRl cm1pbm9sb2d5IGluIG90aGVyIFBDTi1yZWxhdGVkIGRvY3VtZW50cy4gVGhlIFBDTiBXb3JraW5n IEdyb3VwIChpZiAKICAgZm9ybWVkKSB3aWxsIG5lZWQgdG8gYWdyZWUgYSBzaW5nbGUgc2V0IG9m IHRlcm1pbm9sb2d5LiAgCgogICBUaGlzIHRlcm1pbm9sb2d5IGlzIGNvcGllZCBmcm9tIHRoZSBw cmUtY29uZ2VzdGlvbiBub3RpZmljYXRpb24gCiAgIG1hcmtpbmcgZHJhZnQgW1BDTl06IAoKICAg byBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKFBDTik6IHR3byBuZXcgYWxnb3JpdGhtcyB0 aGF0IAogICAgICBkZXRlcm1pbmUgd2hlbiBhIFBDTi1lbmFibGVkIHJvdXRlciBBZG1pc3Npb24g TWFya3MgYW5kIFByZS0KICAgICAgZW1wdGlvbiBNYXJrcyBhIHBhY2tldCwgZGVwZW5kaW5nIG9u IHRoZSB0cmFmZmljIGxldmVsLiAgCgogICBvIEFkbWlzc2lvbiBNYXJraW5nIGNvbmRpdGlvbjog dGhlIHRyYWZmaWMgbGV2ZWwgaXMgc3VjaCB0aGF0IHRoZSAKICAgICAgcm91dGVyIEFkbWlzc2lv biBNYXJrcyBwYWNrZXRzLiBUaGUgcm91dGVyIHByb3ZpZGVzIGFuICJlYXJseSAKICAgICAgd2Fy bmluZyIgdGhhdCB0aGUgbG9hZCBpcyBuZWFyaW5nIHRoZSBlbmdpbmVlcmVkIGFkbWlzc2lvbiBj b250cm9sIAogICAgICBjYXBhY2l0eSwgYmVmb3JlIHRoZXJlIGlzIGFueSBzaWduaWZpY2FudCBi dWlsZC11cCBvZiBDTCBwYWNrZXRzIAogICAgICBpbiB0aGUgcXVldWUuIAoKICAgbyBQcmUtZW1w dGlvbiBNYXJraW5nIGNvbmRpdGlvbjogdGhlIHRyYWZmaWMgbGV2ZWwgaXMgc3VjaCB0aGF0IHRo ZSAKICAgICAgcm91dGVyIFByZS1lbXB0aW9uIE1hcmtzIHBhY2tldHMuIFRoZSByb3V0ZXIgd2Fy bnMgZXhwbGljaXRseSB0aGF0IAogICAgICBwcmUtZW1wdGlvbiBtYXkgYmUgbmVlZGVkLiAKCiAg IG8gQ29uZmlndXJlZC1hZG1pc3Npb24tcmF0ZTogdGhlIHJlZmVyZW5jZSByYXRlIHVzZWQgYnkg dGhlIAogICAgICBhZG1pc3Npb24gbWFya2luZyBhbGdvcml0aG0gaW4gYSBQQ04tZW5hYmxlZCBy b3V0ZXIuICAgCgogICBvIENvbmZpZ3VyZWQtcHJlLWVtcHRpb24tcmF0ZSAtIHRoZSByZWZlcmVu Y2UgcmF0ZSB1c2VkIGJ5IHRoZSBwcmUtCiAgICAgIGVtcHRpb24gbWFya2luZyBhbGdvcml0aG0g aW4gYSBQQ04tZW5hYmxlZCByb3V0ZXIuIAoKICAgIAoKICAgVGhlIGZvbGxvd2luZyB0ZXJtcyBh cmUgZGVmaW5lZCBoZXJlOiAKCiAgIG8gSW5ncmVzcyBnYXRld2F5OiByb3V0ZXIgYXQgYW4gaW5n cmVzcyB0byB0aGUgQ0wtcmVnaW9uLiBBIENMLQogICAgICByZWdpb24gbWF5IGhhdmUgc2V2ZXJh bCBpbmdyZXNzIGdhdGV3YXlzLiAgCgogICBvIEVncmVzcyBnYXRld2F5OiByb3V0ZXIgYXQgYW4g ZWdyZXNzIGZyb20gdGhlIENMLXJlZ2lvbi4gQSBDTC0KICAgICAgcmVnaW9uIG1heSBoYXZlIHNl dmVyYWwgZWdyZXNzIGdhdGV3YXlzLiAKCiAgIG8gSW50ZXJpb3Igcm91dGVyOiBhIHJvdXRlciB3 aGljaCBpcyBwYXJ0IG9mIHRoZSBDTC1yZWdpb24sIGJ1dCAKICAgICAgaXNuJ3QgYW4gaW5ncmVz cyBvciBlZ3Jlc3MgZ2F0ZXdheS4gCgogICBvIENMLXJlZ2lvbjogQSByZWdpb24gb2YgdGhlIElu dGVybmV0IGluIHdoaWNoIGFsbCB0cmFmZmljIAogICAgICBlbnRlcnMvbGVhdmVzIHRocm91Z2gg YW4gaW5ncmVzcy9lZ3Jlc3MgZ2F0ZXdheSBhbmQgYWxsIHJvdXRlcnMgCiAgICAgIHJ1biBQcmUt Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gbWFya2luZy4gQSBDTC1yZWdpb24gaXMgYSBEaWZmU2Vy diAKICAgICAgcmVnaW9uIChhIERpZmZTZXJ2IHJlZ2lvbiBpcyBlaXRoZXIgYSBzaW5nbGUgRGlm ZlNlcnYgZG9tYWluIG9yIAogICAgICBzZXQgb2YgY29udGlndW91cyBEaWZmU2VydiBkb21haW5z KSwgYnV0IG5vdGUgdGhhdCB0aGUgQ0wtcmVnaW9uIAogICAgICBkb2VzIG5vdCB1c2UgdGhlIHRy YWZmaWMgY29uZGl0aW9uaW5nIGFncmVlbWVudHMgKFRDQXMpIG9mIHRoZSAKICAgICAgKGluZm9y bWF0aW9uYWwpIERpZmZTZXJ2IGFyY2hpdGVjdHVyZS4gCgogCiAKQnJpc2NvZSAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDEwXSAKDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAg T2N0b2JlciAyMDA2IAogICAgCgogICBvIENMLXJlZ2lvbi1hZ2dyZWdhdGU6IGFsbCB0aGUgbWlj cm9mbG93cyBiZXR3ZWVuIGEgc3BlY2lmaWMgcGFpciBvZiAKICAgICAgaW5ncmVzcyBhbmQgZWdy ZXNzIGdhdGV3YXlzLiBOb3RlIHRoZXJlIGlzIG5vIGZpZWxkIGluIHRoZSBmbG93IAogICAgICBw YWNrZXQgaGVhZGVycyB0aGF0IHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIGFnZ3JlZ2F0ZS4gCgog ICBvIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGU6IHRoZSBudW1iZXIgb2YgYml0cyBpbiBDTCBw YWNrZXRzIHRoYXQgCiAgICAgIGFyZSBhZG1pc3Npb24gbWFya2VkIChvciBwcmUtZW1wdGlvbiBt YXJrZWQpLCBkaXZpZGVkIGJ5IHRoZSAKICAgICAgbnVtYmVyIG9mIGJpdHMgaW4gYWxsIENMIHBh Y2tldHMuIEl0IGlzIGNhbGN1bGF0ZWQgYXMgYW4gCiAgICAgIGV4cG9uZW50aWFsbHkgd2VpZ2h0 ZWQgbW92aW5nIGF2ZXJhZ2UuIEl0IGlzIGNhbGN1bGF0ZWQgYnkgYW4gCiAgICAgIGVncmVzcyBn YXRld2F5IGZvciB0aGUgQ0wgcGFja2V0cyBmcm9tIGEgcGFydGljdWxhciBpbmdyZXNzIAogICAg ICBnYXRld2F5LCBpLmUuIHRoZXJlIGlzIGEgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZSBmb3Ig ZWFjaCBDTC0KICAgICAgcmVnaW9uLWFnZ3JlZ2F0ZS4gIAoKICAgbyBTdXN0YWluYWJsZS1BZ2dy ZWdhdGUtUmF0ZTogdGhlIHJhdGUgb2YgdHJhZmZpYyB0aGF0IHRoZSBuZXR3b3JrIAogICAgICBj YW4gYWN0dWFsbHkgc3VwcG9ydCBmb3IgYSBzcGVjaWZpYyBDTC1yZWdpb24tYWdncmVnYXRlLiBT byBpdCBpcyAKICAgICAgbWVhc3VyZWQgYnkgYW4gZWdyZXNzIGdhdGV3YXkgZm9yIHRoZSBDTCBw YWNrZXRzIGZyb20gYSBwYXJ0aWN1bGFyIAogICAgICBpbmdyZXNzIGdhdGV3YXkuIAoKICAgbyBJ bmdyZXNzLUFnZ3JlZ2F0ZS1SYXRlOiB0aGUgcmF0ZSBvZiB0cmFmZmljIHRoYXQgaXMgYmVpbmcg c2VudCBvbiAKICAgICAgYSBzcGVjaWZpYyBDTC1yZWdpb24tYWdncmVnYXRlLiBTbyBpdCBpcyBt ZWFzdXJlZCBieSBhbiBpbmdyZXNzIAogICAgICBnYXRld2F5IGZvciB0aGUgQ0wgcGFja2V0cyBz ZW50IHRvd2FyZHMgYSBwYXJ0aWN1bGFyIGVncmVzcyAKICAgICAgZ2F0ZXdheS4gCgogCiAKMS40 LiBFeGlzdGluZyB0ZXJtaW5vbG9neSAKCiAgIFRoaXMgaXMgYSBwbGFjZWhvbGRlciBmb3IgdXNl ZnVsIHRlcm1pbm9sb2d5IHRoYXQgaXMgZGVmaW5lZCAKICAgZWxzZXdoZXJlLiAKCjEuNS4gU3Rh bmRhcmRpc2F0aW9uIHJlcXVpcmVtZW50cyAKCiAgIFRoZSBmcmFtZXdvcmsgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQgaGFzIHR3byBuZXcgc3RhbmRhcmRpc2F0aW9uIAogICByZXF1aXJlbWVu dHM6ICAKCiAgIG8gbmV3IFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiBmb3IgQWRtaXNzaW9u IE1hcmtpbmcgYW5kIFByZS0KICAgICAgZW1wdGlvbiBNYXJraW5nIGFyZSByZXF1aXJlZCwgYXMg ZGV0YWlsZWQgaW4gW1BDTl0uICAKCiAgIG8gdGhlIGVuZC10by1lbmQgc2lnbmFsbGluZyBwcm90 b2NvbCBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBjYXJyeSAKICAgICAgdGhlIENvbmdlc3Rpb24t TGV2ZWwtRXN0aW1hdGUgcmVwb3J0IChmb3IgYWRtaXNzaW9uIGNvbnRyb2wpIGFuZCAKICAgICAg dGhlIFN1c3RhaW5hYmxlLUFnZ3JlZ2F0ZS1SYXRlIChmb3IgZmxvdyBwcmUtZW1wdGlvbikuIFdp dGggb3VyIAogICAgICBhc3N1bXB0aW9uIG9mIFJTVlAgKFNlY3Rpb24gMi4yKSBhcyB0aGUgZW5k LXRvLWVuZCBzaWduYWxsaW5nIAogICAgICBwcm90b2NvbCwgaXQgbWVhbnMgdGhhdCBleHRlbnNp b25zIHRvIFJTVlAgYXJlIHJlcXVpcmVkLCBhcyAKICAgICAgZGV0YWlsZWQgaW4gW1JTVlAtUENO XSwgZm9yIGV4YW1wbGUgdG8gY2FycnkgdGhlIENvbmdlc3Rpb24tTGV2ZWwtCiAgICAgIEVzdGlt YXRlIGFuZCBTdXN0YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZSBpbmZvcm1hdGlvbiBmcm9tIGVncmVz cyAKICAgICAgZ2F0ZXdheSB0byBpbmdyZXNzIGdhdGV3YXkuIAoKIAogCkJyaXNjb2UgICAgICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxMV0g CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAg ICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgbyBXZSBhcmUgZGlzY3Vzc2luZyB3aGF0IHRvIHN0 YW5kYXJkaXNlIGFib3V0IHRoZSBnYXRld2F5J3MgCiAgICAgIGJlaGF2aW91ci4gCgogICBPdGhl ciB0aGFuIHRoZXNlIHRoaW5ncywgdGhlIGFycmFuZ2VtZW50IHVzZXMgZXhpc3RpbmcgSUVURiBw cm90b2NvbHMgCiAgIHRocm91Z2hvdXQsIGFsdGhvdWdoIG5vdCBpbiB0aGVpciB1c3VhbCBhcmNo aXRlY3R1cmUuIAoKMS42LiBTdHJ1Y3R1cmUgb2YgcmVzdCBvZiB0aGUgZG9jdW1lbnQgCgogICBT ZWN0aW9uIDIgZGVzY3JpYmVzIHNvbWUga2V5IGFzcGVjdHMgb2YgdGhlIGRlcGxveW1lbnQgbW9k ZWw6IG91ciAKICAgZ29hbHMgYW5kIGFzc3VtcHRpb25zLiBTZWN0aW9uIDMgZGVzY3JpYmVzIHRo ZSBkZXBsb3ltZW50IG1vZGVsLCAKICAgd2hpbHN0IFNlY3Rpb24gNCBzdW1tYXJpc2VzIHRoZSBy ZXF1aXJlZCBjaGFuZ2VzIHRvIHRoZSB2YXJpb3VzIAogICByb3V0ZXJzIGluIHRoZSBDTC1yZWdp b24uIFNlY3Rpb24gNSBvdXRsaW5lcyBzb21lIGxpbWl0YXRpb25zIG9mIFBDTiAKICAgdGhhdCB3 ZSd2ZSBpZGVudGlmaWVkIGluIHRoaXMgZGVwbG95bWVudCBtb2RlbDsgaXQgYWxzbyBkaXNjdXNz ZXMgCiAgIHNvbWUgcG90ZW50aWFsIHNvbHV0aW9ucywgYW5kIG90aGVyIHBvc3NpYmxlIGV4dGVu c2lvbnMuIFNlY3Rpb24gNiAKICAgcHJvdmlkZXMgc29tZSBjb21wYXJpc29uIHdpdGggZXhpc3Rp bmcgUW9TIG1lY2hhbmlzbXMuICAKCiAgICAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgog CiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDEyXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2Rl bCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgoyLiBLZXkgYXNwZWN0cyBv ZiB0aGUgZGVwbG95bWVudCBtb2RlbCAKCiAgIEVESVRPUidTIE5PVEU6IFRoZSBtYXRlcmlhbCBp biBTZWN0aW9uIDIgd2lsbCBldmVudHVhbGx5IGRpc2FwcGVhciwgCiAgIGFzIGl0IHdpbGwgYmUg Y292ZXJlZCBieSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgb2YgdGhlIFBDTiBXb3JraW5nIAogICBH cm91cCAoaWYgZm9ybWVkKS4gCgogICBJbiB0aGlzIHNlY3Rpb24gd2UgZGlzY3VzcyB0aGUga2V5 IGFzcGVjdHMgb2YgdGhlIGRlcGxveW1lbnQgbW9kZWw6IAoKICAgbyBBdCBhIGhpZ2ggbGV2ZWws IG91ciBrZXkgZ29hbHMsIGkuZS4gdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCB3ZSAKICAgICAgd2Fu dCB0byBhY2hpZXZlIAoKICAgbyBUaGUgYXNzdW1wdGlvbnMgdGhhdCB3ZSdyZSBwcmVwYXJlZCB0 byBtYWtlICAKCjIuMS4gS2V5IGdvYWxzIAoKICAgVGhlIGRlcGxveW1lbnQgbW9kZWwgYWNoaWV2 ZXMgYW4gZW5kLXRvLWVuZCBjb250cm9sbGVkIGxvYWQgKENMKSAKICAgc2VydmljZSB3aGVyZSBh IHNlZ21lbnQgb2YgdGhlIGVuZC10by1lbmQgcGF0aCBpcyBhbiBlZGdlLXRvLWVkZ2UgCiAgIFBy ZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiByZWdpb24uIENMIGlzIGEgcXVhbGl0eSBvZiBzZXJ2 aWNlIChRb1MpIAogICBjbG9zZWx5IGFwcHJveGltYXRpbmcgdGhlIFFvUyB0aGF0IHRoZSBzYW1l IGZsb3cgd291bGQgcmVjZWl2ZSBmcm9tIGEgCiAgIGxpZ2h0bHkgbG9hZGVkIG5ldHdvcmsgZWxl bWVudCBbUkZDMjIxMV0uIEl0IGlzIHVzZWZ1bCBmb3IgaW5lbGFzdGljIAogICBmbG93cyBzdWNo IGFzIHRob3NlIGZvciByZWFsLXRpbWUgbWVkaWEuICAKCiAgIG8gVGhlIENMIHNlcnZpY2Ugc2hv dWxkIGJlIGFjaGlldmVkIGRlc3BpdGUgdmFyeWluZyBsb2FkIGxldmVscyBvZiAKICAgICAgb3Ro ZXIgc29ydHMgb2YgdHJhZmZpYywgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgcmF0ZSBhZGFwdGl2 ZSAKICAgICAgKGkuZS4gcmVzcG9uc2l2ZSB0byBwYWNrZXQgZHJvcHMgb3IgRUNOIG1hcmtzKS4g CgogICBvIFRoZSBDTCBzZXJ2aWNlIHNob3VsZCBiZSBzdXBwb3J0ZWQgZm9yIGEgdmFyaWV0eSBv ZiBwb3NzaWJsZSBDTCAKICAgICAgc291cmNlczogQ29uc3RhbnQgQml0IFJhdGUgKENCUiksIFZh cmlhYmxlIEJpdCBSYXRlIChWQlIpIGFuZCAKICAgICAgdm9pY2Ugd2l0aCBzaWxlbmNlIHN1cHBy ZXNzaW9uLiBWQlIgaXMgdGhlIG1vc3QgY2hhbGxlbmdpbmcgdG8gCiAgICAgIHN1cHBvcnQuIAoK ICAgbyBBZnRlciBhIGxvY2FsaXNlZCBmYWlsdXJlIGluIHRoZSBpbnRlcmlvciBvZiB0aGUgQ0wt cmVnaW9uIGNhdXNpbmcgCiAgICAgIGhlYXZ5IGNvbmdlc3Rpb24sIHRoZSBDTCBzZXJ2aWNlIHNo b3VsZCByZWNvdmVyIGdyYWNlZnVsbHkgYnkgcHJlLQogICAgICBlbXB0aW5nIChkcm9wcGluZykg c29tZSBvZiB0aGUgYWRtaXR0ZWQgQ0wgbWljcm9mbG93cywgd2hpbHN0IAogICAgICBwcmVzZXJ2 aW5nIGFzIG1hbnkgb2YgdGhlbSBhcyBwb3NzaWJsZSB3aXRoIHRoZWlyIGZ1bGwgQ0wgUW9TLiAg CgoKCgoKCgoKCgoKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxM10gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERl cGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAg byBJdCBuZWVkcyB0byBiZSBwb3NzaWJsZSB0byBjb21wbGV0ZSBmbG93IHByZS1lbXB0aW9uIHdp dGhpbiAxLTIgCiAgICAgIHNlY29uZHMuIE9wZXJhdG9ycyB3aWxsIGhhdmUgdmFyeWluZyByZXF1 aXJlbWVudHMgYnV0LCBhdCBsZWFzdCAKICAgICAgZm9yIHZvaWNlLCBpdCBoYXMgYmVlbiBlc3Rp bWF0ZWQgdGhhdCBhZnRlciBhIGZldyBzZWNvbmRzIHRoZW4gCiAgICAgIG1hbnkgYWZmZWN0ZWQg dXNlcnMgd2lsbCBzdGFydCB0byBoYW5nIHVwLCBtYWtpbmcgdGhlIGZsb3cgcHJlLQogICAgICBl bXB0aW9uIG1lY2hhbmlzbSByZWR1bmRhbnQgYW5kIHBvc3NpYmx5IGV2ZW4gY291bnRlci1wcm9k dWN0aXZlLiAKICAgICAgVW50aWwgZmxvdyBwcmUtZW1wdGlvbiBraWNrcyBpbiwgb3RoZXIgYXBw bGljYXRpb25zIHVzaW5nIENMIChlLmcuIAogICAgICB2aWRlbykgYW5kIGxvd2VyIHByaW9yaXR5 IHRyYWZmaWMgKGUuZy4gQXNzdXJlZCBGb3J3YXJkaW5nIChBRikpIAogICAgICBjb3VsZCBiZSBy ZWNlaXZpbmcgcmVkdWNlZCBzZXJ2aWNlLiBUaGVyZWZvcmUgYW4gZXZlbiBmYXN0ZXIgZmxvdyAK ICAgICAgcHJlLWVtcHRpb24gbWVjaGFuaXNtIHdvdWxkIGJlIGRlc2lyYWJsZSAoZXZlbiBpZiwg aW4gcHJhY3RpY2UsIAogICAgICBvcGVyYXRvcnMgaGF2ZSB0byBhZGQgYSBkZWxpYmVyYXRlIHBh dXNlIHRvIHJpZGUgb3V0IGEgdHJhbnNpZW50IAogICAgICB3aGlsZSB0aGUgbmF0dXJhbCByYXRl IG9mIGNhbGwgdGVhciBkb3duIG9yIGxvd2VyIGxheWVyIHByb3RlY3Rpb24gCiAgICAgIG1lY2hh bmlzbXMga2ljayBpbikuIAoKICAgbyBUaGUgQ0wgc2VydmljZSBzaG91bGQgc3VwcG9ydCBlbWVy Z2VuY3kgc2VydmljZXMgKFtFTUVSRy1SUVRTXSwgCiAgICAgIFtFTUVSRy1URUxdKSBhcyB3ZWxs IGFzIHRoZSBBc3N1cmVkIFNlcnZpY2Ugd2hpY2ggaXMgdGhlIElQIAogICAgICBpbXBsZW1lbnRh dGlvbiBvZiB0aGUgZXhpc3RpbmcgSVRVLVQvTkFUTy9Eb0QgdGVsZXBob25lIHN5c3RlbSAKICAg ICAgYXJjaGl0ZWN0dXJlIGtub3duIGFzIE11bHRpLUxldmVsIFByZS1lbXB0aW9uIGFuZCBQcmVj ZWRlbmNlIAogICAgICBbSVRVLk1MUFAuMTk5MF0gW0FOU0kuTUxQUC5TcGVjXVtBTlNJLk1MUFAu U3VwcGxlbWVudF0sIG9yIE1MUFAuIAogICAgICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGludm9sdmVz IGFkbWl0dGluZyBuZXcgZmxvd3MgdGhhdCBhcmUgcGFydCBvZiAKICAgICAgaGlnaCBwcmlvcml0 eSBzZXNzaW9ucyBldmVuIHdoZW4gYWRtaXNzaW9uIGNvbnRyb2wgd291bGQgcmVqZWN0IAogICAg ICBuZXcgcm91dGluZSBmbG93cy4gU2ltaWxhcmx5LCB3aGVuIGhhdmluZyB0byBjaG9vc2Ugd2hp Y2ggZmxvd3MgdG8gCiAgICAgIHByZS1lbXB0LCB0aGlzIGludm9sdmVzIHRha2luZyBpbnRvIGFj Y291bnQgdGhlIHByaW9yaXRpZXMgYW5kIAogICAgICBwcm9wZXJ0aWVzIG9mIHRoZSBzZXNzaW9u cyB0aGF0IGZsb3dzIGFyZSBwYXJ0IG9mLiAKCiAgICAKMi4yLiBLZXkgYXNzdW1wdGlvbnMgCgog ICBUaGUgZnJhbWV3b3JrIGRvZXMgbm90IHRyeSB0byBkZWxpdmVyIHRoZSBhYm92ZSBmdW5jdGlv bmFsaXR5IGluIGFsbCAKICAgc2NlbmFyaW9zLiBXZSBtYWtlIHRoZSBmb2xsb3dpbmcgYXNzdW1w dGlvbnMgYWJvdXQgdGhlIHR5cGUgb2YgCiAgIHNjZW5hcmlvIHRvIGJlIHNvbHZlZC4gIAoKICAg byBFZGdlLXRvLWVkZ2U6IGFsbCB0aGUgcm91dGVycyBpbiB0aGUgQ0wtcmVnaW9uIGFyZSB1cGdy YWRlZCB3aXRoIAogICAgICBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24sIGFuZCBhbGwgdGhl IGluZ3Jlc3MgYW5kIGVncmVzcyAKICAgICAgZ2F0ZXdheXMgYXJlIHVwZ3JhZGVkIHRvIHBlcmZv cm0gdGhlIG1lYXN1cmVtZW50LWJhc2VkIGFkbWlzc2lvbiAKICAgICAgY29udHJvbCBhbmQgZmxv dyBwcmUtZW1wdGlvbi4gTm90ZSB0aGF0IGFsdGhvdWdoIHRoZSB1cGdyYWRlcyAKICAgICAgcmVx dWlyZWQgYXJlIGVkZ2UtdG8tZWRnZSwgdGhlIENMIHNlcnZpY2UgaXMgcHJvdmlkZWQgZW5kLXRv LWVuZC4gCgogICBvIEFkZGl0aW9uYWwgbG9hZDogd2UgYXNzdW1lIHRoYXQgYW55IGFkZGl0aW9u YWwgbG9hZCBvZmZlcmVkIHdpdGhpbiAKICAgICAgdGhlIHJlYWN0aW9uIHRpbWUgb2YgdGhlIGFk bWlzc2lvbiBjb250cm9sIG1lY2hhbmlzbSBkb2Vzbid0IG1vdmUgCiAgICAgIHRoZSBDTC1yZWdp b24gZGlyZWN0bHkgZnJvbSBubyBjb25nZXN0aW9uIHRvIG92ZXJsb2FkLiBTbyBpdCAKICAgICAg YXNzdW1lcyB0aGVyZSB3aWxsIGFsd2F5cyBiZSBhbiBpbnRlcm1lZGlhdGUgc3RhZ2Ugd2hlcmUg c29tZSBDTCAKICAgICAgcGFja2V0cyBhcmUgQWRtaXNzaW9uIE1hcmtlZCwgYnV0IHRoZXkgYXJl IHN0aWxsIGRlbGl2ZXJlZCB3aXRob3V0IAogICAgICBzaWduaWZpY2FudCBRb1MgZGVncmFkYXRp b24uIFdlIGJlbGlldmUgdGhpcyBpcyB2YWxpZCBmb3IgY29yZSBhbmQgCiAgICAgIGJhY2tib25l IG5ldHdvcmtzIHdpdGggdHlwaWNhbCBjYWxsIGFycml2YWwgcGF0dGVybnMgKGdpdmVuIHRoZSAK ICAgICAgcmVhY3Rpb24gdGltZSBpcyBsaXR0bGUgbW9yZSB0aGFuIG9uZSByb3VuZCB0cmlwIHRp bWUgYWNyb3NzIHRoZSAKICAgICAgQ0wtcmVnaW9uKSwgYnV0IGlzIHVubGlrZWx5IHRvIGJlIHZh bGlkIGluIGFjY2VzcyBuZXR3b3JrcyB3aGVyZSAKICAgICAgdGhlIGdyYW51bGFyaXR5IG9mIGFu IGluZGl2aWR1YWwgY2FsbCBiZWNvbWVzIHNpZ25pZmljYW50LiAKIAogCkJyaXNjb2UgICAgICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxNF0g CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAg ICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgbyBBZ2dyZWdhdGlvbjogd2UgYXNzdW1lIHRoYXQg aW4gbm9ybWFsIG9wZXJhdGlvbnMsIHRoZXJlIGFyZSBtYW55IAogICAgICBDTCBtaWNyb2Zsb3dz IHdpdGhpbiB0aGUgQ0wtcmVnaW9uLCB0eXBpY2FsbHkgYXQgbGVhc3QgaHVuZHJlZHMgCiAgICAg IGJldHdlZW4gYW55IHBhaXIgb2YgaW5ncmVzcyBhbmQgZWdyZXNzIGdhdGV3YXlzLiBUaGUgaW1w bGljYXRpb24gCiAgICAgIGlzIHRoYXQgdGhlIHNvbHV0aW9uIGlzIHRhcmdldGVkIGF0IGNvcmUg YW5kIGJhY2tib25lIG5ldHdvcmtzIGFuZCAKICAgICAgcG9zc2libHkgcGFydHMgb2YgbGFyZ2Ug YWNjZXNzIG5ldHdvcmtzLiAgCgogICBvIFRydXN0OiB3ZSBhc3N1bWUgdGhhdCB0aGVyZSBpcyB0 cnVzdCBiZXR3ZWVuIGFsbCB0aGUgcm91dGVycyBpbiAKICAgICAgdGhlIENMLXJlZ2lvbi4gRm9y IGV4YW1wbGUsIHRoaXMgdHJ1c3QgbW9kZWwgaXMgc2F0aXNmaWVkIGlmIG9uZSAKICAgICAgb3Bl cmF0b3IgcnVucyB0aGUgd2hvbGUgb2YgdGhlIENMLXJlZ2lvbi4gQnV0IHdlIG1ha2Ugbm8gc3Vj aCAKICAgICAgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGVuZCBob3N0cywgaS5lLiBkZXBlbmRpbmcg b24gdGhlIHNjZW5hcmlvIAogICAgICB0aGV5IG1heSBiZSB0cnVzdGVkIG9yIHVudHJ1c3RlZCBi eSB0aGUgQ0wtcmVnaW9uLiAgCgogICBvIFNpZ25hbGxpbmc6IHdlIGFzc3VtZSB0aGF0IHRoZSBl bmQtdG8tZW5kIHNpZ25hbGxpbmcgcHJvdG9jb2wgaXMgCiAgICAgIFJTVlAuIFNlY3Rpb24gMyBk ZXNjcmliZXMgaG93IHRoZSBDTC1yZWdpb24gZml0cyBpbnRvIHN1Y2ggYW4gZW5kLQogICAgICB0 by1lbmQgUW9TIHNjZW5hcmlvLCB3aGlsc3QgW1JTVlAtUENOXSBkZXNjcmliZXMgdGhlIGV4dGVu c2lvbnMgdG8gCiAgICAgIFJTVlAgdGhhdCBhcmUgcmVxdWlyZWQuICAKCiAgIG8gU2VwYXJhdGlv bjogd2UgYXNzdW1lIHRoYXQgYWxsIHJvdXRlcnMgd2l0aGluIHRoZSBDTC1yZWdpb24gYXJlIAog ICAgICB1cGdyYWRlZCB3aXRoIHRoZSBDTCBtZWNoYW5pc20sIHNvIHRoZSByZXF1aXJlbWVudHMg b2YgW0Zsb3lkXSBhcmUgCiAgICAgIG1ldCBiZWNhdXNlIHRoZSBDTC1yZWdpb24gaXMgYW4gZW5j bG9zZWQgZW52aXJvbm1lbnQuIEFsc28sIGFuIAogICAgICBvcGVyYXRvciBzZXBhcmF0ZXMgQ0wt dHJhZmZpYyBpbiB0aGUgQ0wtcmVnaW9uIGZyb20gb3V0c2lkZSAKICAgICAgdHJhZmZpYyBieSBh ZG1pbmlzdHJhdGl2ZSBjb25maWd1cmF0aW9uIG9mIHRoZSByaW5nIG9mIGdhdGV3YXlzIAogICAg ICBhcm91bmQgdGhlIHJlZ2lvbi4gV2l0aGluIHRoZSBDTC1yZWdpb24gd2UgYXNzdW1lIHRoYXQg dGhlIENMLQogICAgICB0cmFmZmljIGlzIHNlcGFyYXRlZCBmcm9tIG5vbi1DTCB0cmFmZmljLiAg CgogICBvIFJvdXRpbmc6IHdlIGFzc3VtZSB0aGF0IGFsbCBwYWNrZXRzIGJldHdlZW4gYSBwYWly IG9mIGluZ3Jlc3MgYW5kIAogICAgICBlZ3Jlc3MgZ2F0ZXdheXMgZm9sbG93IHRoZSBzYW1lIHBh dGgsIG9yIHRoYXQgdGhleSBmb2xsb3cgCiAgICAgIGRpZmZlcmVudCBwYXRocyBidXQgdGhhdCB0 aGUgbG9hZCBiYWxhbmNpbmcgc2NoZW1lIGlzIHR1bmVkIGluIHRoZSAKICAgICAgQ0wtcmVnaW9u IHRvIGRpc3RyaWJ1dGUgbG9hZCBzdWNoIHRoYXQgdGhlIGRpZmZlcmVudCBwYXRocyBhbHdheXMg CiAgICAgIHJlY2VpdmUgY29tcGFyYWJsZSByZWxhdGl2ZSBsb2FkLiBUaGlzIGVuc3VyZXMgdGhh dCB0aGUgCiAgICAgIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgdXNlZCBpbiB0aGUgYWRtaXNz aW9uIGNvbnRyb2wgcHJvY2VkdXJlIAogICAgICAoYW5kIHdoaWNoIGlzIGNvbXB1dGVkIHRha2lu ZyBpbnRvIGFjY291bnQgcGFja2V0cyB0cmF2ZWxsaW5nIG9uIAogICAgICBhbGwgdGhlIHBhdGhz KSBhcHByb3hpbWF0ZWx5IHJlZmxlY3RzIHRoZSBzdGF0dXMgb2YgdGhlIGFjdHVhbCAKICAgICAg cGF0aCB0aGF0IHdpbGwgYmUgZm9sbG93ZWQgYnkgdGhlIG5ldyBtaWNyb2Zsb3cncyBwYWNrZXRz LiAgIAoKICAgIAoKICAgV2UgYXJlIGludmVzdGlnYXRpbmcgd2F5cyBvZiBsb29zZW5pbmcgdGhl IHJlc3RyaWN0aW9ucyBzZXQgYnkgc29tZSAKICAgb2YgdGhlc2UgYXNzdW1wdGlvbnMsIGZvciBp bnN0YW5jZTogCgogICBvIFRydXN0OiB0byBhbGxvdyB0aGUgQ0wtcmVnaW9uIHRvIHNwYW4gbXVs dGlwbGUsIG5vbi10cnVzdGluZyAKICAgICAgb3BlcmF0b3JzLCB1c2luZyB0aGUgdGVjaG5pcXVl IG9mIFtSZS1QQ05dIGFzIG1lbnRpb25lZCBpbiBTZWN0aW9uIAogICAgICA1LjcuMi4gCgoKCgog CiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDE1XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2Rl bCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBvIFNpZ25hbGxpbmc6 IHdlIGJlbGlldmUgdGhhdCB0aGUgc29sdXRpb24gY291bGQgb3BlcmF0ZSB3aXRoIAogICAgICBh bm90aGVyIHNpZ25hbGxpbmcgcHJvdG9jb2wsIHN1Y2ggYXMgdGhlIG9uZSBwcm9kdWNlZCBieSB0 aGUgTlNJUyAKICAgICAgd29ya2luZyBncm91cC4gSXQgY291bGQgYWxzbyB3b3JrIHdpdGggYXBw bGljYXRpb24gbGV2ZWwgCiAgICAgIHNpZ25hbGxpbmcgYXMgc3VnZ2VzdGVkIGluIFtSVC1FQ05d LiAKCiAgIG8gQWRkaXRpb25hbCBsb2FkOiB3ZSBiZWxpZXZlIHRoYXQgdGhlIGFzc3VtcHRpb24g aXMgdmFsaWQgZm9yIGNvcmUgCiAgICAgIGFuZCBiYWNrYm9uZSBuZXR3b3Jrcywgd2l0aCBhbiBh cHByb3ByaWF0ZSBtYXJnaW4gYmV0d2VlbiB0aGUgCiAgICAgIGNvbmZpZ3VyZWQtYWRtaXNzaW9u LXJhdGUgYW5kIHRoZSBjYXBhY2l0eSBmb3IgQ0wgdHJhZmZpYy4gCiAgICAgIEhvd2V2ZXIsIGlu IHByaW5jaXBsZSBhIGJ1cnN0IG9mIGFkbWlzc2lvbiByZXF1ZXN0cyBjYW4gb2NjdXIgaW4gYSAK ICAgICAgc2hvcnQgdGltZS4gV2UgZXhwZWN0IHRoaXMgdG8gYmUgYSByYXJlIGV2ZW50IHVuZGVy IG5vcm1hbCAKICAgICAgY29uZGl0aW9ucywgYnV0IGl0IGNvdWxkIGhhcHBlbiBlLmcuIGR1ZSB0 byBhICdmbGFzaCBjcm93ZCcuIElmIGl0IAogICAgICBkb2VzLCB0aGVuIG1vcmUgZmxvd3MgbWF5 IGJlIGFkbWl0dGVkIHRoYW4gc2hvdWxkIGJlLCB0cmlnZ2VyaW5nIAogICAgICB0aGUgcHJlLWVt cHRpb24gbWVjaGFuaXNtLiBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIGFuIG9wZXJhdG9yIAogICAg ICBtaWdodCB0cnkgdG8gYWxsZXZpYXRlIHRoaXMgaXNzdWUsIHdoaWNoIGFyZSBkaXNjdXNzZWQg aW4gdGhlIAogICAgICAnRmxhc2ggY3Jvd2RzJyBzZWN0aW9uIDUuNSBsYXRlci4gIAoKICAgbyBT ZXBhcmF0aW9uOiB0aGUgYXNzdW1wdGlvbiB0aGF0IENMIHRyYWZmaWMgaXMgc2VwYXJhdGVkIGZy b20gbm9uLQogICAgICBDTCB0cmFmZmljIGltcGxpZXMgdGhhdCB0aGUgQ0wgdHJhZmZpYyBoYXMg aXRzIG93biBQSEIsIG5vdCBzaGFyZWQgCiAgICAgIHdpdGggb3RoZXIgdHJhZmZpYy4gV2UgYXJl IGxvb2tpbmcgYXQgd2hldGhlciBpdCBjb3VsZCBzaGFyZSAKICAgICAgRXhwZWRpdGVkIEZvcndh cmRpbmcncyBQSEIsIGJ1dCBzdXBwbGVtZW50ZWQgd2l0aCBQcmUtQ29uZ2VzdGlvbiAKICAgICAg Tm90aWZpY2F0aW9uLiBJZiB0aGlzIGlzIHBvc3NpYmxlLCBvdGhlciBQSEJzIChsaWtlIEFzc3Vy ZWQgCiAgICAgIEZvcndhcmRpbmcpIGNvdWxkIGJlIHN1cHBsZW1lbnRlZCB3aXRoIHRoZSBzYW1l IG5ldyBiZWhhdmlvdXJzLiAKICAgICAgVGhpcyBpcyBzaW1pbGFyIHRvIGhvdyBSRkMzMTY4IEVD TiB3YXMgZGVmaW5lZCB0byBzdXBwbGVtZW50IGFueSAKICAgICAgUEhCLiAKCiAgIG8gUm91dGlu Zzogd2UgYXJlIGxvb2tpbmcgaW4gZ3JlYXRlciBkZXRhaWwgYXQgdGhlIHNvbHV0aW9uIGluIHRo ZSAKICAgICAgcHJlc2VuY2Ugb2YgRXF1YWwgQ29zdCBNdWx0aS1QYXRoIHJvdXRpbmcgYW5kIGF0 IHN1aXRhYmxlIAogICAgICBlbmhhbmNlbWVudHMuIFNlZSBhbHNvIHRoZSAnRUNNUCcgc2VjdGlv biA1LjEgbGF0ZXIuICAKCiAgICAKCgoKCgoKCgoKCgoKCgoKCiAKIApCcmlzY29lICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTZdIAoM CkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAg ICBPY3RvYmVyIDIwMDYgCiAgICAKCjMuIERlcGxveW1lbnQgbW9kZWwgCgozLjEuIEFkbWlzc2lv biBjb250cm9sICAKCiAgIEluIHRoaXMgc2VjdGlvbiB3ZSBkZXNjcmliZSB0aGUgYWRtaXNzaW9u IGNvbnRyb2wgbWVjaGFuaXNtLiBXZSAKICAgZGlzY3VzcyB0aGUgdGhyZWUgcGllY2VzIG9mIHRo ZSBzb2x1dGlvbiBhbmQgdGhlbiBnaXZlIGFuIGV4YW1wbGUgb2YgCiAgIGhvdyB0aGV5IGZpdCB0 b2dldGhlciBpbiBhIHVzZSBjYXNlOiAKCiAgIG8gdGhlIG5ldyBQcmUtQ29uZ2VzdGlvbiBOb3Rp ZmljYXRpb24gZm9yIEFkbWlzc2lvbiBNYXJraW5nIHVzZWQgYnkgCiAgICAgIGFsbCByb3V0ZXJz IGluIHRoZSBDTC1yZWdpb24gCgogICBvIGhvdyB0aGUgbWVhc3VyZW1lbnRzIG1hZGUgc3VwcG9y dCBvdXIgYWRtaXNzaW9uIGNvbnRyb2wgbWVjaGFuaXNtICAKCiAgIG8gaG93IHRoZSBlZGdlIHRv IGVkZ2UgbWVjaGFuaXNtIGZpdHMgaW50byB0aGUgZW5kIHRvIGVuZCBSU1ZQIAogICAgICBzaWdu YWxsaW5nIAoKICAgIAoKMy4xLjEuIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiBmb3IgQWRt aXNzaW9uIE1hcmtpbmcgCgogICBUaGlzIGlzIGRpc2N1c3NlZCBpbiBbUENOXS4gSGVyZSB3ZSBv bmx5IGdpdmUgYSBicmllZiBvdXRsaW5lLiAgCgogICBUbyBzdXBwb3J0IG91ciBhZG1pc3Npb24g Y29udHJvbCBtZWNoYW5pc20sIGVhY2ggcm91dGVyIGluIHRoZSBDTC0KICAgcmVnaW9uIHJ1bnMg YW4gYWxnb3JpdGhtIHRvIGRldGVybWluZSB3aGV0aGVyIHRvIEFkbWlzc2lvbiBNYXJrIHRoZSAK ICAgcGFja2V0LiBUaGUgYWxnb3JpdGhtIG1lYXN1cmVzIHRoZSBhZ2dyZWdhdGUgQ0wgdHJhZmZp YyBvbiB0aGUgbGluayAKICAgYW5kIGVuc3VyZXMgdGhhdCBwYWNrZXRzIGFyZSBhZG1pc3Npb24g bWFya2VkIGJlZm9yZSB0aGUgYWN0dWFsIHF1ZXVlIAogICBidWlsZHMgdXAsIGJ1dCB3aGVuIGl0 IGlzIGluIGRhbmdlciBvZiBkb2luZyBzbyBzb29uOyB0aGUgcHJvYmFiaWxpdHkgCiAgIG9mIGFk bWlzc2lvbiBtYXJraW5nIGluY3JlYXNlcyB3aXRoIHRoZSBkYW5nZXIuIFRoZSBhbGdvcml0aG0n cyBtYWluIAogICBwYXJhbWV0ZXIgaXMgdGhlIGNvbmZpZ3VyZWQtYWRtaXNzaW9uLXJhdGUsIHdo aWNoIGlzIHNldCBsb3dlciB0aGFuIAogICB0aGUgbGluayBzcGVlZCwgcGVyaGFwcyBjb25zaWRl cmFibHkgc28uIEFkbWlzc2lvbiBtYXJrZWQgcGFja2V0cyAKICAgaW5kaWNhdGUgdGhhdCB0aGUg Q0wgdHJhZmZpYyByYXRlIGlzIHJlYWNoaW5nIHRoZSBjb25maWd1cmVkLQogICBhZG1pc3Npb24t cmF0ZSBhbmQgc28gYWN0IGFzIGFuICJlYXJseSB3YXJuaW5nIiB0aGF0IHRoZSBlbmdpbmVlcmVk IAogICBjYXBhY2l0eSBpcyBuZWFybHkgcmVhY2hlZC4gVGhlcmVmb3JlIHRoZXkgaW5kaWNhdGUg dGhhdCByZXF1ZXN0cyB0byAKICAgYWRtaXQgcHJvc3BlY3RpdmUgbmV3IENMIGZsb3dzIG1heSBu ZWVkIHRvIGJlIHJlZnVzZWQuIAoKICAgIAoKMy4xLjIuIE1lYXN1cmVtZW50cyB0byBzdXBwb3J0 IGFkbWlzc2lvbiBjb250cm9sIAoKICAgVG8gc3VwcG9ydCBvdXIgYWRtaXNzaW9uIGNvbnRyb2wg bWVjaGFuaXNtIHRoZSBlZ3Jlc3MgbWVhc3VyZXMgdGhlIAogICBDb25nZXN0aW9uLUxldmVsLUVz dGltYXRlIGZvciB0cmFmZmljIGZyb20gZWFjaCByZW1vdGUgaW5ncmVzcyAKICAgZ2F0ZXdheSwg aS5lLiBwZXIgQ0wtcmVnaW9uLWFnZ3JlZ2F0ZS4gVGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1h dGUgCiAgIGlzIHRoZSBudW1iZXIgb2YgYml0cyBpbiBDTCBwYWNrZXRzIHRoYXQgYXJlIGFkbWlz c2lvbiBtYXJrZWQgb3IgcHJlLQogICBlbXB0aW9uIG1hcmtlZCwgZGl2aWRlZCBieSB0aGUgbnVt YmVyIG9mIGJpdHMgaW4gYWxsIENMIHBhY2tldHMuIEl0IAogICBpcyBjYWxjdWxhdGVkIGFzIGFu IGV4cG9uZW50aWFsbHkgd2VpZ2h0ZWQgbW92aW5nIGF2ZXJhZ2UuIEl0IGlzIAogICBjYWxjdWxh dGVkIGJ5IGFuIGVncmVzcyBnYXRld2F5IHNlcGFyYXRlbHkgZm9yIHRoZSBDTCBwYWNrZXRzIGZy b20gCiAgIGVhY2ggcGFydGljdWxhciBpbmdyZXNzIGdhdGV3YXkuICAKIAogCkJyaXNjb2UgICAg ICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAx N10gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAg ICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgV2h5IGFyZSBwcmUtZW1wdGlvbiBtYXJrZWQg cGFja2V0cyBpbmNsdWRlZCBpbiB0aGUgQ29uZ2VzdGlvbi1MZXZlbC0KICAgRXN0aW1hdGU/IFBy ZS1lbXB0aW9uIG1hcmtpbmcgb3Zlci13cml0ZXMgYWRtaXNzaW9uIG1hcmtpbmcsIGkuZS4gYSAK ICAgcGFja2V0IGNhbm5vdCBiZSBib3RoIGFkbWlzc2lvbiBhbmQgcHJlLWVtcHRpb24gbWFya2Vk LiBTbyBpZiBwcmUtCiAgIGVtcHRpb24gbWFya2VkIHBhY2tldHMgd2VyZW4ndCBjb3VudGVkIHdl IHdvdWxkIGhhdmUgdGhlIGFub21hbHkgdGhhdCAKICAgYXMgdGhlIHRyYWZmaWMgcmF0ZSBncmV3 IGFib3ZlIHRoZSBjb25maWd1cmVkLXByZS1lbXB0aW9uLXJhdGUsIHRoZSAKICAgQ29uZ2VzdGlv bi1MZXZlbC1Fc3RpbWF0ZSB3b3VsZCBmYWxsLiBJZiBhIHBhcnRpY3VsYXIgZW5jb2Rpbmcgc2No ZW1lIAogICBpcyBjaG9zZW4gd2hlcmUgYSBwYWNrZXQgY2FuIGJlIGJvdGggYWRtaXNzaW9uIGFu ZCBwcmUtZW1wdGlvbiBtYXJrZWQgCiAgIChzdWNoIGFzIEFsdGVybmF0aXZlIDQgaW4gQXBwZW5k aXggQyBvZiBbUENOXSksIHRoZW4gdGhpcyBpcyBub3QgCiAgIG5lY2Vzc2FyeS4gCgogICBUaGlz IENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgcHJvdmlkZXMgYW4gZXN0aW1hdGUgb2YgaG93IG5l YXIgdGhlIAogICBsaW5rcyBvbiB0aGUgcGF0aCBpbnNpZGUgdGhlIENMLXJlZ2lvbiBhcmUgZ2V0 dGluZyB0byB0aGUgY29uZmlndXJlZC0KICAgYWRtaXNzaW9uLXJhdGUuIE5vdGUgdGhhdCB0aGUg bWV0ZXJpbmcgaXMgZG9uZSBzZXBhcmF0ZWx5IHBlciBpbmdyZXNzIAogICBnYXRld2F5LCBiZWNh dXNlIHRoZXJlIG1heSBiZSBzdWZmaWNpZW50IGNhcGFjaXR5IG9uIGFsbCB0aGUgcm91dGVycyAK ICAgb24gdGhlIHBhdGggYmV0d2VlbiBvbmUgaW5ncmVzcyBnYXRld2F5IGFuZCBhIHBhcnRpY3Vs YXIgZWdyZXNzLCBidXQgCiAgIG5vdCBmcm9tIGEgc2Vjb25kIGluZ3Jlc3MgdG8gdGhhdCBzYW1l IGVncmVzcyBnYXRld2F5LiAKCjMuMS4zLiBIb3cgZWRnZS10by1lZGdlIGFkbWlzc2lvbiBjb250 cm9sIHN1cHBvcnRzIGVuZC10by1lbmQgUW9TIAogICBzaWduYWxsaW5nIAoKICAgQ29uc2lkZXIg YSBzY2VuYXJpbyB0aGF0IGNvbnNpc3RzIG9mIHR3byBlbmQgaG9zdHMsIGVhY2ggY29ubmVjdGVk IHRvIAogICB0aGVpciBvd24gYWNjZXNzIG5ldHdvcmtzLCB3aGljaCBhcmUgbGlua2VkIGJ5IHRo ZSBDTC1yZWdpb24uIEEgCiAgIHNvdXJjZSB0cmllcyB0byBzZXQgdXAgYSBuZXcgQ0wgbWljcm9m bG93IGJ5IHNlbmRpbmcgYW4gUlNWUCBQQVRIIAogICBtZXNzYWdlLCBhbmQgdGhlIHJlY2Vpdmlu ZyBlbmQgaG9zdCByZXBsaWVzIHdpdGggYW4gUlNWUCBSRVNWIAogICBtZXNzYWdlLiBPdXRzaWRl IHRoZSBDTC1yZWdpb24gc29tZSBvdGhlciBtZXRob2QsIGZvciBpbnN0YW5jZSAKICAgSW50U2Vy diwgaXMgdXNlZCB0byBwcm92aWRlIFFvUy4gRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgUlNWUCB0 aGUgQ0wtCiAgIHJlZ2lvbiBpcyBhIHNpbmdsZSBob3AsIHNvIHRoZSBSU1ZQIFBBVEggYW5kIFJF U1YgbWVzc2FnZXMgYXJlIAogICBwcm9jZXNzZWQgYnkgdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBn YXRld2F5cyBidXQgYXJlIGNhcnJpZWQgCiAgIHRyYW5zcGFyZW50bHkgYWNyb3NzIGFsbCB0aGUg aW50ZXJpb3Igcm91dGVyczsgaGVuY2UsIHRoZSBpbmdyZXNzIGFuZCAKICAgZWdyZXNzIGdhdGV3 YXlzIGhvbGQgcGVyIG1pY3JvZmxvdyBzdGF0ZSwgd2hpbHN0IG5vIHBlciBtaWNyb2Zsb3cgCiAg IHN0YXRlIGlzIGtlcHQgYnkgdGhlIGludGVyaW9yIHJvdXRlcnMuIFNvIGZhciB0aGlzIGlzIGFz IGluIEludFNlcnYgCiAgIG92ZXIgRGlmZlNlcnYgW1JGQzI5OThdLiBIb3dldmVyLCBpbiBvcmRl ciB0byBzdXBwb3J0IG91ciBhZG1pc3Npb24gCiAgIGNvbnRyb2wgbWVjaGFuaXNtLCB0aGUgZWdy ZXNzIGdhdGV3YXkgYWRkcyB0byB0aGUgUkVTViBtZXNzYWdlIGFuIAogICBvcGFxdWUgb2JqZWN0 IHdoaWNoIHN0YXRlcyB0aGUgY3VycmVudCBDb25nZXN0aW9uLUxldmVsLUVzdGltYXRlIGZvciAK ICAgdGhlIHJlbGV2YW50IENMLXJlZ2lvbi1hZ2dyZWdhdGUuIERldGFpbHMgb2YgdGhlIGNvcnJl c3BvbmRpbmcgUlNWUCAKICAgZXh0ZW5zaW9ucyBhcmUgZGVzY3JpYmVkIGluIFtSU1ZQLVBDTl0u IAoKMy4xLjQuIFVzZSBjYXNlIAoKICAgVG8gc2VlIGhvdyB0aGUgdGhyZWUgcGllY2VzIG9mIHRo ZSBzb2x1dGlvbiBmaXQgdG9nZXRoZXIsIHdlIGltYWdpbmUgCiAgIGEgc2NlbmFyaW8gd2hlcmUg c29tZSBtaWNyb2Zsb3dzIGFyZSBhbHJlYWR5IGluIHBsYWNlIGJldHdlZW4gYSBnaXZlbiAKICAg cGFpciBvZiBpbmdyZXNzIGFuZCBlZ3Jlc3MgZ2F0ZXdheXMsIGJ1dCB0aGUgdHJhZmZpYyBsb2Fk IGlzIHN1Y2ggCiAgIHRoYXQgbm8gcGFja2V0cyBmcm9tIHRoZXNlIGZsb3dzIGFyZSBhZG1pc3Np b24gbWFya2VkIGFzIHRoZXkgdHJhdmVsIAogICBhY3Jvc3MgdGhlIENMLXJlZ2lvbi4gQSBzb3Vy Y2Ugd2FudGluZyB0byBzdGFydCBhIG5ldyBDTCBtaWNyb2Zsb3cgCiAgIHNlbmRzIGFuIFJTVlAg UEFUSCBtZXNzYWdlLiBUaGUgZWdyZXNzIGdhdGV3YXkgYWRkcyBhbiBvYmplY3QgdG8gdGhlIAog ICBSRVNWIG1lc3NhZ2Ugd2l0aCB0aGUgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZSwgd2hpY2gg aXMgemVyby4gVGhlIAogICBpbmdyZXNzIGdhdGV3YXkgc2VlcyB0aGlzIGFuZCBjb25zZXF1ZW50 bHkgYWRtaXRzIHRoZSBuZXcgZmxvdy4gSXQgCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4 cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMThdIAoMCkludGVybmV0 LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVy IDIwMDYgCiAgICAKCiAgIHRoZW4gZm9yd2FyZHMgdGhlIFJTVlAgUkVTViBtZXNzYWdlIHVwc3Ry ZWFtIHRvd2FyZHMgdGhlIHNvdXJjZSBlbmQgCiAgIGhvc3QuIEhlbmNlLCBhc3N1bWluZyB0aGVy ZSdzIHN1ZmZpY2llbnQgY2FwYWNpdHkgaW4gdGhlIGFjY2VzcyAKICAgbmV0d29ya3MsIHRoZSBu ZXcgbWljcm9mbG93IGlzIGFkbWl0dGVkIGVuZC10by1lbmQuICAKCiAgIFRoZSBzb3VyY2Ugbm93 IHNlbmRzIENMIHBhY2tldHMsIHdoaWNoIGFycml2ZSBhdCB0aGUgaW5ncmVzcyBnYXRld2F5LiAK ICAgVGhlIGluZ3Jlc3MgdXNlcyBhIGZpdmUtdHVwbGUgZmlsdGVyIHRvIGlkZW50aWZ5IHRoYXQg dGhlIHBhY2tldHMgYXJlIAogICBwYXJ0IG9mIGEgcHJldmlvdXNseSBhZG1pdHRlZCBDTCBtaWNy b2Zsb3csIGFuZCBpdCBhbHNvIHBvbGljZXMgdGhlIAogICBtaWNyb2Zsb3cgdG8gZW5zdXJlIGl0 IHJlbWFpbnMgd2l0aGluIGl0cyB0cmFmZmljIHByb2ZpbGUuIChUaGUgCiAgIGluZ3Jlc3MgaGFz IGxlYXJudCB0aGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gZnJvbSB0aGUgUlNWUCBtZXNzYWdlcy4p IAogICBXaGVuIGZvcndhcmRpbmcgYSBwYWNrZXQgYmVsb25naW5nIHRvIGFuIGFkbWl0dGVkIG1p Y3JvZmxvdywgdGhlIAogICBpbmdyZXNzIHNldHMgdGhlIHBhY2tldCdzIERTQ1AgYW5kIEVDTiBm aWVsZHMgdG8gdGhlIGFwcHJvcHJpYXRlIAogICB2YWx1ZXMgY29uZmlndXJlZCBmb3IgdGhlIENM IHJlZ2lvbi4gVGhlIENMIHBhY2tldCBub3cgdHJhdmVscyBhY3Jvc3MgCiAgIHRoZSBDTC1yZWdp b24sIGdldHRpbmcgYWRtaXNzaW9uIG1hcmtlZCBpZiBuZWNlc3NhcnkuICAKCiAgIE5leHQsIHdl IGltYWdpbmUgdGhlIHNhbWUgc2NlbmFyaW8gYnV0IGF0IGEgbGF0ZXIgdGltZSB3aGVuIGxvYWQg aXMgCiAgIGhpZ2hlciBhdCBvbmUgKG9yIG1vcmUpIG9mIHRoZSBpbnRlcmlvciByb3V0ZXJzLCB3 aGljaCBzdGFydCB0byAKICAgQWRtaXNzaW9uIE1hcmsgQ0wgcGFja2V0cywgYmVjYXVzZSB0aGVp ciBsb2FkIG9uIHRoZSBvdXRnb2luZyBsaW5rIGlzIAogICBuZWFyaW5nIHRoZSBjb25maWd1cmVk LWFkbWlzc2lvbi1yYXRlLiBUaGUgbmV4dCB0aW1lIGEgc291cmNlIHRyaWVzIAogICB0byBzZXQg dXAgYSBDTCBtaWNyb2Zsb3csIHRoZSBpbmdyZXNzIGdhdGV3YXkgbGVhcm5zIChmcm9tIHRoZSAK ICAgZWdyZXNzKSB0aGUgcmVsZXZhbnQgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZS4gSWYgaXQg aXMgZ3JlYXRlciB0aGFuIAogICBzb21lIENMRS10aHJlc2hvbGQgdmFsdWUgdGhlbiB0aGUgaW5n cmVzcyByZWZ1c2VzIHRoZSByZXF1ZXN0LCAKICAgb3RoZXJ3aXNlIGl0IGlzIGFjY2VwdGVkLiBU aGUgaW5ncmVzcyBnYXRld2F5IGNvdWxkIGFsc28gdGFrZSBpbnRvIAogICBhY2NvdW50IGF0dHJp YnV0ZXMgb2YgdGhlIFJTVlAgcmVzZXJ2YXRpb24gKHN1Y2ggYXMgZm9yIGV4YW1wbGUgdGhlIAog ICBSU1ZQIHByZS1lbXB0aW9uIHByaW9yaXR5IG9mIFtSU1ZQLVBSRUVNUFRJT05dIG9yIHRoZSBS U1ZQIGFkbWlzc2lvbiAKICAgcHJpb3JpdHkgb2YgW1JTVlAtRU1FUkdFTkNZXSkgYXMgd2VsbCBh cyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBhIAogICBwb2xpY3kgZGVjaXNpb24gcG9pbnQgaW4g b3JkZXIgdG8gbWFrZSBhIG1vcmUgc29waGlzdGljYXRlZCBhZG1pc3Npb24gCiAgIGRlY2lzaW9u LiBUaGlzIHdheSwgZmxvdyBhZG1pc3Npb24gY2FuIGhlbHAgZW1lcmdlbmN5L21pbGl0YXJ5IGNh bGxzIAogICBieSB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBjb3JyZXNwb25kaW5nIHByaW9yaXRp ZXMgKGFzIGNvbnZleWVkIGluIAogICBSU1ZQIHBvbGljeSBlbGVtZW50cykgd2hlbiBkZWNpZGlu ZyB0byBhZG1pdCBvciByZWplY3QgYSBuZXcgCiAgIHJlc2VydmF0aW9uLiBVc2Ugb2YgUlNWUCBm b3IgdGhlIHN1cHBvcnQgb2YgZW1lcmdlbmN5L21pbGl0YXJ5IAogICBhcHBsaWNhdGlvbnMgaXMg ZGlzY3Vzc2VkIGluIGZ1cnRoZXIgZGV0YWlsIGluIFtSRkM0NTQyXSBhbmQgW1JTVlAtCiAgIEVN RVJHRU5DWV0uIAoKICAgSXQgaXMgYWxzbyBwb3NzaWJsZSBmb3IgYW4gZWdyZXNzIGdhdGV3YXkg dG8gZ2V0IGEgUlNWUCBSRVNWIG1lc3NhZ2UgCiAgIGFuZCBub3Qga25vdyB3aGF0IHRoZSBDb25n ZXN0aW9uLUxldmVsLUVzdGltYXRlIGlzLiBGb3IgZXhhbXBsZSwgaWYgCiAgIHRoZXJlIGFyZSBu byBDTCBtaWNyb2Zsb3dzIGF0IHByZXNlbnQgYmV0d2VlbiB0aGUgcmVsZXZhbnQgaW5ncmVzcyAK ICAgYW5kIGVncmVzcyBnYXRld2F5cy4gSW4gdGhpcyBjYXNlIHRoZSBlZ3Jlc3MgcmVxdWVzdHMg dGhlIGluZ3Jlc3MgdG8gCiAgIHNlbmQgcHJvYmUgcGFja2V0cywgZnJvbSB3aGljaCBpdCBjYW4g aW5pdGlhbGlzZSBpdHMgbWV0ZXIuIFJTVlAgCiAgIEV4dGVuc2lvbnMgZm9yIHN1Y2ggYSByZXF1 ZXN0IHRvIHNlbmQgcHJvYmUgZGF0YSBjYW4gYmUgZm91bmQgaW4gCiAgIFtSU1ZQLVBDTl0uIAoK ICAgIAoKIAoKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDE5XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVw bG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgozLjIu IEZsb3cgcHJlLWVtcHRpb24gCgogICBJbiB0aGlzIHNlY3Rpb24gd2UgZGVzY3JpYmUgdGhlIGZs b3cgcHJlLWVtcHRpb24gbWVjaGFuaXNtLiBXZSAKICAgZGlzY3VzcyB0aGUgdHdvIHBhcnRzIG9m IHRoZSBzb2x1dGlvbiBhbmQgdGhlbiBnaXZlIGFuIGV4YW1wbGUgb2YgaG93IAogICB0aGV5IGZp dCB0b2dldGhlciBpbiBhIHVzZSBjYXNlOiAKCiAgIG8gSG93IGFuIGluZ3Jlc3MgZ2F0ZXdheSBp cyB0cmlnZ2VyZWQgdG8gdGVzdCB3aGV0aGVyIGZsb3cgcHJlLQogICAgICBlbXB0aW9uIG1heSBi ZSBuZWVkZWQgCgogICBvIEhvdyBhbiBpbmdyZXNzIGdhdGV3YXkgZGV0ZXJtaW5lcyB0aGUgcmln aHQgYW1vdW50IG9mIENMIHRyYWZmaWMgCiAgICAgIHRvIGRyb3AgCgogICBUaGUgbWVjaGFuaXNt IGlzIGRlZmluZWQgaW4gW1BDTl0gYW5kIFtSU1ZQLVBDTl0uIAoKICAgVHdvIHN1YnNlcXVlbnQg c3RlcHMgY291bGQgYmU6IAoKICAgbyBDaG9vc2Ugd2hpY2ggZmxvd3MgdG8gc2hlZCwgaW5mbHVl bmNlZCBieSB0aGVpciBwcmlvcml0eSBhbmQgb3RoZXIgCiAgICAgIHBvbGljeSBpbmZvcm1hdGlv biAKCiAgIG8gVGVhciBkb3duIHRoZSByZXNlcnZhdGlvbnMgZm9yIHRoZSBjaG9zZW4gZmxvd3Mg CgogICBXZSBwcm92aWRlIHNvbWUgaGludHMgYWJvdXQgdGhlc2UgbGF0dGVyIHR3byBzdGVwcyBp biBTZWN0aW9uIDMuMi4zLCAKICAgYnV0IGRvbid0IHRyeSB0byBwcm92aWRlIGZ1bGwgZ3VpZGFu Y2UgYXMgaXQgZ3JlYXRseSBkZXBlbmRzIG9uIHRoZSAKICAgcGFydGljdWxhciBkZXRhaWxlZCBv cGVyYXRpb25hbCBzaXR1YXRpb24uIAoKICAgQW4gZXNzZW50aWFsIFFvUyBpc3N1ZSBpbiBjb3Jl IGFuZCBiYWNrYm9uZSBuZXR3b3JrcyBpcyBiZWluZyBhYmxlIHRvIAogICBjb3BlIHdpdGggZmFp bHVyZXMgb2Ygcm91dGVycyBhbmQgbGlua3MuIFRoZSBjb25zZXF1ZW50IHJlLXJvdXRpbmcgCiAg IGNhbiBjYXVzZSBzZXZlcmUgY29uZ2VzdGlvbiBvbiBzb21lIGxpbmtzIGFuZCBoZW5jZSBkZWdy YWRlIHRoZSBRb1MgCiAgIGV4cGVyaWVuY2VkIGJ5IG9uLWdvaW5nIG1pY3JvZmxvd3MgYW5kIG90 aGVyLCBsb3dlciBwcmlvcml0eSB0cmFmZmljLiAKICAgRXZlbiB3aGVuIHRoZSBuZXR3b3JrIGlz IGVuZ2luZWVyZWQgdG8gc3VzdGFpbiBhIHNpbmdsZSBsaW5rIGZhaWx1cmUsIAogICBtdWx0aXBs ZSBsaW5rIGZhaWx1cmVzIChlLmcuIGR1ZSB0byBhIGZpYnJlIGN1dCwgcm91dGVyIGZhaWx1cmUg b3IgYSAKICAgbmF0dXJhbCBkaXNhc3RlcikgY2FuIGNhdXNlIHZpb2xhdGlvbiBvZiBjYXBhY2l0 eSBjb25zdHJhaW50cyBhbmQgCiAgIHJlc3VsdGluZyBRb1MgZmFpbHVyZXMuIE91ciBzb2x1dGlv biB1c2VzIHJhdGUtYmFzZWQgZmxvdyBwcmUtCiAgIGVtcHRpb24sIHNvIHRoYXQgc3VmZmljaWVu dCBvZiB0aGUgcHJldmlvdXNseSBhZG1pdHRlZCBDTCBtaWNyb2Zsb3dzIAogICBhcmUgZHJvcHBl ZCB0byBlbnN1cmUgdGhhdCB0aGUgcmVtYWluaW5nIG9uZXMgYWdhaW4gcmVjZWl2ZSBRb1MgCiAg IGNvbW1lbnN1cmF0ZSB3aXRoIHRoZSBDTCBzZXJ2aWNlIGFuZCBhdCBsZWFzdCBzb21lIFFvUyBp cyBxdWlja2x5IAogICByZXN0b3JlZCB0byBvdGhlciB0cmFmZmljIGNsYXNzZXMuICAKCjMuMi4x LiBBbGVydGluZyBhbiBpbmdyZXNzIGdhdGV3YXkgdGhhdCBmbG93IHByZS1lbXB0aW9uIG1heSBi ZSBuZWVkZWQgCgogICBBbGVydGluZyBhbiBpbmdyZXNzIGdhdGV3YXkgdGhhdCBmbG93IHByZS1l bXB0aW9uIG1heSBiZSBuZWVkZWQgaXMgYSAKICAgdHdvIHN0YWdlIHByb2Nlc3M6IGEgcm91dGVy IGluIHRoZSBDTC1yZWdpb24gYWxlcnRzIGFuIGVncmVzcyBnYXRld2F5IAogICB0aGF0IGZsb3cg cHJlLWVtcHRpb24gbWF5IGJlIG5lZWRlZDsgaW4gdHVybiB0aGUgZWdyZXNzIGdhdGV3YXkgCiAg IGFsZXJ0cyB0aGUgcmVsZXZhbnQgaW5ncmVzcyBnYXRld2F5LiBFdmVyeSByb3V0ZXIgaW4gdGhl IENMLXJlZ2lvbiAKICAgaGFzIHRoZSBhYmlsaXR5IHRvIGFsZXJ0IGVncmVzcyBnYXRld2F5cywg d2hpY2ggbWF5IGJlIGRvbmUgZWl0aGVyIAogICBleHBsaWNpdGx5IG9yIGltcGxpY2l0bHk6ICAK CiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAg ICAgICAgICAgW1BhZ2UgMjBdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1v ZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIG8gRXhwbGljaXQg LSB0aGUgcm91dGVyIHBlci1ob3AgYmVoYXZpb3VyIGlzIHN1cHBsZW1lbnRlZCB3aXRoIGEgbmV3 IAogICAgICBQcmUtZW1wdGlvbiBNYXJraW5nIGJlaGF2aW91ciwgd2hpY2ggaXMgb3V0bGluZWQg YmVsb3cuIFJlY2VwdGlvbiAKICAgICAgb2Ygc3VjaCBhIHBhY2tldCBieSB0aGUgZWdyZXNzIGdh dGV3YXkgYWxlcnRzIGl0IHRoYXQgcHJlLWVtcHRpb24gCiAgICAgIG1heSBiZSBuZWVkZWQuIAoK ICAgbyBJbXBsaWNpdCAtIHRoZSByb3V0ZXIgYmVoYXZpb3VyIGlzIHVuY2hhbmdlZCBmcm9tIHRo ZSBBZG1pc3Npb24gCiAgICAgIE1hcmtpbmcgYmVoYXZpb3VyIGRlc2NyaWJlZCBlYXJsaWVyLiBU aGUgZWdyZXNzIGdhdGV3YXkgdHJlYXRzIGEgCiAgICAgIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1h dGUgb2YgKGFsbW9zdCkgMTAwJSBhcyBhbiBpbXBsaWNpdCBhbGVydCAKICAgICAgdGhhdCBwcmUt ZW1wdGlvbiBtYXkgYmUgcmVxdWlyZWQuICgnQWxtb3N0JyBiZWNhdXNlIHRoZSAKICAgICAgQ29u Z2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZSBpcyBhIG1vdmluZyBhdmVyYWdlLCBzbyBjYW4gbmV2ZXIg cmVhY2ggCiAgICAgIGV4YWN0bHkgMTAwJS4pIAoKICAgVG8gc3VwcG9ydCBleHBsaWNpdCBwcmUt ZW1wdGlvbiBhbGVydGluZywgZWFjaCByb3V0ZXIgaW4gdGhlIENMLQogICByZWdpb24gcnVucyBh biBhbGdvcml0aG0gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdG8gUHJlLWVtcHRpb24gTWFyayB0aGUg CiAgIHBhY2tldC4gVGhlIGFsZ29yaXRobSBtZWFzdXJlcyB0aGUgYWdncmVnYXRlIENMIHRyYWZm aWMgYW5kIGVuc3VyZXMgCiAgIHRoYXQgcGFja2V0cyBhcmUgcHJlLWVtcHRpb24gbWFya2VkIGJl Zm9yZSB0aGUgYWN0dWFsIHF1ZXVlIGJ1aWxkcyAKICAgdXAuIFRoZSBhbGdvcml0aG0ncyBtYWlu IHBhcmFtZXRlciBpcyB0aGUgY29uZmlndXJlZC1wcmUtZW1wdGlvbi0KICAgcmF0ZSwgd2hpY2gg aXMgc2V0IGxvd2VyIHRoYW4gdGhlIGxpbmsgc3BlZWQgKGJ1dCBoaWdoZXIgdGhhbiB0aGUgCiAg IGNvbmZpZ3VyZWQtYWRtaXNzaW9uLXJhdGUpLiBUaHVzIHByZS1lbXB0aW9uIG1hcmtlZCBwYWNr ZXRzIGluZGljYXRlIAogICB0aGF0IHRoZSBDTCB0cmFmZmljIHJhdGUgaXMgcmVhY2hpbmcgdGhl IGNvbmZpZ3VyZWQtcHJlLWVtcHRpb24tcmF0ZSAKICAgYW5kIHNvIGFjdCBhcyBhbiAiZWFybHkg d2FybmluZyIgdGhhdCB0aGUgZW5naW5lZXJlZCBjYXBhY2l0eSBpcyAKICAgbmVhcmx5IHJlYWNo ZWQuIFRoZXJlZm9yZSB0aGV5IGluZGljYXRlIHRoYXQgaXQgbWF5IGJlIGFkdmlzYWJsZSB0byAK ICAgcHJlLWVtcHQgc29tZSBvZiB0aGUgZXhpc3RpbmcgQ0wgZmxvd3MgaW4gb3JkZXIgdG8gcHJl c2VydmUgdGhlIFFvUyAKICAgb2YgdGhlIG90aGVycy4gCgogICBOb3RlIHRoYXQgdGhlIHByZS1l bXB0aW9uIG1hcmtpbmcgYWxnb3JpdGhtIGRvZXNuJ3QgbWVhc3VyZSB0aGUgCiAgIHBhY2tldHMg dGhhdCBhcmUgYWxyZWFkeSBQcmUtZW1wdGlvbiBNYXJrZWQuIFRoaXMgZW5zdXJlcyB0aGF0IGlu IGEgCiAgIHNjZW5hcmlvIHdpdGggc2V2ZXJhbCBsaW5rcyB0aGF0IGFyZSBhYm92ZSB0aGVpciBj b25maWd1cmVkLXByZS0KICAgZW1wdGlvbi1yYXRlLCB0aGVuIGF0IHRoZSBlZ3Jlc3MgZ2F0ZXdh eSB0aGUgcmF0ZSBvZiBwYWNrZXRzIAogICBleGNsdWRpbmcgUHJlLWVtcHRpb24gTWFya2VkIG9u ZXMgdHJ1bHkgZG9lcyByZXByZXNlbnQgdGhlIAogICBTdXN0YWluYWJsZS1BZ2dyZWdhdGUtUmF0 ZShzZWUgYmVsb3cgZm9yIGV4cGxhbmF0aW9uKS4gCgogICBOb3RlIHRoYXQgdGhlIGV4cGxpY2l0 IG1lY2hhbmlzbSBvbmx5IG1ha2VzIHNlbnNlIGlmIGFsbCB0aGUgcm91dGVycyAKICAgaW4gdGhl IENMLXJlZ2lvbiBoYXZlIHRoZSBmdW5jdGlvbmFsaXR5IHNvIHRoYXQgdGhlIGVncmVzcyBnYXRl d2F5cyAKICAgY2FuIHJlbHkgb24gdGhlIGV4cGxpY2l0IG1lY2hhbmlzbS4gT3RoZXJ3aXNlIHRo ZXJlIGlzIHRoZSBkYW5nZXIgCiAgIHRoYXQgdGhlIHRyYWZmaWMgaGFwcGVucyB0byBmb2N1cyBv biBhIHJvdXRlciB3aXRob3V0IGl0LCBhbmQgZWdyZXNzIAogICBnYXRld2F5cyB0aGVuIGhhdmUg YWxzbyB0byB3YXRjaCBmb3IgaW1wbGljaXQgcHJlLWVtcHRpb24gYWxlcnRzLiAKCiAgIFdoZW4g b25lIG9yIG1vcmUgcGFja2V0cyBpbiBhIENMLXJlZ2lvbi1hZ2dyZWdhdGUgYWxlcnQgdGhlIGVn cmVzcyAKICAgZ2F0ZXdheSBvZiB0aGUgbmVlZCBmb3IgZmxvdyBwcmUtZW1wdGlvbiwgd2hldGhl ciBleHBsaWNpdGx5IG9yIAogICBpbXBsaWNpdGx5LCB0aGUgZWdyZXNzIHB1dHMgdGhhdCBDTC1y ZWdpb24tYWdncmVnYXRlIGludG8gdGhlIFByZS0KICAgZW1wdGlvbiBBbGVydCBzdGF0ZS4gRm9y IGVhY2ggQ0wtcmVnaW9uLWFnZ3JlZ2F0ZSBpbiBhbGVydCBzdGF0ZSBpdCAKICAgbWVhc3VyZXMg dGhlIHJhdGUgb2YgdHJhZmZpYyBhdCB0aGUgZWdyZXNzIGdhdGV3YXkgKGkuZS4gdGhlIHRyYWZm aWMgCiAgIHJhdGUgb2YgdGhlIGFwcHJvcHJpYXRlIENMLXJlZ2lvbi1hZ2dyZWdhdGUpIGFuZCBy ZXBvcnRzIHRoaXMgdG8gdGhlIAogICByZWxldmFudCBpbmdyZXNzIGdhdGV3YXkuIFRoZSBzdGVw cyBhcmU6IAoKCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgMjFdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBs b3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIG8g RGV0ZXJtaW5lIHRoZSByZWxldmFudCBpbmdyZXNzIGdhdGV3YXkgLSBmb3IgdGhlIGV4cGxpY2l0 IGNhc2UgdGhlIAogICAgICBlZ3Jlc3MgZ2F0ZXdheSBleGFtaW5lcyB0aGUgcHJlLWVtcHRpb24g bWFya2VkIHBhY2tldCBhbmQgdXNlcyB0aGUgCiAgICAgIHN0YXRlIGluc3RhbGxlZCBhdCB0aGUg dGltZSBvZiBhZG1pc3Npb24gdG8gZGV0ZXJtaW5lIHdoaWNoIAogICAgICBpbmdyZXNzIGdhdGV3 YXkgdGhlIHBhY2tldCBjYW1lIGZyb20uIEZvciB0aGUgaW1wbGljaXQgY2FzZSB0aGUgCiAgICAg IGVncmVzcyBnYXRld2F5IGhhcyBhbHJlYWR5IGRldGVybWluZWQgdGhpcyBpbmZvcm1hdGlvbiwg YmVjYXVzZSAKICAgICAgdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgaXMgY2FsY3VsYXRl ZCBwZXIgaW5ncmVzcyBnYXRld2F5LiAKCiAgIG8gTWVhc3VyZSB0aGUgdHJhZmZpYyByYXRlIG9m IENMIHBhY2tldHMgLSBhcyBzb29uIGFzIHRoZSBlZ3Jlc3MgCiAgICAgIGdhdGV3YXkgaXMgYWxl cnRlZCAod2hldGhlciBleHBsaWNpdGx5IG9yIGltcGxpY2l0bHkpIGl0IG1lYXN1cmVzIAogICAg ICB0aGUgcmF0ZSBvZiBDTCB0cmFmZmljIGZyb20gdGhpcyBpbmdyZXNzIGdhdGV3YXkgKGkuZS4g Zm9yIHRoaXMgCiAgICAgIENMLXJlZ2lvbi1hZ2dyZWdhdGUpLiBOb3RlIHRoYXQgcHJlLWVtcHRp b24gbWFya2VkIHBhY2tldHMgYXJlIAogICAgICBleGNsdWRlZCBmcm9tIHRoYXQgbWVhc3VyZW1l bnQuIEl0IHNob3VsZCBtYWtlIGl0cyBtZWFzdXJlbWVudCAKICAgICAgcXVpY2tseSBhbmQgYWNj dXJhdGVseSwgYnV0IGV4YWN0bHkgaG93IGlzIHVwIHRvIHRoZSAKICAgICAgaW1wbGVtZW50YXRp b24uICAKCiAgIG8gQWxlcnQgdGhlIGluZ3Jlc3MgZ2F0ZXdheSAtIHRoZSBlZ3Jlc3MgZ2F0ZXdh eSB0aGVuIGltbWVkaWF0ZWx5IAogICAgICBhbGVydHMgdGhlIHJlbGV2YW50IGluZ3Jlc3MgZ2F0 ZXdheSBhYm91dCB0aGUgZmFjdCB0aGF0IGZsb3cgcHJlLQogICAgICBlbXB0aW9uIG1heSBiZSBy ZXF1aXJlZC4gVGhpcyBBbGVydCBtZXNzYWdlIGFsc28gaW5jbHVkZXMgdGhlIAogICAgICBtZWFz dXJlZCBTdXN0YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZSwgaS5lLiB0aGUgcmF0ZSBvZiBDTC10cmFm ZmljIAogICAgICByZWNlaXZlZCBmcm9tIHRoaXMgaW5ncmVzcyBnYXRld2F5LiBUaGUgQWxlcnQg bWVzc2FnZSBpcyBzZW50IAogICAgICB1c2luZyByZWxpYWJsZSBkZWxpdmVyeS4gUHJvY2VkdXJl cyBmb3IgdGhlIHN1cHBvcnQgb2Ygc3VjaCBhbiAKICAgICAgQWxlcnQgdXNpbmcgUlNWUCBhcmUg ZGVmaW5lZCBpbiBbUlNWUC1QQ05dLiAKCiAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAg ICBfICAgICAgIF8gICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0gICAgIApDTCBwYWNrZXQgICB8 VXBkYXRlICAgICAgICB8ICAgICAvIElzIGl0IGEgXCAgIFkgICAgfCBNZWFzdXJlIENMIHJhdGUg fCAKYXJyaXZlcyAtLS0+fENvbmdlc3Rpb24tICAgfC0tLT4vcHJlLWVtcHRpb25cLS0tLS0+IHwg ZnJvbSBpbmdyZXNzIGFuZHwgCiAgICAgICAgICAgIHxMZXZlbC1Fc3RpbWF0ZXwgICAgXCAgbWFy a2VkICAgLyAgICAgICB8IGFsZXJ0IGluZ3Jlc3MgICB8IAogICAgICAgICAgICAgLS0tLS0tLS0t LS0tLS0gICAgICBcIHBhY2tldD8gLyAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXF8gICAgIF8vIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKRmlndXJlIDI6IEVncmVzcyBnYXRld2F5IGFjdGlvbiBmb3IgZXhw bGljaXQgUHJlLWVtcHRpb24gQWxlcnQgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF8gICAgIF8gICAgICAgICAgCiAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAv ICAgICAgIFwgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0gICAgIApDTCBwYWNrZXQgICB8VXBk YXRlICAgICAgICB8ICAgICAvICBJcyAgICAgXCAgIFkgICAgfCBNZWFzdXJlIENMIHJhdGUgfCAK YXJyaXZlcyAtLS0+fENvbmdlc3Rpb24tICAgfC0tLT4vICBDLkwuRS4gICBcLS0tLS0+IHwgZnJv bSBpbmdyZXNzIGFuZHwgCiAgICAgICAgICAgIHxMZXZlbC1Fc3RpbWF0ZXwgICAgXCAobmVhcmx5 KSAgLyAgICAgICB8IGFsZXJ0IGluZ3Jlc3MgICB8IAogICAgICAgICAgICAgLS0tLS0tLS0tLS0t LS0gICAgICBcIDEwMCU/ICAgLyAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgXF8gICAgIF8vICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAKRmlndXJlIDM6IEVncmVzcyBnYXRld2F5IGFjdGlvbiBmb3IgaW1wbGljaXQgUHJl LWVtcHRpb24gQWxlcnQgIAogCiAKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDIyXSAKDApJbnRlcm5ldC1EcmFm dCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2 IAogICAgCgozLjIuMi4gRGV0ZXJtaW5pbmcgdGhlIHJpZ2h0IGFtb3VudCBvZiBDTCB0cmFmZmlj IHRvIGRyb3AgCgogICBUaGUgbWV0aG9kIHJlbGllcyBvbiB0aGUgaW5zaWdodCB0aGF0IHRoZSBh bW91bnQgb2YgQ0wgdHJhZmZpYyB0aGF0IAogICBjYW4gYmUgc3VwcG9ydGVkIGJldHdlZW4gYSBw YXJ0aWN1bGFyIHBhaXIgb2YgaW5ncmVzcyBhbmQgZWdyZXNzIAogICBnYXRld2F5cywgaXMgdGhl IGFtb3VudCBvZiBDTCB0cmFmZmljIHRoYXQgaXMgYWN0dWFsbHkgZ2V0dGluZyBhY3Jvc3MgCiAg IHRoZSBDTC1yZWdpb24gdG8gdGhlIGVncmVzcyBnYXRld2F5IHdpdGhvdXQgYmVpbmcgUHJlLWVt cHRpb24gTWFya2VkLiAKICAgSGVuY2Ugd2UgdGVybSBpdCB0aGUgU3VzdGFpbmFibGUtQWdncmVn YXRlLVJhdGUuIAoKICAgU28gd2hlbiB0aGUgaW5ncmVzcyBnYXRld2F5IGdldHMgdGhlIEFsZXJ0 IG1lc3NhZ2UgZnJvbSBhbiBlZ3Jlc3MgCiAgIGdhdGV3YXksIGl0IGNvbXBhcmVzOiAKCiAgIG8g VGhlIHRyYWZmaWMgcmF0ZSB0aGF0IGl0IGlzIHNlbmRpbmcgdG8gdGhpcyBwYXJ0aWN1bGFyIGVn cmVzcyAKICAgICAgZ2F0ZXdheSAod2hpY2ggd2UgdGVybSBJbmdyZXNzLUFnZ3JlZ2F0ZS1SYXRl KSAKCiAgIG8gVGhlIHRyYWZmaWMgcmF0ZSB0aGF0IHRoZSBlZ3Jlc3MgZ2F0ZXdheSByZXBvcnRz IChpbiB0aGUgQWxlcnQgCiAgICAgIG1lc3NhZ2UpIHRoYXQgaXQgaXMgcmVjZWl2aW5nIGZyb20g dGhpcyBpbmdyZXNzIGdhdGV3YXkgKHdoaWNoIGlzIAogICAgICB0aGUgU3VzdGFpbmFibGUtQWdn cmVnYXRlLVJhdGUpIAoKICAgSWYgdGhlIGRpZmZlcmVuY2UgaXMgc2lnbmlmaWNhbnQsIHRoZW4g dGhlIGluZ3Jlc3MgZ2F0ZXdheSBwcmUtZW1wdHMgCiAgIHNvbWUgbWljcm9mbG93cy4gSXQgb25s eSBwcmUtZW1wdHMgaWY6IAoKICAgICAgICBJbmdyZXNzLUFnZ3JlZ2F0ZS1SYXRlID4gU3VzdGFp bmFibGUtQWdncmVnYXRlLVJhdGUgKyBlcnJvciAKCiAgIFRoZSAiZXJyb3IiIHRlcm0gaXMgcGFy dGx5IHRvIGFsbG93IGZvciBpbmFjY3VyYWNpZXMgaW4gdGhlIAogICBtZWFzdXJlbWVudHMgb2Yg dGhlIHJhdGVzLiBJdCBpcyBhbHNvIG5lZWRlZCBiZWNhdXNlIHRoZSBJbmdyZXNzLQogICBBZ2dy ZWdhdGUtUmF0ZSBpcyBtZWFzdXJlZCBhdCBhIHNsaWdodGx5IGxhdGVyIG1vbWVudCB0aGFuIHRo ZSAKICAgU3VzdGFpbmFibGUtQWdncmVnYXRlLVJhdGUsIGFuZCBpdCBpcyBxdWl0ZSBwb3NzaWJs ZSB0aGF0IHRoZSAKICAgSW5ncmVzcy1BZ2dyZWdhdGUtUmF0ZSBoYXMgaW5jcmVhc2VkIGluIHRo ZSBpbnRlcmltIGR1ZSB0byBuYXR1cmFsIAogICB2YXJpYXRpb24gb2YgdGhlIGJpdCByYXRlIG9m IHRoZSBDTCBzb3VyY2VzLiBTbyB0aGUgImVycm9yIiB0ZXJtIAogICBhbGxvd3MgZm9yIHNvbWUg dmFyaWF0aW9uIGluIHRoZSBpbmdyZXNzIHJhdGUgd2l0aG91dCB0cmlnZ2VyaW5nIHByZS0KICAg ZW1wdGlvbi4gIAoKICAgVGhlIGluZ3Jlc3MgZ2F0ZXdheSBzaG91bGQgcHJlLWVtcHQgZW5vdWdo IG1pY3JvZmxvd3MgdG8gZW5zdXJlIHRoYXQ6IAoKICAgICAgICBOZXcgSW5ncmVzcy1BZ2dyZWdh dGUtUmF0ZSA8IFN1c3RhaW5hYmxlLUFnZ3JlZ2F0ZS1SYXRlIC0gZXJyb3IgCgogICBUaGUgImVy cm9yIiB0ZXJtIGhlcmUgaXMgdXNlZCBmb3Igc2ltaWxhciByZWFzb25zIGJ1dCBpbiB0aGUgb3Ro ZXIgCiAgIGRpcmVjdGlvbiwgdG8gZW5zdXJlIHNsaWdodGx5IG1vcmUgbG9hZCBpcyBzaGVkIHRo YW4gc2VlbXMgbmVjZXNzYXJ5LCAKICAgaW4gY2FzZSB0aGUgdHdvIG1lYXN1cmVtZW50cyB3ZXJl IHRha2VuIGR1cmluZyBhIHNob3J0LXRlcm0gZmFsbCBpbiAKICAgbG9hZC4gIAoKICAgV2hlbiB0 aGUgcm91dGVycyBpbiB0aGUgQ0wtcmVnaW9uIGFyZSB1c2luZyBleHBsaWNpdCBwcmUtZW1wdGlv biAKICAgYWxlcnRpbmcsIHRoZSBpbmdyZXNzIGdhdGV3YXkgd291bGQgbm9ybWFsbHkgcHJlLWVt cHQgbWljcm9mbG93cyAKICAgd2hlbmV2ZXIgaXQgZ2V0cyBhbiBhbGVydCAoaXQgYWx3YXlzIHdv dWxkIGlmIGl0IHdlcmUgcG9zc2libGUgdG8gc2V0IAogICAiZXJyb3IiIGVxdWFsIHRvIHplcm8p LiBGb3IgdGhlIGltcGxpY2l0IGNhc2UgaG93ZXZlciB0aGlzIGlzIG5vdCBzby4gCiAgIEl0IHJl Y2VpdmVzIGFuIEFsZXJ0IG1lc3NhZ2Ugd2hlbiB0aGUgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0 ZSAKICAgcmVhY2hlcyAoYWxtb3N0KSAxMDAlLCB3aGljaCBpcyByb3VnaGx5IHdoZW4gdHJhZmZp YyBleGNlZWRzIHRoZSAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAy NSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAyM10gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg IERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoK ICAgY29uZmlndXJlZC1hZG1pc3Npb24tcmF0ZS4gSG93ZXZlciwgaXQgaXMgb25seSB3aGVuIHBh Y2tldHMgYXJlIAogICBpbmRlZWQgZHJvcHBlZCBlbiByb3V0ZSB0aGF0IHRoZSBTdXN0YWluYWJs ZS1BZ2dyZWdhdGUtUmF0ZSBiZWNvbWVzIAogICBsZXNzIHRoYW4gdGhlIEluZ3Jlc3MtQWdncmVn YXRlLVJhdGUgc28gb25seSB0aGVuIHdpbGwgcHJlLWVtcHRpb24gCiAgIGFjdHVhbGx5IG9jY3Vy IG9uIHRoZSBpbmdyZXNzIGdhdGV3YXkuICAgCgogICBIZW5jZSB3aXRoIHRoZSBpbXBsaWNpdCBz Y2hlbWUsIHByZS1lbXB0aW9uIGNhbiBvbmx5IGJlIHRyaWdnZXJlZCAKICAgb25jZSB0aGUgc3lz dGVtIHN0YXJ0cyBkcm9wcGluZyBwYWNrZXRzIGFuZCB0aHVzIHRoZSBRb1Mgb2YgZmxvd3MgCiAg IHN0YXJ0cyBiZWluZyBzaWduaWZpY2FudGx5IGRlZ3JhZGVkLiBUaGlzIGlzIGluIGNvbnRyYXN0 IHdpdGggdGhlIAogICBleHBsaWNpdCBzY2hlbWUgd2hpY2ggYWxsb3dzIGZsb3cgcHJlLWVtcHRp b24gdG8gYmUgdHJpZ2dlcmVkIGJlZm9yZSAKICAgYW55IHBhY2tldCBkcm9wLCBzaW1wbHkgd2hl biB0aGUgdHJhZmZpYyByZWFjaGVzIHRoZSBjb25maWd1cmVkLXByZS0KICAgZW1wdGlvbi1yYXRl LiBUaGVyZWZvcmUgd2UgYmVsaWV2ZSB0aGF0IHRoZSBleHBsaWNpdCBtZWNoYW5pc20gaXMgCiAg IHN1cGVyaW9yLiBIb3dldmVyIGl0IGRvZXMgcmVxdWlyZSBuZXcgZnVuY3Rpb25hbGl0eSBvbiBh bGwgdGhlIAogICByb3V0ZXJzIChhbHRob3VnaCB0aGlzIGlzIGxpdHRsZSBtb3JlIHRoYW4gYSBi dWxrIHRva2VuIGJ1Y2tldCAtIHNlZSAKICAgW1BDTl0gZm9yIGRldGFpbHMpLiAgCgogCgozLjIu My4gVXNlIGNhc2UgZm9yIGZsb3cgcHJlLWVtcHRpb24gIAoKICAgVG8gc2VlIGhvdyB0aGUgcGll Y2VzIG9mIHRoZSBzb2x1dGlvbiBmaXQgdG9nZXRoZXIgaW4gYSB1c2UgY2FzZSwgd2UgCiAgIGlt YWdpbmUgYSBzY2VuYXJpbyB3aGVyZSBtYW55IG1pY3JvZmxvd3MgaGF2ZSBhbHJlYWR5IGJlZW4g YWRtaXR0ZWQuIAogICBXZSBjb25maW5lIG91ciBkZXNjcmlwdGlvbiB0byB0aGUgZXhwbGljaXQg cHJlLWVtcHRpb24gbWVjaGFuaXNtLiBOb3cgCiAgIGFuIGludGVyaW9yIHJvdXRlciBpbiB0aGUg Q0wtcmVnaW9uIGZhaWxzLiBUaGUgbmV0d29yayBsYXllciByb3V0aW5nIAogICBwcm90b2NvbCBy ZS1yb3V0ZXMgcm91bmQgdGhlIHByb2JsZW0sIGJ1dCBhcyBhIGNvbnNlcXVlbmNlIHRyYWZmaWMg b24gCiAgIG90aGVyIGxpbmtzIGluY3JlYXNlcy4gSW4gZmFjdCBsZXQncyBhc3N1bWUgdGhlIHRy YWZmaWMgb24gb25lIGxpbmsgCiAgIG5vdyBleGNlZWRzIGl0cyBjb25maWd1cmVkLXByZS1lbXB0 aW9uLXJhdGUgYW5kIHNvIHRoZSByb3V0ZXIgcHJlLQogICBlbXB0aW9uIG1hcmtzIENMIHBhY2tl dHMuIFdoZW4gdGhlIGVncmVzcyBzZWVzIHRoZSBmaXJzdCBvbmUgb2YgdGhlIAogICBwcmUtZW1w dGlvbiBtYXJrZWQgcGFja2V0cyBpdCBpbW1lZGlhdGVseSBkZXRlcm1pbmVzIHdoaWNoIG1pY3Jv ZmxvdyAKICAgdGhpcyBwYWNrZXQgaXMgcGFydCBvZiAoYnkgdXNpbmcgYSBmaXZlLXR1cGxlIGZp bHRlciBhbmQgY29tcGFyaW5nIGl0IAogICB3aXRoIHN0YXRlIGluc3RhbGxlZCBhdCBhZG1pc3Np b24pIGFuZCBoZW5jZSB3aGljaCBpbmdyZXNzIGdhdGV3YXkgCiAgIHRoZSBwYWNrZXQgY2FtZSBm cm9tLiBJdCBzZXRzIHVwIGEgbWV0ZXIgdG8gbWVhc3VyZSB0aGUgdHJhZmZpYyByYXRlIAogICBm cm9tIHRoaXMgaW5ncmVzcyBnYXRld2F5LCBhbmQgYXMgc29vbiBhcyBwb3NzaWJsZSBzZW5kcyBh IG1lc3NhZ2UgdG8gCiAgIHRoZSBpbmdyZXNzIGdhdGV3YXkuIFRoaXMgbWVzc2FnZSBhbGVydHMg dGhlIGluZ3Jlc3MgZ2F0ZXdheSB0aGF0IAogICBwcmUtZW1wdGlvbiBtYXkgYmUgbmVlZGVkIGFu ZCBjb250YWlucyB0aGUgdHJhZmZpYyByYXRlIG1lYXN1cmVkIGJ5IAogICB0aGUgZWdyZXNzIGdh dGV3YXkuIFRoZW4gdGhlIGluZ3Jlc3MgZ2F0ZXdheSBkZXRlcm1pbmVzIHRoZSB0cmFmZmljIAog ICByYXRlIHRoYXQgaXQgaXMgc2VuZGluZyB0b3dhcmRzIHRoaXMgZWdyZXNzIGdhdGV3YXkgYW5k IGhlbmNlIGl0IGNhbiAKICAgY2FsY3VsYXRlIHRoZSBhbW91bnQgb2YgdHJhZmZpYyB0aGF0IG5l ZWRzIHRvIGJlIHByZS1lbXB0ZWQuICAKCiAgIFRoZSBzb2x1dGlvbiBvcGVyYXRlcyB3aXRoaW4g YSBsaXR0bGUgb3ZlciBvbmUgcm91bmQgdHJpcCB0aW1lIC0gdGhlIAogICB0aW1lIHJlcXVpcmVk IGZvciBtaWNyb2Zsb3cgcGFja2V0cyB0aGF0IGhhdmUgZXhwZXJpZW5jZWQgUHJlLWVtcHRpb24g CiAgIE1hcmtpbmcgdG8gdHJhdmVsIGRvd25zdHJlYW0gdGhyb3VnaCB0aGUgQ0wtcmVnaW9uIGFu ZCBhcnJpdmUgYXQgdGhlIAogICBlZ3Jlc3MgZ2F0ZXdheSwgcGx1cyBzb21lIGFkZGl0aW9uYWwg dGltZSBmb3IgdGhlIGVncmVzcyBnYXRld2F5IHRvIAogICBtZWFzdXJlIHRoZSByYXRlIHNlZW4g YWZ0ZXIgaXQgaGFzIGJlZW4gYWxlcnRlZCB0aGF0IHByZS1lbXB0aW9uIG1heSAKICAgYmUgbmVl ZGVkLCBhbmQgdGhlIHRpbWUgZm9yIHRoZSBlZ3Jlc3MgZ2F0ZXdheSB0byByZXBvcnQgdGhpcyAK ICAgaW5mb3JtYXRpb24gdG8gdGhlIGluZ3Jlc3MgZ2F0ZXdheS4gIAoKCiAKIApCcmlzY29lICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2Ug MjRdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAg ICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIFRoZSBpbmdyZXNzIGdhdGV3YXkgY291bGQg bm93IGp1c3Qgc2hlZCByYW5kb20gbWljcm9mbG93cywgYnV0IGl0IGlzIAogICBiZXR0ZXIgaWYg dGhlIGxlYXN0IGltcG9ydGFudCBvbmVzIGFyZSBkcm9wcGVkLiBUaGUgaW5ncmVzcyBnYXRld2F5 IAogICBjb3VsZCB1c2UgaW5mb3JtYXRpb24gc3RvcmVkIGxvY2FsbHkgaW4gZWFjaCByZXNlcnZh dGlvbidzIHN0YXRlIAogICAoc3VjaCBhcyBmb3IgZXhhbXBsZSB0aGUgUlNWUCBwcmUtZW1wdGlv biBwcmlvcml0eSBvZiBbUlNWUC0KICAgUFJFRU1QVElPTl0gb3IgdGhlIFJTVlAgYWRtaXNzaW9u IHByaW9yaXR5IG9mIFtSU1ZQLUVNRVJHRU5DWV0pIGFzIAogICB3ZWxsIGFzIGluZm9ybWF0aW9u IHByb3ZpZGVkIGJ5IGEgcG9saWN5IGRlY2lzaW9uIHBvaW50IGluIG9yZGVyIHRvIAogICBkZWNp ZGUgd2hpY2ggb2YgdGhlIGZsb3dzIHRvIHNoZWQgKG9yIHBlcmhhcHMgd2hpY2ggb25lcyBub3Qg dG8gCiAgIHNoZWQpLiBUaGlzIHdheSwgZmxvdyBwcmUtZW1wdGlvbiBjYW4gYWxzbyBoZWxwcyBl bWVyZ2VuY3kvbWlsaXRhcnkgCiAgIGNhbGxzIGJ5IHRha2luZyBpbnRvIGFjY291bnQgdGhlIGNv cnJlc3BvbmRpbmcgcHJpb3JpdGllcyAoYXMgCiAgIGNvbnZleWVkIGluIFJTVlAgcG9saWN5IGVs ZW1lbnRzKSB3aGVuIHNlbGVjdGluZyBjYWxscyB0byBiZSBwcmUtCiAgIGVtcHRlZCwgd2hpY2gg aXMgbGlrZWx5IHRvIGJlIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgaW4gYSBkaXNhc3RlciAKICAg c2NlbmFyaW8uIFVzZSBvZiBSU1ZQIGZvciBzdXBwb3J0IG9mIGVtZXJnZW5jeS9taWxpdGFyeSBh cHBsaWNhdGlvbnMgCiAgIGlzIGRpc2N1c3NlZCBpbiBmdXJ0aGVyIGRldGFpbHMgaW4gW1JGQzQ1 NDJdIGFuZCBbUlNWUC1FTUVSR0VOQ1ldLiAKCiAgIFRoZSBpbmdyZXNzIGdhdGV3YXkgdGhlbiBp bml0aWF0ZXMgUlNWUCBzaWduYWxsaW5nIHRvIGluc3RydWN0IHRoZSAKICAgcmVsZXZhbnQgZGVz dGluYXRpb25zIHRoYXQgdGhlaXIgcmVzZXJ2YXRpb24gaGFzIGJlZW4gdGVybWluYXRlZCwgYW5k IAogICB0byB0ZWxsIChSU1ZQKSBub2RlcyBhbG9uZyB0aGUgcGF0aCB0byB0ZWFyIGRvd24gYXNz b2NpYXRlZCBSU1ZQIAogICBzdGF0ZS4gVG8gZ3VhcmQgYWdhaW5zdCByZWNhbGNpdHJhbnQgc291 cmNlcywgbm9ybWFsIEludFNlcnYgcG9saWNpbmcgCiAgIG1heSBiZSB1c2VkIHRvIGJsb2NrIGFu eSBmdXR1cmUgdHJhZmZpYyBmcm9tIHRoZSBkcm9wcGVkIGZsb3dzIGZyb20gCiAgIGVudGVyaW5n IHRoZSBDTC1yZWdpb24uIE5vdGUgdGhhdCAtIHdpdGggdGhlIGV4cGxpY2l0IFByZS1lbXB0aW9u IAogICBBbGVydCBtZWNoYW5pc20gLSBzaW5jZSB0aGUgY29uZmlndXJlZC1wcmUtZW1wdGlvbi1y YXRlIG1heSBiZSAKICAgc2lnbmlmaWNhbnRseSBsZXNzIHRoYW4gdGhlIHBoeXNpY2FsIGxpbmUg Y2FwYWNpdHksIGZsb3cgcHJlLWVtcHRpb24gCiAgIG1heSBiZSB0cmlnZ2VyZWQgYmVmb3JlIGFu eSBjb25nZXN0aW9uIGhhcyBhY3R1YWxseSBvY2N1cnJlZCBhbmQgCiAgIGJlZm9yZSBhbnkgcGFj a2V0IGlzIGRyb3BwZWQuIAoKICAgV2UgZXh0ZW5kIHRoZSBzY2VuYXJpbyBmdXJ0aGVyIGJ5IGlt YWdpbmluZyB0aGF0IChkdWUgdG8gYSBkaXNhc3RlciAKICAgb2Ygc29tZSBraW5kKSBmdXJ0aGVy IHJvdXRlcnMgaW4gdGhlIENMLXJlZ2lvbiBmYWlsIGR1cmluZyB0aGUgdGltZSAKICAgdGFrZW4g YnkgdGhlIHByZS1lbXB0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGFib3ZlLiBUaGlzIGlzIGhhbmRs ZWQgCiAgIG5hdHVyYWxseSwgYXMgcGFja2V0cyB3aWxsIGNvbnRpbnVlIHRvIGJlIHByZS1lbXB0 aW9uIG1hcmtlZCBhbmQgc28gCiAgIHRoZSBwcmUtZW1wdGlvbiBwcm9jZXNzIHdpbGwgaGFwcGVu IGZvciBhIHNlY29uZCB0aW1lLiAgCgogICAgCgozLjMuIEJvdGggYWRtaXNzaW9uIGNvbnRyb2wg YW5kIHByZS1lbXB0aW9uIAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYm90aCB0aGUgYWRt aXNzaW9uIGNvbnRyb2wgYW5kIHByZS1lbXB0aW9uIAogICBtZWNoYW5pc21zLCBhbmQgd2Ugc3Vn Z2VzdCB0aGF0IGFuIG9wZXJhdG9yIHVzZXMgYm90aC4gSG93ZXZlciwgd2UgZG8gCiAgIG5vdCBy ZXF1aXJlIHRoaXMgYW5kIHNvbWUgb3BlcmF0b3JzIG1heSB3YW50IHRvIGltcGxlbWVudCBvbmx5 IG9uZS4gIAoKICAgRm9yIGV4YW1wbGUsIGFuIG9wZXJhdG9yIGNvdWxkIHVzZSBqdXN0IGFkbWlz c2lvbiBjb250cm9sLCBzb2x2aW5nIAogICBoZWF2eSBjb25nZXN0aW9uIChjYXVzZWQgYnkgcmUt cm91dGluZykgYnkgJ2p1c3Qgd2FpdGluZycgLSBhcyAKICAgc2Vzc2lvbnMgZW5kLCBleGlzdGlu ZyBtaWNyb2Zsb3dzIG5hdHVyYWxseSBkZXBhcnQgZnJvbSB0aGUgc3lzdGVtIAogICBvdmVyIHRp bWUsIGFuZCB0aGUgYWRtaXNzaW9uIGNvbnRyb2wgbWVjaGFuaXNtIHdpbGwgcHJldmVudCBhZG1p c3Npb24gCiAgIG9mIG5ldyBtaWNyb2Zsb3dzIHRoYXQgdXNlIHRoZSBhZmZlY3RlZCBsaW5rcy4g U28gdGhlIENMLXJlZ2lvbiB3aWxsIAogICBuYXR1cmFsbHkgcmV0dXJuIHRvIG5vcm1hbCBjb250 cm9sbGVkIGxvYWQgc2VydmljZSwgYnV0IHdpdGggcmVkdWNlZCAKICAgY2FwYWNpdHkuIFRoZSBk cmF3YmFjayBvZiB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHRoYXQgdW50aWwgZmxvd3MgCiAgIG5h dHVyYWxseSBkZXBhcnQgdG8gcmVsaWV2ZSB0aGUgY29uZ2VzdGlvbiwgYWxsIGZsb3dzIGFuZCBs b3dlciAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAg ICAgICAgICAgICAgICBbUGFnZSAyNV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1l bnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgcHJpb3Jp dHkgc2VydmljZXMgd2lsbCBiZSBhZHZlcnNlbHkgYWZmZWN0ZWQuIEFzIGFub3RoZXIgZXhhbXBs ZSwgYW4gCiAgIG9wZXJhdG9yIGNvdWxkIHVzZSBqdXN0IGFkbWlzc2lvbiBjb250cm9sLCBhdm9p ZGluZyBoZWF2eSBjb25nZXN0aW9uIAogICAoY2F1c2VkIGJ5IHJlLXJvdXRpbmcpIGJ5ICdjYXBh Y2l0eSBwbGFubmluZycgLSBieSBjb25maWd1cmluZyAKICAgYWRtaXNzaW9uIGNvbnRyb2wgdGhy ZXNob2xkcyB0byBsb3dlciBsZXZlbHMgdGhhbiB0aGUgbmV0d29yayBjb3VsZCAKICAgYWNjZXB0 IGluIG5vcm1hbCBzaXR1YXRpb25zIHN1Y2ggdGhhdCB0aGUgbG9hZCBhZnRlciBmYWlsdXJlIGlz IAogICBleHBlY3RlZCB0byBzdGF5IGJlbG93IGFjY2VwdGFibGUgbGV2ZWxzIGV2ZW4gd2l0aCBy ZWR1Y2VkIG5ldHdvcmsgCiAgIHJlc291cmNlcy4gCgogICBPbiB0aGUgb3RoZXIgaGFuZCwgYW4g b3BlcmF0b3IgY291bGQganVzdCByZWx5IGZvciBhZG1pc3Npb24gY29udHJvbCAKICAgb24gdGhl IHRyYWZmaWMgY29uZGl0aW9uaW5nIGFncmVlbWVudHMgb2YgdGhlIERpZmZTZXJ2IGFyY2hpdGVj dHVyZSAKICAgW1JGQzI0NzVdLiBUaGUgcHJlLWVtcHRpb24gbWVjaGFuaXNtIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50IHdvdWxkIAogICBiZSB1c2VkIHRvIGNvdW50ZXJhY3QgdGhlIHByb2Js ZW0gZGVzY3JpYmVkIGF0IHRoZSBlbmQgb2YgU2VjdGlvbiAKICAgMS4xLjEuIAoKICAgIAoKICAg IAoKICAgIAoKICAgIAoKICAgIAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiAKIApCcmlzY29lICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2Ug MjZdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAg ICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCjQuIFN1bW1hcnkgb2YgRnVuY3Rpb25hbGl0eSAK CiAgIFRoaXMgc2VjdGlvbiBpcyBpbnRlbmRlZCB0byBwcm92aWRlIGEgc3lzdGVtYXRpYyBzdW1t YXJ5IG9mIHRoZSBuZXcgCiAgIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgYnkgdGhlIHJvdXRlcnMg aW4gdGhlIENMLXJlZ2lvbi4gCgogICBBIG5ldHdvcmsgb3BlcmF0b3IgdXBncmFkZXMgbm9ybWFs IElQIHJvdXRlcnMgYnk6IAoKICAgbyBBZGRpbmcgZnVuY3Rpb25hbGl0eSByZWxhdGVkIHRvIGFk bWlzc2lvbiBjb250cm9sIGFuZCBmbG93IHByZS0KICAgICAgZW1wdGlvbiB0byBhbGwgaXRzIGlu Z3Jlc3MgYW5kIGVncmVzcyBnYXRld2F5cyAKCiAgIG8gQWRkaW5nIFByZS1Db25nZXN0aW9uIE5v dGlmaWNhdGlvbiBmb3IgQWRtaXNzaW9uIE1hcmtpbmcgYW5kIFByZS0KICAgICAgZW1wdGlvbiBN YXJraW5nIHRvIGFsbCB0aGUgcm91dGVycyBpbiB0aGUgQ0wtcmVnaW9uLiAKCiAgIFdlIGNvbnNp ZGVyIHRoZSBkZXRhaWxlZCBhY3Rpb25zIHJlcXVpcmVkIGZvciBlYWNoIG9mIHRoZSB0eXBlcyBv ZiAKICAgcm91dGVyIGluIHR1cm4uICAKCjQuMS4gSW5ncmVzcyBnYXRld2F5cyAKCiAgIEluZ3Jl c3MgZ2F0ZXdheXMgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHRhc2tzOiAKCiAgIG8gQ2xhc3NpZnkg aW5jb21pbmcgcGFja2V0cyAtIGRlY2lkZSB3aGV0aGVyIHRoZXkgYXJlIENMIG9yIG5vbi1DTCAK ICAgICAgcGFja2V0cy4gVGhpcyBpcyBkb25lIHVzaW5nIGFuIEludFNlcnYgZmlsdGVyIHNwZWMg KHNvdXJjZSBhbmQgCiAgICAgIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBhbmQgcG9ydCBudW1iZXJz KSwgd2hvc2UgZGV0YWlscyBoYXZlIGJlZW4gCiAgICAgIGdhdGhlcmVkIGZyb20gdGhlIFJTVlAg bWVzc2FnaW5nLiAKCiAgIG8gUG9saWNlIC0gY2hlY2sgdGhhdCB0aGUgbWljcm9mbG93IGNvbmZv cm1zIHdpdGggd2hhdCBoYXMgYmVlbiAKICAgICAgYWdyZWVkIChpLmUuIGl0IGtlZXBzIHRvIGl0 cyBhZ3JlZWQgZGF0YSByYXRlKS4gSWYgbmVjZXNzYXJ5LCAKICAgICAgcGFja2V0cyB3aGljaCBk byBub3QgY29ycmVzcG9uZCB0byBhbnkgcmVzZXJ2YXRpb25zLCBwYWNrZXRzIHdoaWNoIAogICAg ICBhcmUgaW4gZXhjZXNzIG9mIHRoZSByYXRlIGFncmVlZCBmb3IgdGhlaXIgcmVzZXJ2YXRpb24s IGFuZCAKICAgICAgcGFja2V0cyBmb3IgYSByZXNlcnZhdGlvbiB0aGF0IGhhcyBlYXJsaWVyIGJl ZW4gcHJlLWVtcHRlZCBtYXkgYmUgCiAgICAgIHBvbGljZWQuIFBvbGljaW5nIG1heSBiZSBhY2hp ZXZlZCB2aWEgZHJvcHBpbmcgb3IgdmlhIHJlLW1hcmtpbmcgCiAgICAgIG9mIHRoZSBwYWNrZXQn cyBEU0NQIHRvIGEgdmFsdWUgZGlmZmVyZW50IGZyb20gdGhlIENMIGJlaGF2aW91ciAKICAgICAg YWdncmVnYXRlLiAKCiAgIG8gRUNOIGNvbG91cmluZyBwYWNrZXRzIC0gZm9yIENMIG1pY3JvZmxv d3MsIHNldCB0aGUgRUNOIGZpZWxkIG9mIAogICAgICBwYWNrZXRzIGFwcHJvcHJpYXRlbHkgKHNl ZSBbUENOXSBmb3Igc29tZSBkaXNjdXNzaW9uIG9mIGVuY29kaW5nKS4gCgogICBvIFBlcmZvcm0g J2ludGVyaW9yIHJvdXRlcicgZnVuY3Rpb25zIChzZWUgbmV4dCBzdWItc2VjdGlvbikuIAoKICAg byBBZG1pc3Npb24gQ29udHJvbCAtIG9uIG5ldyBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIGNvbnNp ZGVyIHRoZSAKICAgICAgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZSByZWNlaXZlZCBmcm9tIHRo ZSBjb3JyZXNwb25kaW5nIGVncmVzcyAKICAgICAgZ2F0ZXdheSBhbmQgbW9zdCBsaWtlbHkgYmFz ZWQgb24gYSBzaW1wbGUgY29uZmlndXJlZCBDTEUtdGhyZXNob2xkIAogICAgICBkZWNpZGUgaWYg YSBuZXcgY2FsbCBpcyB0byBiZSBhZG1pdHRlZCBvciByZWplY3RlZCAodGFraW5nIGludG8gCiAg ICAgIGFjY291bnQgbG9jYWwgcG9saWN5IGluZm9ybWF0aW9uIGFzIHdlbGwgYXMgb3B0aW9uYWxs eSBpbmZvcm1hdGlvbiAKICAgICAgcHJvdmlkZWQgYnkgYSBwb2xpY3kgZGVjaXNpb24gcG9pbnQp LiAKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDI3XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVu dCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBvIFByb2Jl IC0gaWYgcmVxdWVzdGVkIGJ5IHRoZSBlZ3Jlc3MgZ2F0ZXdheSB0byBkbyBzbywgdGhlIGluZ3Jl c3MgCiAgICAgIGdhdGV3YXkgZ2VuZXJhdGVzIHByb2JlIHRyYWZmaWMgc28gdGhhdCB0aGUgZWdy ZXNzIGdhdGV3YXkgY2FuIAogICAgICBjb21wdXRlIHRoZSBDb25nZXN0aW9uLUxldmVsLUVzdGlt YXRlIGZyb20gdGhpcyBpbmdyZXNzIGdhdGV3YXkuIAogICAgICBQcm9iZSBwYWNrZXRzIG1heSBi ZSBzaW1wbGUgZGF0YSBhZGRyZXNzZWQgdG8gdGhlIGVncmVzcyBnYXRld2F5IAogICAgICBhbmQg cmVxdWlyZSBubyBwcm90b2NvbCBzdGFuZGFyZGlzYXRpb24sIGFsdGhvdWdoIHRoZXJlIHdpbGwg YmUgCiAgICAgIGJlc3QgcHJhY3RpY2UgZm9yIHRoZWlyIG51bWJlciwgc2l6ZSBhbmQgcmF0ZS4g CgogICBvIE1lYXN1cmUgLSB3aGVuIGl0IHJlY2VpdmVzIGEgUHJlLWVtcHRpb24gQWxlcnQgbWVz c2FnZSBmcm9tIGFuIAogICAgICBlZ3Jlc3MgZ2F0ZXdheSwgaXQgZGV0ZXJtaW5lcyB0aGUgcmF0 ZSBhdCB3aGljaCBpdCBpcyBzZW5kaW5nIAogICAgICBwYWNrZXRzIHRvIHRoYXQgZWdyZXNzIGdh dGV3YXkgCgogICBvIFByZS1lbXB0IC0gY2FsY3VsYXRlIGhvdyBtdWNoIENMIHRyYWZmaWMgbmVl ZHMgdG8gYmUgcHJlLWVtcHRlZDsgCiAgICAgIGRlY2lkZSB3aGljaCBtaWNyb2Zsb3dzIHNob3Vs ZCBiZSBkcm9wcGVkLCBwZXJoYXBzIGluIGNvbnN1bHRhdGlvbiAKICAgICAgd2l0aCBhIFBvbGlj eSBEZWNpc2lvbiBQb2ludDsgYW5kIGRvIHRoZSBuZWNlc3Nhcnkgc2lnbmFsbGluZyB0byAKICAg ICAgZHJvcCB0aGVtLiAKCjQuMi4gSW50ZXJpb3Igcm91dGVycyAKCiAgIEludGVyaW9yIHJvdXRl cnMgZG8gdGhlIGZvbGxvd2luZyB0YXNrczogCgogICBvIENsYXNzaWZ5IHBhY2tldHMgLSBleGFt aW5lIHRoZSBEU0NQIGFuZCBFQ04gZmllbGQgdG8gc2VlIGlmIGl0J3MgYSAKICAgICAgQ0wgcGFj a2V0IAoKICAgbyBOb24tQ0wgcGFja2V0cyBhcmUgaGFuZGxlZCBhcyB1c3VhbCwgd2l0aCByZXNw ZWN0IHRvIGRyb3BwaW5nIHRoZW0gCiAgICAgIG9yIHNldHRpbmcgdGhlaXIgQ0UgY29kZXBvaW50 LiAgCgogICBvIFByZS1Db25nZXN0aW9uIE5vdGlmaWNhdGlvbiAtIENMIHBhY2tldHMgYXJlIEFk bWlzc2lvbiBNYXJrZWQgYW5kIAogICAgICBQcmUtZW1wdGlvbiBNYXJrZWQgYWNjb3JkaW5nIHRv IHRoZSBhbGdvcml0aG0gZGV0YWlsZWQgaW4gW1BDTl0gCiAgICAgIGFuZCBvdXRsaW5lZCBpbiBT ZWN0aW9uIDMuIAoKIAoKNC4zLiBFZ3Jlc3MgZ2F0ZXdheXMgCgogICBFZ3Jlc3MgZ2F0ZXdheXMg ZG8gdGhlIGZvbGxvd2luZyB0YXNrczogCgogICBvIENsYXNzaWZ5IHBhY2tldHMgLSBkZXRlcm1p bmUgd2hpY2ggaW5ncmVzcyBnYXRld2F5IGEgQ0wgcGFja2V0IGhhcyAKICAgICAgY29tZSBmcm9t LiBUaGlzIGlzIHRoZSBwcmV2aW91cyBSU1ZQIGhvcCwgaGVuY2UgdGhlIG5lY2Vzc2FyeSAKICAg ICAgZGV0YWlscyBhcmUgb2J0YWluZWQganVzdCBhcyB3aXRoIEludFNlcnYgZnJvbSB0aGUgc3Rh dGUgCiAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgcGFja2V0IGZpdmUtdHVwbGUsIHdoaWNoIGhh cyBiZWVuIGJ1aWx0IHVzaW5nIAogICAgICBpbmZvcm1hdGlvbiBmcm9tIHRoZSBSU1ZQIG1lc3Nh Z2VzLiAKCgoKCgoKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSAyOF0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERl cGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAg byBNZXRlciAtIGZvciBDTCBwYWNrZXRzLCBjYWxjdWxhdGUgdGhlIGZyYWN0aW9uIG9mIHRoZSB0 b3RhbCBudW1iZXIgCiAgICAgIG9mIGJpdHMgd2hpY2ggYXJlIGluIEFkbWlzc2lvbiBtYXJrZWQg cGFja2V0cyBvciBpbiBQcmUtZW1wdGlvbiAKICAgICAgTWFya2VkIHBhY2tldHMuIFRoZSBjYWxj dWxhdGlvbiBpcyBkb25lIGFzIGFuIGV4cG9uZW50aWFsbHkgCiAgICAgIHdlaWdodGVkIG1vdmlu ZyBhdmVyYWdlIChzZWUgQXBwZW5kaXggQykuIEEgc2VwYXJhdGUgY2FsY3VsYXRpb24gCiAgICAg IGlzIG1hZGUgZm9yIENMIHBhY2tldHMgZnJvbSBlYWNoIGluZ3Jlc3MgZ2F0ZXdheS4gVGhlIG1l dGVyIHdvcmtzIAogICAgICBvbiBhbiBhZ2dyZWdhdGUgYmFzaXMgYW5kIG5vdCBwZXIgbWljcm9m bG93LiAKCiAgIG8gU2lnbmFsIHRoZSBDb25nZXN0aW9uLUxldmVsLUVzdGltYXRlIC0gdGhpcyBp cyBwaWdneS1iYWNrZWQgb24gdGhlIAogICAgICByZXNlcnZhdGlvbiByZXBseS4gQW4gZWdyZXNz IGdhdGV3YXkncyBpbnRlcmZhY2UgaXMgY29uZmlndXJlZCB0byAKICAgICAga25vdyBpdCBpcyBh biBlZ3Jlc3MgZ2F0ZXdheSwgc28gaXQgYWx3YXlzIGFwcGVuZHMgdGhpcyB0byB0aGUgCiAgICAg IFJFU1YgbWVzc2FnZS4gSWYgdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgaXMgdW5rbm93 biBvciBpcyAKICAgICAgdG9vIHN0YWxlLCB0aGVuIHRoZSBlZ3Jlc3MgZ2F0ZXdheSBjYW4gcmVx dWVzdCB0aGUgaW5ncmVzcyBnYXRld2F5IAogICAgICB0byBzZW5kIHByb2Jlcy4gIAoKICAgbyBQ YWNrZXQgY29sb3VyaW5nIC0gZm9yIENMIHBhY2tldHMsIHNldCB0aGUgRFNDUCBhbmQgdGhlIEVD TiBmaWVsZCAKICAgICAgdG8gd2hhdGV2ZXIgaGFzIGJlZW4gYWdyZWVkIGFzIGFwcHJvcHJpYXRl IGZvciB0aGUgbmV4dCBkb21haW4uIEJ5IAogICAgICBkZWZhdWx0IHRoZSBFQ04gZmllbGQgaXMg c2V0IHRvIHRoZSBOb3QtRUNUIGNvZGVwb2ludC4gU2VlIGFsc28gCiAgICAgIHRoZSBkaXNjdXNz aW9uIGluIHRoZSBUdW5uZWxsaW5nIHNlY3Rpb24gbGF0ZXIuICAKCiAgIG8gTWVhc3VyZSB0aGUg cmF0ZSAtIG1lYXN1cmUgdGhlIHJhdGUgb2YgQ0wgdHJhZmZpYyBmcm9tIGEgCiAgICAgIHBhcnRp Y3VsYXIgaW5ncmVzcyBnYXRld2F5LCBleGNsdWRpbmcgcGFja2V0cyB0aGF0IGFyZSBQcmUtZW1w dGlvbiAKICAgICAgTWFya2VkIChpLmUuIHRoZSBTdXN0YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZSBm b3IgdGhlIENMLXJlZ2lvbi0KICAgICAgYWdncmVnYXRlKSwgd2hlbiBhbGVydGVkIChlaXRoZXIg ZXhwbGljaXRseSBvciBpbXBsaWNpdGx5KSB0aGF0IAogICAgICBwcmUtZW1wdGlvbiBtYXkgYmUg cmVxdWlyZWQuIFRoZSBtZWFzdXJlZCByYXRlIGlzIHJlcG9ydGVkIGJhY2sgdG8gCiAgICAgIHRo ZSBhcHByb3ByaWF0ZSBpbmdyZXNzIGdhdGV3YXkgW1JTVlAtUENOXS4gIAoKNC40LiBGYWlsdXJl cyAgCgogICBJZiBhbiBpbnRlcmlvciByb3V0ZXIgZmFpbHMsIHRoZW4gdGhlIHJlZ3VsYXIgSVAg cm91dGluZyBwcm90b2NvbCAKICAgd2lsbCByZS1yb3V0ZSByb3VuZCBpdC4gSWYgdGhlIG5ldyBy b3V0ZSBjYW4gY2FycnkgYWxsIHRoZSBhZG1pdHRlZCAKICAgdHJhZmZpYywgZmxvd3Mgd2lsbCBn cmFjZWZ1bGx5IGNvbnRpbnVlLiBJZiBpbnN0ZWFkIHRoaXMgY2F1c2VzIGVhcmx5IAogICB3YXJu aW5nIG9mIHByZS1jb25nZXN0aW9uIG9uIHRoZSBuZXcgcm91dGUsIHRoZW4gYWRtaXNzaW9uIGNv bnRyb2wgCiAgIGJhc2VkIG9uIHByZS1jb25nZXN0aW9uIG5vdGlmaWNhdGlvbiB3aWxsIGVuc3Vy ZSBuZXcgZmxvd3Mgd2lsbCBub3QgCiAgIGJlIGFkbWl0dGVkIHVudGlsIGVub3VnaCBleGlzdGlu ZyBmbG93cyBoYXZlIGRlcGFydGVkLiBGaW5hbGx5IHJlLQogICByb3V0aW5nIG1heSByZXN1bHQg aW4gaGVhdnkgY29uZ2VzdGlvbiwgd2hlbiB0aGUgZmxvdyBwcmUtZW1wdGlvbiAKICAgbWVjaGFu aXNtIHdpbGwga2ljayBpbi4gIAoKICAgSWYgYSBnYXRld2F5IGZhaWxzIHRoZW4gd2Ugd291bGQg bGlrZSByZWd1bGFyIFJTVlAgcHJvY2VkdXJlcyAKICAgW1JGQzIyMDVdIHRvIHRha2UgY2FyZSBv ZiB0aGluZ3MuIFdpdGggdGhlIGxvY2FsIHJlcGFpciBtZWNoYW5pc20gb2YgCiAgIFtSRkMyMjA1 XSwgd2hlbiBhIHJvdXRlIGNoYW5nZXMgdGhlIG5leHQgUlNWUCBQQVRIIHJlZnJlc2ggbWVzc2Fn ZSAKICAgd2lsbCBlc3RhYmxpc2ggcGF0aCBzdGF0ZSBhbG9uZyB0aGUgbmV3IHJvdXRlLCBhbmQg dGh1cyBhdHRlbXB0IHRvIAogICByZS1lc3RhYmxpc2ggcmVzZXJ2YXRpb25zIHRocm91Z2ggdGhl IG5ldyBpbmdyZXNzIGdhdGV3YXkuIAogICBFc3NlbnRpYWxseSB0aGUgc2FtZSBwcm9jZWR1cmUg aXMgdXNlZCBhcyBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzIAogICBkb2N1bWVudCwgd2l0aCB0 aGUgcmUtcm91dGVkIHNlc3Npb24gdHJlYXRlZCBhcyBhIG5ldyBzZXNzaW9uIAogICByZXF1ZXN0 LiAKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDI5XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVu dCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBJbiBtb3Jl IGRldGFpbCwgY29uc2lkZXIgd2hhdCBoYXBwZW5zIGlmIGFuIGluZ3Jlc3MgZ2F0ZXdheSBvZiB0 aGUgCiAgIENMLXJlZ2lvbiBmYWlscy4gVGhlbiBSU1ZQIHJvdXRlcnMgdXBzdHJlYW0gb2YgaXQg ZG8gSVAgcmUtcm91dGluZyB0byAKICAgYSBuZXcgaW5ncmVzcyBnYXRld2F5LiBUaGUgbmV4dCB0 aW1lIHRoZSB1cHN0cmVhbSBSU1ZQIHJvdXRlciBzZW5kcyBhIAogICBQQVRIIHJlZnJlc2ggbWVz c2FnZSBpdCByZWFjaGVzIHRoZSBuZXcgaW5ncmVzcyBnYXRld2F5IHdoaWNoIAogICB0aGVyZWZv cmUgaW5zdGFsbHMgdGhlIGFzc29jaWF0ZWQgUlNWUCBzdGF0ZS4gVGhlIG5leHQgUlNWUCBSRVNW IAogICByZWZyZXNoIHdpbGwgcGljayB1cCB0aGUgQ29uZ2VzdGlvbi1MZXZlbC1Fc3RpbWF0ZSBm cm9tIHRoZSBlZ3Jlc3MgCiAgIGdhdGV3YXksIGFuZCB0aGUgaW5ncmVzcyBjb21wYXJlcyB0aGlz IHdpdGggaXRzIHRocmVzaG9sZCB0byBkZWNpZGUgCiAgIHdoZXRoZXIgdG8gYWRtaXQgdGhlIG5l dyBzZXNzaW9uLiBUaGlzIGNvdWxkIHJlc3VsdCBpbiBzb21lIG9mIHRoZSAKICAgZmxvd3MgYmVp bmcgcmVqZWN0ZWQsIGJ1dCB0aG9zZSBhY2NlcHRlZCB3aWxsIHJlY2VpdmUgdGhlIGZ1bGwgUW9T LiAKCiAgIEFuIGlzc3VlIHdpdGggdGhpcyBpcyB0aGF0IHdlIGhhdmUgdG8gd2FpdCB1bnRpbCBh IFBBVEggYW5kIFJFU1YgCiAgIHJlZnJlc2ggbWVzc2FnZXMgYXJlIHNlbnQgLSB3aGljaCBtYXkg bm90IGJlIHZlcnkgb2Z0ZW4gLSB0aGUgZGVmYXVsdCAKICAgdmFsdWUgaXMgMzAgc2Vjb25kcy4g W1JGQzIyMDVdIGRpc2N1c3NlcyBob3cgdG8gc3BlZWQgdXAgdGhlIGxvY2FsIAogICByZXBhaXIg bWVjaGFuaXNtLiBGaXJzdCwgdGhlIFJTVlAgbW9kdWxlIGlzIG5vdGlmaWVkIGJ5IHRoZSBsb2Nh bCAKICAgcm91dGluZyBwcm90b2NvbCBtb2R1bGUgb2YgYSByb3V0ZSBjaGFuZ2UgdG8gcGFydGlj dWxhciBkZXN0aW5hdGlvbnMsIAogICB3aGljaCB0cmlnZ2VycyBpdCB0byByYXBpZGx5IHNlbmQg b3V0IFBBVEggcmVmcmVzaCBtZXNzYWdlcy4gRnVydGhlciwgCiAgIHdoZW4gYSBQQVRIIHJlZnJl c2ggYXJyaXZlcyB3aXRoIGEgcHJldmlvdXMgaG9wIGFkZHJlc3MgZGlmZmVyZW50IAogICBmcm9t IHRoZSBvbmUgc3RvcmVkLCB0aGVuIFJFU1YgcmVmcmVzaGVzIGFyZSBpbW1lZGlhdGVseSBzZW50 IHRvIHRoYXQgCiAgIHByZXZpb3VzIGhvcC4gV2hlcmUgUlNWUCBpcyBvcGVyYXRpbmcgaG9wLWJ5 LWhvcCwgaS5lLiBvbiBldmVyeSAKICAgcm91dGVyLCB0aGVuIHRyaWdnZXJpbmcgdGhlIFBBVEgg cmVmcmVzaCBpcyBlYXN5IGFzIHRoZSByb3V0ZXIgY2FuIAogICBzaW1wbHkgbW9uaXRvciBpdHMg bG9jYWwgbGluay4gVGh1cywgdGhpcyBmYXN0IGxvY2FsIHJlcGFpciBtZWNoYW5pc20gCiAgIGNh biBiZSAgdXNlZCB0byBkZWFsIHdpdGggZmFpbHVyZXMgdXBzdHJlYW0gb2YgdGhlIGluZ3Jlc3Mg Z2F0ZXdheSwgCiAgIHdpdGggZmFpbHVyZXMgb2YgdGhlIGluZ3Jlc3MgZ2F0ZXdheSBhbmQgd2l0 aCBmYWlsdXJlcyBkb3duc3RyZWFtIG9mIAogICB0aGUgZWdyZXNzIGdhdGV3YXkuIAoKICAgQnV0 IHdoZXJlIFJTVlAgaXMgbm90IG9wZXJhdGluZyBob3AtYnktaG9wIChhcyBpcyB0aGUgY2FzZSB3 aXRoaW4gdGhlIAogICBDTC1yZWdpb24pLCBpdCBpcyBub3Qgc28gZWFzeSB0byB0cmlnZ2VyIHRo ZSBQQVRIIHJlZnJlc2guIAoKICAgVW5mb3J0dW5hdGVseSwgdGhpcyBwcm9ibGVtIGFwcGxpZXMg aWYgYW4gZWdyZXNzIGdhdGV3YXkgZmFpbHMsIHNpbmNlIAogICBpdCdzIHZlcnkgbGlrZWx5IHRo YXQgYW4gZWdyZXNzIGdhdGV3YXkgaXMgc2V2ZXJhbCBJUCBob3BzIGZyb20gdGhlIAogICBpbmdy ZXNzIGdhdGV3YXkuIChJZiB0aGUgaW5ncmVzcyBpcyBzZXZlcmFsIElQIGhvcHMgZnJvbSBpdHMg cHJldmlvdXMgCiAgIFJTVlAgbm9kZSwgdGhlbiB0aGVyZSBpcyB0aGUgc2FtZSBpc3N1ZS4pIFRo ZSBvcHRpb25zIGFwcGVhciB0byBiZTogCgogICBvIHRoZSBpbmdyZXNzIGdhdGV3YXkgaGFzIGEg bGluayBzdGF0ZSBkYXRhYmFzZSBmb3IgdGhlIENMLXJlZ2lvbiwgCiAgICAgIHNvIGl0IGNhbiBk ZXRlY3QgdGhhdCBhbiBlZ3Jlc3MgZ2F0ZXdheSBoYXMgZmFpbGVkIG9yIGJlY2FtZSAKICAgICAg dW5yZWFjaGFibGUgCgogICBvIHRoZXJlIGlzIGFuIGludGVyLWdhdGV3YXkgcHJvdG9jb2wsIHNv IHRoZSBpbmdyZXNzIGNhbiAKICAgICAgY29udGludW91c2x5IGNoZWNrIHRoYXQgdGhlIGVncmVz cyBnYXRld2F5cyBhcmUgc3RpbGwgYWxpdmUgCgogICBvIChkZWZhdWx0KSBkbyBub3RoaW5nIGFu ZCB3YWl0IGZvciB0aGUgcmVndWxhciBQQVRIL1JFU1YgcmVmcmVzaGVzIAogICAgICAoYW5kLCBp ZiBuZWVkZWQsIHRoZSBwcmUtZW1wdGlvbiBtZWNoYW5pc20pIHRvIHNvcnQgdGhpbmdzIG91dC4g CgogICAgCgogICAgCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1 LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDMwXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAg RGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgo1 LiBMaW1pdGF0aW9ucyBhbmQgc29tZSBwb3RlbnRpYWwgc29sdXRpb25zIAoKICAgSW4gdGhpcyBz ZWN0aW9uIHdlIGRlc2NyaWJlIHZhcmlvdXMgbGltaXRhdGlvbnMgb2YgdGhlIGRlcGxveW1lbnQg CiAgIG1vZGVsLCBhbmQgc29tZSBzdWdnZXN0aW9ucyBhYm91dCBwb3RlbnRpYWwgd2F5cyBvZiBh bGxldmlhdGluZyB0aGVtLiAKICAgVGhlIGxpbWl0YXRpb25zIGZhbGwgaW50byB0aHJlZSBicm9h ZCBjYXRlZ29yaWVzOiAKCiAgIG8gRUNNUCAoU2VjdGlvbiA1LjEpOiB0aGUgYXNzdW1wdGlvbiBh Ym91dCByb3V0aW5nIChTZWN0aW9uIDIuMikgaXMgCiAgICAgIHRoYXQgYWxsIHBhY2tldHMgYmV0 d2VlbiBhIHBhaXIgb2YgaW5ncmVzcyBhbmQgZWdyZXNzIGdhdGV3YXlzIAogICAgICBmb2xsb3cg dGhlIHNhbWUgcGF0aDsgRUNNUCBicmVha3MgdGhpcyBhc3N1bXB0aW9uLiBBIHN0dWR5IAogICAg ICByZWdhcmRpbmcgdGhlIGFjY3VyYWN5IG9mIGxvYWQgYmFsYW5jaW5nIHNjaGVtZXMgY2FuIGJl IGZvdW5kIGluIAogICAgICBbTG9hZEJhbGFuY2luZy1hXSBhbmQgW0xvYWRCYWxhbmNpbmctYl0u IAoKICAgbyBUaGUgbGFjayBvZiBnbG9iYWwgY29vcmRpbmF0aW9uIChTZWN0aW9ucyA1LjIsIDUu MyBhbmQgNS40KTogYSAKICAgICAgZGVjaXNpb24gYWJvdXQgYWRtaXNzaW9uIGNvbnRyb2wgb3Ig ZmxvdyBwcmUtZW1wdGlvbiBpcyBtYWRlIGZvciAKICAgICAgb25lIGFnZ3JlZ2F0ZSBpbmRlcGVu ZGVudGx5IG9mIG90aGVyIGFnZ3JlZ2F0ZXMgCgogICBvIFRpbWluZyBhbmQgYWNjdXJhY3kgb2Yg bWVhc3VyZW1lbnRzIChTZWN0aW9ucyA1LjUgYW5kIDUuNik6IHRoZSAKICAgICAgYXNzdW1wdGlv biAoU2VjdGlvbiAyLjIpIHRoYXQgYWRkaXRpb25hbCBsb2FkLCBvZmZlcmVkIHdpdGhpbiB0aGUg CiAgICAgIHJlYWN0aW9uIHRpbWUgb2YgdGhlIG1lYXN1cmVtZW50LWJhc2VkIGFkbWlzc2lvbiBj b250cm9sIAogICAgICBtZWNoYW5pc20sIGRvZXNuJ3QgbW92ZSB0aGUgc3lzdGVtIGRpcmVjdGx5 IGZyb20gbm8gY29uZ2VzdGlvbiB0byAKICAgICAgb3ZlcmxvYWQgKGRyb3BwaW5nIHBhY2tldHMp LiBBICdmbGFzaCBjcm93ZCcgbWF5IGJyZWFrIHRoaXMgCiAgICAgIGFzc3VtcHRpb24gKFNlY3Rp b24gNS41KS4gVGhlcmUgYXJlIGEgdmFyaWV0eSBvZiBtb3JlIGdlbmVyYWwgCiAgICAgIGlzc3Vl cyBhc3NvY2lhdGVkIHdpdGggbWFya2luZyBtZWFzdXJlbWVudHMsIHdoaWNoIG1heSBtZWFuIGl0 J3MgYSAKICAgICAgZ29vZCBpZGVhIHRvIGRvIHByZS1lbXB0aW9uICdzbG93ZXInIChTZWN0aW9u IDUuNikuIAoKICAgRWFjaCBzZWN0aW9uIGRlc2NyaWJlcyBhIGxpbWl0YXRpb24gYW5kIHNvbWUg cG9zc2libGUgc29sdXRpb25zIHRvIAogICBhbGxldmlhdGUgdGhlIGxpbWl0YXRpb24uIFRoZXNl IGFyZSBpbnRlbmRlZCBhcyBvcHRpb25zIGZvciBhbiAKICAgb3BlcmF0b3IgdG8gY29uc2lkZXIs IGJhc2VkIG9uIHRoZWlyIHBhcnRpY3VsYXIgcmVxdWlyZW1lbnRzLiAgCgogICBXZSB3b3VsZCB3 ZWxjb21lIGZlZWRiYWNrLCBmb3IgZXhhbXBsZSBzdWdnZXN0aW9ucyBhcyB0byB3aGljaCAKICAg cG90ZW50aWFsIHNvbHV0aW9ucyBhcmUgd29ydGggd29ya2luZyBvdXQgaW4gbW9yZSBkZXRhaWws IGFuZCBpZGVhcyAKICAgb24gbmV3IHBvdGVudGlhbCBzb2x1dGlvbnMuICAgCgogICBGaW5hbGx5 IFNlY3Rpb24gNS43IGNvbnNpZGVycyBzb21lIG90aGVyIHBvdGVudGlhbCBleHRlbnNpb25zLiAK CiAgICAKCjUuMS4gRUNNUCAKCiAgIElmIHRoZSBDTC1yZWdpb24gdXNlcyBFcXVhbCBDb3N0IE11 bHRpcGF0aCBSb3V0aW5nIChFQ01QKSwgdGhlbiAKICAgdHJhZmZpYyBiZXR3ZWVuIGEgcGFydGlj dWxhciBwYWlyIG9mIGluZ3Jlc3MgYW5kIGVncmVzcyBnYXRld2F5cyBtYXkgCiAgIGZvbGxvdyBz ZXZlcmFsIGRpZmZlcmVudCBwYXRocy4gCgogICBXaHk/IEFuIEVDTVAtZW5hYmxlZCByb3V0ZXIg cnVucyBhbiBhbGdvcml0aG0gdG8gY2hvb3NlIGJldHdlZW4gCiAgIHBvdGVudGlhbCBvdXRnb2lu ZyBsaW5rcywgYmFzZWQgb24gYSBoYXNoIG9mIGZpZWxkcyBzdWNoIGFzIHRoZSAKICAgcGFja2V0 J3Mgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgLSBleGFjdGx5IHdoYXQgZGVwZW5k cyBvbiAKICAgdGhlIHByb3ByaWV0YXJ5IGFsZ29yaXRobS4gUGFja2V0cyBhcmUgYWRkcmVzc2Vk IHRvIHRoZSBDTCBmbG93J3MgCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXBy aWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzFdIAoMCkludGVybmV0LURyYWZ0ICAg ICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAg ICAKCiAgIGVuZC1wb2ludCwgYW5kIHRoZXJlZm9yZSBkaWZmZXJlbnQgZmxvd3MgbWF5IGZvbGxv dyBkaWZmZXJlbnQgcGF0aHMgCiAgIHRocm91Z2ggdGhlIENMLXJlZ2lvbi4gKEFsbCBwYWNrZXRz IG9mIGFuIGluZGl2aWR1YWwgZmxvdyBmb2xsb3cgdGhlIAogICBzYW1lIEVDTVAgcGF0aC4pIAoK ICAgVGhlIHByb2JsZW0gaXMgdGhhdCBpZiBvbmUgb2YgdGhlIHBhdGhzIGlzIGNvbmdlc3RlZCBz dWNoIHRoYXQgCiAgIHBhY2tldHMgYXJlIGJlaW5nIGFkbWlzc2lvbiBtYXJrZWQsIHRoZW4gdGhl IENvbmdlc3Rpb24tTGV2ZWwtCiAgIEVzdGltYXRlIG1lYXN1cmVkIGJ5IHRoZSBlZ3Jlc3MgZ2F0 ZXdheSB3aWxsIGJlIGRpbHV0ZWQgYnkgdW5tYXJrZWQgCiAgIHBhY2tldHMgZnJvbSBvdGhlciBu b24tY29uZ2VzdGVkIHBhdGhzLiBTaW1pbGFybHksIHRoZSBtZWFzdXJlbWVudCBvZiAKICAgdGhl IFN1c3RhaW5hYmxlLUFnZ3JlZ2F0ZS1SYXRlIHdpbGwgYWxzbyBiZSBkaWx1dGVkLiAgCgogICBQ b3NzaWJsZSBzb2x1dGlvbiBhcHByb2FjaGVzIGFyZTogCgogICBvIHR1bm5lbDogdHJhZmZpYyBp cyB0dW5uZWxsZWQgYWNyb3NzIHRoZSBDTC1yZWdpb24uIFRoZW4gdGhlIAogICAgICBkZXN0aW5h dGlvbiBhZGRyZXNzIChhbmQgc28gb24pIHNlZW4gYnkgdGhlIEVDTVAgYWxnb3JpdGhtIGlzIHRo YXQgCiAgICAgIG9mIHRoZSBlZ3Jlc3MgZ2F0ZXdheSwgc28gYWxsIGZsb3dzIGZvbGxvdyB0aGUg c2FtZSBwYXRoLiAKICAgICAgRWZmZWN0aXZlbHkgRUNNUCBpcyB0dXJuZWQgb2ZmLiBBcyBhIGNv bXByb21pc2UsIHRvIHRyeSB0byByZXRhaW4gCiAgICAgIHNvbWUgb2YgdGhlIGJlbmVmaXRzIG9m IEVDTVAsIHRoZXJlIGNvdWxkIGJlIHNldmVyYWwgdHVubmVscywgZWFjaCAKICAgICAgZm9sbG93 aW5nIGEgZGlmZmVyZW50IEVDTVAgcGF0aCwgd2l0aCBmbG93cyByYW5kb21seSBhc3NpZ25lZCB0 byAKICAgICAgZGlmZmVyZW50IHR1bm5lbHMuICAKCiAgIG8gYXNzdW1lIHdvcnN0IGNhc2U6IHRo ZSBvcGVyYXRvciBzZXRzIHRoZSBjb25maWd1cmVkLWFkbWlzc2lvbi1yYXRlIAogICAgICAoYW5k IGNvbmZpZ3VyZWQtcHJlLWVtcHRpb24tcmF0ZSkgdG8gYmVsb3cgdGhlIG9wdGltdW0gbGV2ZWwg dG8gCiAgICAgIGNvbXBlbnNhdGUgZm9yIHRoZSBmYWN0IHRoYXQgdGhlIGVmZmVjdCBvbiB0aGUg Q29uZ2VzdGlvbi1MZXZlbC0KICAgICAgRXN0aW1hdGUgKGFuZCBTdXN0YWluYWJsZS1BZ2dyZWdh dGUtUmF0ZSkgb2YgdGhlIGNvbmdlc3Rpb24gCiAgICAgIGV4cGVyaWVuY2VkIG92ZXIgb25lIG9m IHRoZSBwYXRocyBtYXkgYmUgZGlsdXRlZCBieSB0cmFmZmljIAogICAgICByZWNlaXZlZCBvdmVy IG5vbi1jb25nZXN0ZWQgcGF0aHMuIEhlbmNlIGxvd2VyIHRocmVzaG9sZHMgbmVlZCB0byAKICAg ICAgYmUgdXNlZCB0byBlbnN1cmUgZWFybHkgYWRtaXNzaW9uIGNvbnRyb2wgcmVqZWN0aW9uIGFu ZCBwcmUtCiAgICAgIGVtcHRpb24gb3ZlciB0aGUgY29uZ2VzdGVkIHBhdGguIFRoaXMgYXBwcm9h Y2ggd2lsbCB3YXN0ZSBjYXBhY2l0eSAKICAgICAgKGUuZy4gZmxvd3MgZm9sbG93aW5nIGEgbm9u LWNvbmdlc3RlZCBFQ01QIHBhdGggYXJlIG5vdCBhZG1pdHRlZCAKICAgICAgb3IgYXJlIHByZS1l bXB0ZWQpLCBhbmQgdGhlcmUgaXMgc3RpbGwgdGhlIGRhbmdlciB0aGF0IGZvciBzb21lIAogICAg ICB0cmFmZmljIG1peGVzIHRoZSBvcGVyYXRvciBoYXNuJ3QgYmVlbiBjYXV0aW91cyBlbm91Z2gu IAoKICAgbyBmb3IgYWRtaXNzaW9uIGNvbnRyb2wsIHByb2JlIHRvIG9idGFpbiBhIGZsb3ctc3Bl Y2lmaWMgY29uZ2VzdGlvbi0KICAgICAgbGV2ZWwtZXN0aW1hdGUuIEVhcmxpZXIgdGhpcyBkb2N1 bWVudCBzdWdnZXN0cyBjb250aW51b3VzbHkgCiAgICAgIG1vbml0b3JpbmcgdGhlIGNvbmdlc3Rp b24tbGV2ZWwtZXN0aW1hdGUuIEluc3RlYWQsIHByb2JlIHBhY2tldHMgCiAgICAgIGNvdWxkIGJl IHNlbnQgZm9yIGVhY2ggcHJvc3BlY3RpdmUgbmV3IGZsb3cuIFRoZSBwcm9iZSBwYWNrZXRzIAog ICAgICBoYXZlIHRoZSBzYW1lIElQIGFkZHJlc3MgZXRjIGFzIHRoZSBkYXRhIHBhY2tldHMgd291 bGQgaGF2ZSwgYW5kIAogICAgICBoZW5jZSBmb2xsb3cgdGhlIHNhbWUgRUNNUCBwYXRoLiBIb3dl dmVyLCBwcm9iaW5nIGlzIGFuIGV4dHJhIAogICAgICBvdmVyaGVhZCwgZGVwZW5kaW5nIG9uIGhv dyBtYW55IHByb2JlIHBhY2tldHMgbmVlZCB0byBiZSBzZW50IHRvIAogICAgICBnZXQgYSBzdWZm aWNpZW50bHkgYWNjdXJhdGUgY29uZ2VzdGlvbi1sZXZlbC1lc3RpbWF0ZS4gUHJvYmVzIGFsc28g CiAgICAgIGNhdXNlIGEgcHJvY2Vzc2luZyBvdmVyaGVhZCwgZWl0aGVyIGZvciB0aGUgbWFjaGlu ZSBhdCB0aGUgCiAgICAgIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3IgZm9yIHRoZSBlZ3Jlc3MgZ2F0 ZXdheSB0byBpZGVudGlmeSBhbmQgCiAgICAgIHJlbW92ZSB0aGUgcHJvYmUgcGFja2V0cy4gCgoK CgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAg ICAgICAgICAgIFtQYWdlIDMyXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBN b2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBvIGZvciBmbG93 IHByZS1lbXB0aW9uLCBvbmx5IHNlbGVjdCBmbG93cyBmb3IgcHJlLWVtcHRpb24gZnJvbSAKICAg ICAgYW1vbmdzdCB0aG9zZSB0aGF0IGhhdmUgYWN0dWFsbHkgcmVjZWl2ZWQgYSBQcmUtZW1wdGlv biBNYXJrZWQgCiAgICAgIHBhY2tldC4gQmVjYXVzZSB0aGVzZSBmbG93cyBtdXN0IGhhdmUgZm9s bG93ZWQgYW4gRUNNUCBwYXRoIHRoYXQgCiAgICAgIGdvZXMgdGhyb3VnaCBhbiBvdmVybG9hZGVk IHJvdXRlci4gSG93ZXZlciwgaXQgbmVlZHMgc29tZSBleHRyYSAKICAgICAgd29yayBieSB0aGUg ZWdyZXNzIGdhdGV3YXksIHRvIHJlY29yZCB0aGlzIGluZm9ybWF0aW9uIGFuZCByZXBvcnQgCiAg ICAgIGl0IHRvIHRoZSBpbmdyZXNzIGdhdGV3YXkuICAKCiAgIG8gZm9yIGZsb3cgcHJlLWVtcHRp b24sIGEgdmFyaWFudCBvZiB0aGlzIGlkZWEgaW52b2x2ZXMgaW50cm9kdWNpbmcgCiAgICAgIGEg bmV3IG1hcmtpbmcgYmVoYXZpb3VyLCAnUm91dGVyIE1hcmtpbmcnLiBBIHJvdXRlciB0aGF0IGlz IHByZS0KICAgICAgZW1wdGlvbiBtYXJraW5nIHBhY2tldHMgb24gYW4gb3V0Z29pbmcgbGluaywg YWxzbyAnUm91dGVyIE1hcmtzJyAKICAgICAgYWxsIG90aGVyIHBhY2tldHMuIFdoZW4gc2VsZWN0 aW5nIGZsb3dzIGZvciBwcmUtZW1wdGlvbiwgdGhlIAogICAgICBzZWxlY3Rpb24gaXMgbWFkZSBm cm9tIGFtb25nc3QgdGhvc2UgdGhhdCBoYXZlIGFjdHVhbGx5IHJlY2VpdmVkIGEgCiAgICAgIFJv dXRlciBNYXJrZWQgb3IgUHJlLWVtcHRpb24gTWFya2VkIHBhY2tldC4gSGVuY2UgY29tcGFyZWQg d2l0aCAKICAgICAgdGhlIHByZXZpb3VzIGJ1bGxldCwgaXQgbWF5IGV4dGVuZCB0aGUgcmFuZ2Ug b2YgZmxvd3MgZnJvbSB3aGljaCAKICAgICAgdGhlIHByZS1lbXB0aW9uIHNlbGVjdGlvbiBpcyBt YWRlIChpLmUuIGl0IGluY2x1ZGVzIHRob3NlIHdoaWNoLCAKICAgICAgYnkgY2hhbmNlLCBoYXZl bid0IGhhZCBhbnkgcHJlLWVtcHRpb24gbWFya2VkIHBhY2tldHMpLiBIb3dldmVyLCAKICAgICAg aXQgYWxzbyByZXF1aXJlcyB0aGF0IHRoZSAnUm91dGVyIE1hcmtpbmcnIHN0YXRlIGlzIHNvbWVo b3cgCiAgICAgIGVuY29kZWQgaW50byBhIHBhY2tldCwgaS5lLiBpdCBtYWtlcyBoYXJkZXIgdGhl IGVuY29kaW5nIGNoYWxsZW5nZSAKICAgICAgZGlzY3Vzc2VkIGluIEFwcGVuZGl4IEMgb2YgW1BD Tl0uIFRoZSBleHRyYSB3b3JrIHJlcXVpcmVkIGJ5IHRoZSAKICAgICAgZWdyZXNzIGdhdGV3YXkg d291bGQgYWxzbyBiZSBzb21ld2hhdCBoaWdoZXIgdGhhbiBmb3IgdGhlIHByZXZpb3VzIAogICAg ICBidWxsZXQuICAKCiAgICAKCjUuMi4gQmVhdCBkb3duIGVmZmVjdCAKCiAgIFRoaXMgbGltaXRh dGlvbiBjb25jZXJucyB0aGUgcHJlLWVtcHRpb24gbWVjaGFuaXNtIGluIHRoZSBjYXNlIHdoZXJl IAogICBtb3JlIHRoYW4gb25lIHJvdXRlciBpcyBwcmUtZW1wdGlvbiBtYXJraW5nIHBhY2tldHMu IFRoZSByZXN1bHQgCiAgIChleHBsYWluZWQgaW4gdGhlIG5leHQgcGFyYWdyYXBoKSBpcyB0aGF0 IHRoZSBtZWFzdXJlbWVudCBvZiAKICAgc3VzdGFpbmFibGUtYWdncmVnYXRlLXJhdGUgaXMgbG93 ZXIgdGhhbiBpdHMgdHJ1ZSB2YWx1ZSwgc28gbW9yZSAKICAgdHJhZmZpYyBpcyBwcmUtZW1wdGVk IHRoYW4gbmVjZXNzYXJ5LiAKCiAgIEltYWdpbmUgdGhlIHNjZW5hcmlvOiAKCiAgICAgICAgICAg ICAgICAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKyAKICAgSUFSLWI9MyA+ QEBAQEB8IENQUj0yIHxAQEBAQHwgQ1BSPjIgfEBAQEBAfCBDUFI9MSB8QEA+IFNBUi1iPTEgIAog ICBJQVItYT0xID4jIyMjI3wgIFIxICAgfCMjIyMjfCAgUjIgICB8ICAgICB8ICBSMyAgIHwgIAog ICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICAgKy0tLS0tLS0rICAgICArLS0tLS0tLSsgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIyAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2IFNBUi1hPTAuNSAKICAgIAogICBGaWd1cmUg NDogU2NlbmFyaW8gdG8gaWxsdXN0cmF0ZSAnYmVhdCBkb3duIGVmZmVjdCcgbGltaXRhdGlvbiAK ICAgIAogICBBZ2dyZWdhdGUtYSAoaW5ncmVzcy1hZ2dyZWdhdGUtcmF0ZSwgSUFSLCAxIHVuaXQp IHRha2VzIGEgJ3Nob3J0JyAKICAgcm91dGUgdGhyb3VnaCB0d28gcm91dGVycywgb25lIG9mIHdo aWNoIChSMSkgaXMgYWJvdmUgaXRzIGNvbmZpZ3VyZWQtCiAKIApCcmlzY29lICAgICAgICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzNdIAoMCklu dGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBP Y3RvYmVyIDIwMDYgCiAgICAKCiAgIHByZS1lbXB0aW9uLXJhdGUgKENQUiwgMiB1bml0cykuIEFn Z3JlZ2F0ZS1iIHRha2VzIGEgJ2xvbmcnIHJvdXRlLCAKICAgZ29pbmcgdGhyb3VnaCBhIHNlY29u ZCBjb25nZXN0ZWQgcm91dGVyIChSMywgd2l0aCBhIENQUiBvZiAxIHVuaXQpLiAgCgogICBSMSdz IGlucHV0IHRyYWZmaWMgaXMgNCB1bml0cywgdHdpY2UgaXRzIGNvbmZpZ3VyZWQtcHJlLWVtcHRp b24tcmF0ZSwgCiAgIHNvIDUwJSBvZiBwYWNrZXRzIGFyZSBwcmUtZW1wdGlvbiBtYXJrZWQuIEhl bmNlIHRoZSBtZWFzdXJlZCAKICAgc3VzdGFpbmFibGUtYWdncmVnYXRlLXJhdGUgKFNBUikgZm9y IGFnZ3JlZ2F0ZS1hIGlzIDAuNSwgYW5kIGhhbGYgb2YgCiAgIGl0cyB0cmFmZmljIHdpbGwgYmUg cHJlLWVtcHRlZC4gIAoKICAgUjMncyBpbnB1dCBvZiBub24tcHJlLWVtcHRpb24tbWFya2VkIHRy YWZmaWMgaXMgMS41IHVuaXRzLCBhbmQgCiAgIHRoZXJlZm9yZSBpdCBoYXMgdG8gZG8gZnVydGhl ciBtYXJraW5nLiAgCgogICBCdXQgdGhpcyBtZWFucyB0aGF0IGFnZ3JlZ2F0ZS1hIGhhcyB0YWtl biBhIGJpZ2dlciBoaXQgdGhhbiBpdCBuZWVkZWQgCiAgIHRvOyB0aGUgcm91dGVyIFIxIGNvdWxk IGhhdmUgbGV0IHRocm91Z2ggYWxsIG9mIGFnZ3JlZ2F0ZS1hJ3MgdHJhZmZpYyAKICAgdW5tYXJr ZWQgaWYgaXQgaGFkIGtub3duIHRoYXQgdGhlIHNlY29uZCByb3V0ZXIgUjIgd2FzIGdvaW5nIHRv ICJiZWF0IAogICBkb3duIiBhZ2dyZWdhdGUtYidzIHRyYWZmaWMgZnVydGhlci4gIAoKICAgR2Vu ZXJhbGlzaW5nLCB0aGUgcmVzdWx0IGlzIHRoYXQgaW4gYSBzY2VuYXJpbyB3aGVyZSBtb3JlIHRo YW4gb25lIAogICByb3V0ZXIgaXMgcHJlLWVtcHRpb24gbWFya2luZyBwYWNrZXRzLCBvbmx5IHRo ZSBmaW5hbCByb3V0ZXIgaXMgc3VyZSAKICAgdG8gYmUgZnVsbHkgbG9hZGVkIGFmdGVyIGZsb3cg cHJlLWVtcHRpb24uIFRoZSBmdW5kYW1lbnRhbCByZWFzb24gaXMgCiAgIHRoYXQgYSByb3V0ZXIg bWFrZXMgYSBsb2NhbCBkZWNpc2lvbiBhYm91dCB3aGljaCBwYWNrZXRzIHRvIHByZS0KICAgZW1w dGlvbiBtYXJrLCBpLmUuIGluZGVwZW5kZW50bHkgb2YgaG93IG90aGVyIHJvdXRlcnMgYXJlIHBy ZS1lbXB0aW9uIAogICBtYXJraW5nLiBBIHZlcnkgc2ltaWxhciBlZmZlY3QgaGFzIGJlZW4gbm90 ZWQgaW4gWENQIFtMb3ddLiAKCiAgIFBvdGVudGlhbCBzb2x1dGlvbnM6IAoKICAgbyBhIGZ1bGwg c29sdXRpb24gd291bGQgaW52b2x2ZSByb3V0ZXJzIGxlYXJuaW5nIGFib3V0IG90aGVyIHJvdXRl cnMgCiAgICAgIHRoYXQgYXJlIHByZS1lbXB0aW9uIG1hcmtpbmcsIGFuZCBiZWluZyBhYmxlIHRv IGRpZmZlcmVudGlhbGx5IAogICAgICBtYXJrIGZsb3dzIChlLmcuIGluIHRoZSBleGFtcGxlIGFi b3ZlLCBhZ2dyZWdhdGUtYSdzIHBhY2tldHMgCiAgICAgIHdvdWxkbid0IGJlIG1hcmtlZCBieSBS MSkuIFRoaXMgc2VlbXMgaGFyZCBhbmQgY29tcGxleC4gCgogICBvIGRvIG5vdGhpbmcgYWJvdXQg dGhpcyBsaW1pdGF0aW9uLiBJdCBjYXVzZXMgb3Zlci1wcmUtZW1wdGlvbiwgCiAgICAgIHdoaWNo IGlzIHNhZmUuIEF0IHRoZSBtb21lbnQgdGhpcyBpcyBvdXIgc3VnZ2VzdGVkIG9wdGlvbi4gIAoK CgoKCgoKCgoKCgoKCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUs IDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzRdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBE ZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAg IG8gZG8gcHJlLWVtcHRpb24gJ3Nsb3dseScuIFRoZSBkZXNjcmlwdGlvbiBlYXJsaWVyIGluIHRo aXMgZG9jdW1lbnQgCiAgICAgIGFzc3VtZXMgdGhhdCBhZnRlciB0aGUgbWVhc3VyZW1lbnRzIG9m IGluZ3Jlc3MtYWdncmVnYXRlLXJhdGUgYW5kIAogICAgICBzdXN0YWluYWJsZS1hZ2dyZWdhdGUt cmF0ZSwgdGhlbiBzdWZmaWNpZW50IGZsb3dzIGFyZSBwcmUtZW1wdGVkIAogICAgICBpbiAnb25l IHNob3QnIHRvIGVsaW1pbmF0ZSB0aGUgZXhjZXNzIHRyYWZmaWMuIEFuIGFsdGVybmF0aXZlIGlz IAogICAgICB0byBzcHJlYWQgcHJlLWVtcHRpb24gb3ZlciBzZXZlcmFsIHJvdW5kczogaW5pdGlh bGx5LCBvbmx5IHByZS0KICAgICAgZW1wdCBlbm91Z2ggdG8gZWxpbWluYXRlIHNvbWUgb2YgdGhl IGV4Y2VzcyB0cmFmZmljLCB0aGVuIHJlLQogICAgICBtZWFzdXJlIHRoZSBzdXN0YWluYWJsZS1h Z2dyZWdhdGUtcmF0ZSwgYW5kIHRoZW4gcHJlLWVtcHQgc29tZSAKICAgICAgbW9yZSwgZXRjLiBJ biB0aGUgc2NlbmFyaW8gYWJvdmUsIHRoZSByZS1tZWFzdXJlbWVudCB3b3VsZCBiZSAKICAgICAg bG93ZXIgdGhhbiBleHBlY3RlZCwgZHVlIHRvIHRoZSBiZWF0IGRvd24gZWZmZWN0LCBhbmQgaGVu Y2UgaW4gdGhlIAogICAgICBzZWNvbmQgcm91bmQgb2YgcHJlLWVtcHRpb24gbGVzcyBvZiBhZ2dy ZWdhdGUtYSdzIHRyYWZmaWMgd291bGQgYmUgCiAgICAgIHByZS1lbXB0ZWQgKHBlcmhhcHMgbm9u ZSkuIE92ZXJhbGwsIHRoZXJlZm9yZSB0aGUgaW1wYWN0IG9mIHRoZSAKICAgICAgJ2JlYXQgZG93 bicgZWZmZWN0IHdvdWxkIGJlIGxlc3NlbmVkLCBpLmUuIHRoZXJlIHdvdWxkIGJlIGEgCiAgICAg IHNtYWxsZXIgZGVncmVlIG9mIG92ZXIgcHJlLWVtcHRpb24uIFRoZSBkb3duc2lkZSBpcyB0aGF0 IHRoZSAKICAgICAgb3ZlcmFsbCBwcmUtZW1wdGlvbiBpcyBzbG93ZXIsIGFuZCB0aGVyZWZvcmUg cm91dGVycyB3aWxsIGJlIAogICAgICBjb25nZXN0ZWQgbG9uZ2VyLiAgCgogICAgCgogICAgCgo1 LjMuIEJpLWRpcmVjdGlvbmFsIHNlc3Npb25zIAoKICAgVGhlIGRvY3VtZW50IGVhcmxpZXIgZGVz Y3JpYmVzIGhvdyB0byBkZWNpZGUgd2hldGhlciBvciBub3QgdG8gYWRtaXQgCiAgIChvciBwcmUt ZW1wdCkgYSBwYXJ0aWN1bGFyIGZsb3cuIEhvd2V2ZXIsIGZyb20gYSB1c2VyL2FwcGxpY2F0aW9u IAogICBwZXJzcGVjdGl2ZSwgdGhlIHNlc3Npb24gaXMgdGhlIHJlbGV2YW50IHVuaXQgb2YgZ3Jh bnVsYXJpdHkuIEEgCiAgIHNlc3Npb24gY2FuIGNvbnNpc3Qgb2Ygc2V2ZXJhbCBmbG93cyB3aGlj aCBtYXkgbm90IGFsbCBiZSBwYXJ0IG9mIHRoZSAKICAgc2FtZSBhZ2dyZWdhdGUuIFRoZSBtb3N0 IG9idmlvdXMgZXhhbXBsZSBpcyBhIGJpLWRpcmVjdGlvbmFsIHNlc3Npb24sIAogICB3aGVyZSB0 aGUgdHdvIGZsb3dzIHNob3VsZCBpZGVhbGx5IGJlIGFkbWl0dGVkIG9yIHByZS1lbXB0ZWQgYXMg YSAKICAgcGFpciAtIGZvciBpbnN0YW5jZSBhIHZvaWNlIGNhbGwgb25seSBtYWtlcyBzZW5zZSBp ZiBBIGNhbiBzZW5kIHRvIEIgCiAgIGFzIHdlbGwgYXMgQiB0byBBISBCdXQgdGhlIGFkbWlzc2lv biBhbmQgcHJlLWVtcHRpb24gbWVjaGFuaXNtcyAKICAgZGVzY3JpYmVkIGVhcmxpZXIgaW4gdGhp cyBkb2N1bWVudCBvcGVyYXRlIG9uIGEgcGVyLWFnZ3JlZ2F0ZSBiYXNpcywgCiAgIGluZGVwZW5k ZW50bHkgb2Ygd2hhdCdzIGhhcHBlbmluZyB3aXRoIG90aGVyIGFnZ3JlZ2F0ZXMuIEZvciAKICAg YWRtaXNzaW9uIGNvbnRyb2wgdGhlIHByb2JsZW0gaXNuJ3Qgc2VyaW91czogZS5nLiB0aGUgU0lQ IHNlcnZlciBmb3IgCiAgIHRoZSB2b2ljZSBjYWxsIGNhbiBlYXNpbHkgZGV0ZWN0IHRoYXQgdGhl IEEtdG8tQiBmbG93IGhhcyBiZWVuIAogICBhZG1pdHRlZCBidXQgdGhlIEItdG8tQSBmbG93IGJs b2NrZWQsIGFuZCBpbmZvcm0gdGhlIHVzZXIgcGVyaGFwcyB2aWEgCiAgIGEgYnVzeSB0b25lLiBG b3IgZmxvdyBwcmUtZW1wdGlvbiwgdGhlIHByb2JsZW0gaXMgc2ltaWxhciBidXQgbW9yZSAKICAg c2VyaW91cy4gSWYgYm90aCB0aGUgYWdncmVnYXRlLTEtdG8tMiAoaS5lLiBmcm9tIGdhdGV3YXkg MSB0byBnYXRld2F5IAogICAyKSBhbmQgdGhlIGFnZ3JlZ2F0ZS0yLXRvLTEgaGF2ZSB0byBwcmUt ZW1wdCBmbG93cywgdGhlbiBpdCB3b3VsZCBiZSAKICAgZ29vZCBpZiBlaXRoZXIgYWxsIG9mIHRo ZSBmbG93cyBvZiBhIHBhcnRpY3VsYXIgc2Vzc2lvbiB3ZXJlIHByZS0KICAgZW1wdGVkIG9yIG5v bmUgb2YgdGhlbS4gVGhlcmVmb3JlIGlmIHRoZSB0d28gYWdncmVnYXRlcyBwcmUtZW1wdCAKICAg Zmxvd3MgaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLCBtb3JlIHNlc3Npb25zIHdpbGwgZW5k IHVwIGJlaW5nIAogICB0b3JuIGRvd24gdGhhbiBpcyByZWFsbHkgbmVjZXNzYXJ5LiBGb3IgaW5z dGFuY2UsIHByZS1lbXB0aW5nIG9uZSAKICAgZGlyZWN0aW9uIG9mIGEgdm9pY2UgY2FsbCB3aWxs IHJlc3VsdCBpbiB0aGUgU0lQIHNlcnZlciB0ZWFyaW5nIGRvd24gCiAgIHRoZSBvdGhlciBkaXJl Y3Rpb24gYW55d2F5LiAgCgogICAgCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDM1XSAKDApJbnRlcm5ldC1EcmFm dCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2 IAogICAgCgogICAgCgogICBQb3RlbnRpYWwgc29sdXRpb25zOiAKCiAgIG8gaWYgaXQncyBrbm93 biB0aGF0IGFsbCBzZXNzaW9uIGFyZSBiaS1kaXJlY3Rpb25hbCwgc2ltcGx5IHByZS0KICAgICAg ZW1wdGluZyByb3VnaGx5IGhhbGYgYXMgbWFueSBmbG93cyBhcyBzdWdnZXN0ZWQgYnkgdGhlIAog ICAgICBtZWFzdXJlbWVudHMgb2Yge2luZ3Jlc3MtYWdncmVnYXRlLXJhdGUgLSBzdXN0YWluYWJs ZS1hZ2dyZWdhdGUtCiAgICAgIHJhdGV9LiBCdXQgdGhpcyBtYWtlcyBhIGJpZyBhc3N1bXB0aW9u IGFib3V0IHRoZSBuYXR1cmUgb2YgCiAgICAgIHNlc3Npb25zLCBhbmQgYWxzbyB0aGF0IHRoZSBh Z2dyZWdhdGUtMS10by0yIGFuZCBhZ2dyZWdhdGUtMi10by0xIAogICAgICBhcmUgZXF1YWxseSBv dmVybG9hZGVkLiAgCgogICBvIGlnbm9yZSB0aGUgbGltaXRhdGlvbi4gVGhlIHBlbmFsdHkgd2ls bCBiZSBxdWl0ZSBzbWFsbCBpZiBtb3N0IAogICAgICBzZXNzaW9ucyBjb25zaXN0IG9mIG9uZSBm bG93IG9yIG9mIGZsb3dzIHBhcnQgb2YgdGhlIHNhbWUgCiAgICAgIGFnZ3JlZ2F0ZS4gIAoKICAg byBpbnRyb2R1Y2UgYSBnYXRld2F5IGNvbnRyb2xsZXIuIEl0IHdvdWxkIHJlY2VpdmUgcmVwb3J0 cyBmb3IgYWxsIAogICAgICBhZ2dyZWdhdGVzIHdoZXJlIHRoZSBpbmdyZXNzLWFnZ3JlZ2F0ZS1y YXRlIGV4Y2VlZHMgdGhlIAogICAgICBzdXN0YWluYWJsZS1hZ2dyZWdhdGUtcmF0ZS4gSXQgdGhl biB3b3VsZCBtYWtlIGEgZ2xvYmFsIGRlY2lzaW9uIAogICAgICBhYm91dCB3aGljaCBmbG93cyB0 byBwcmUtZW1wdC4gSG93ZXZlciBpdCByZXF1aXJlcyBxdWl0ZSBzb21lIAogICAgICBjb21wbGV4 aXR5LCBmb3IgZXhhbXBsZSB0aGUgY29udHJvbGxlciBuZWVkcyB0byB1bmRlcnN0YW5kIHdoaWNo IAogICAgICBmbG93cyBtYXAgdG8gd2hpY2ggc2Vzc2lvbnMuIFRoaXMgbWF5IGJlIGFuIG9wdGlv biBpbiBzb21lIAogICAgICBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHdoZXJlIGdhdGV3YXlzIGFy ZW4ndCBoYW5kbGluZyB0b28gbWFueSAKICAgICAgZmxvd3MgKGJ1dCBub3RlIHRoYXQgdGhpcyBi cmVha3MgdGhlIGFnZ3JlZ2F0aW9uIGFzc3VtcHRpb24gb2YgCiAgICAgIFNlY3Rpb24gMi4yKS4g QSB2YXJpYW50IG9mIHRoaXMgaWRlYSB3b3VsZCBiZSB0byBpbnRyb2R1Y2UgYSAKICAgICAgZ2F0 ZXdheSBjb250cm9sbGVyIHBlciBwYWlyIG9mIGdhdGV3YXlzLCBpbiBvcmRlciB0byBoYW5kbGUg YmktCiAgICAgIGRpcmVjdGlvbmFsIHNlc3Npb25zIGJ1dCBub3QgdHJ5IHRvIGRlYWwgd2l0aCBt b3JlIGNvbXBsZXggCiAgICAgIHNlc3Npb25zIHRoYXQgaW5jbHVkZSBmbG93cyBmcm9tIGFuIGFy Yml0cmFyeSBudW1iZXIgb2YgCiAgICAgIGFnZ3JlZ2F0ZXMuICAKCiAgIG8gZG8gcHJlLWVtcHRp b24gJ3Nsb3dseScuIEFzIGluIHRoZSAiYmVhdCBkb3duIiBzb2x1dGlvbiA0LCB0aGlzIAogICAg ICB3b3VsZCByZWR1Y2UgdGhlIGltcGFjdCBvZiB0aGlzIGxpbWl0YXRpb24uIFRoZSBkb3duc2lk ZSBpcyB0aGF0IAogICAgICB0aGUgb3ZlcmFsbCBwcmUtZW1wdGlvbiBpcyBzbG93ZXIsIGFuZCB0 aGVyZWZvcmUgcm91dGVyKHMpIHdpbGwgYmUgCiAgICAgIGNvbmdlc3RlZCBsb25nZXIuICAgCgoK CgoKCgoKCgoKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAy MDA3ICAgICAgICAgICAgICAgIFtQYWdlIDM2XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVw bG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBv IGVhY2ggaW5ncmVzcyBnYXRld2F5ICdsb29zZWx5IGNvb3JkaW5hdGVzJyB3aXRoIG90aGVyIGdh dGV3YXlzIGl0cyAKICAgICAgZGVjaXNpb24gYWJvdXQgd2hpY2ggc3BlY2lmaWMgZmxvd3MgdG8g cHJlLWVtcHQuIEVhY2ggZ2F0ZXdheSAKICAgICAgbnVtYmVycyBmbG93cyBpbiB0aGUgb3JkZXIg dGhleSBhcnJpdmUgKG5vdGUgdGhhdCB0aGlzIG51bWJlciBoYXMgCiAgICAgIG5vIG1lYW5pbmcg b3V0c2lkZSB0aGUgZ2F0ZXdheSksIGFuZCB3aGVuIHByZS1lbXB0aW5nIGZsb3dzLCB0aGUgCiAg ICAgIG1vc3QgcmVjZW50IChvciBtb3N0IHJlY2VudCBsb3cgcHJpb3JpdHkgZmxvdykgaXMgc2Vs ZWN0ZWQgZm9yIAogICAgICBwcmUtZW1wdGlvbjsgdGhlIGdhdGV3YXkgdGhlbiB3b3JrcyBiYWNr d2FyZHMgc2VsZWN0aW5nIGFzIG1hbnkgCiAgICAgIGZsb3dzIGFzIG5lZWRlZC4gR2F0ZXdheXMg d2lsbCB0aGVyZWZvcmUgdGVuZCB0byBwcmUtZW1wdCBmbG93cyAKICAgICAgdGhhdCBhcmUgcGFy dCBvZiB0aGUgc2FtZSBzZXNzaW9uIChhcyB0aGV5IHdlcmUgYWRtaXR0ZWQgYXQgdGhlIAogICAg ICBzYW1lIHRpbWUpLiBPZiBjb3Vyc2UgdGhpcyBpc24ndCBndWFyYW50ZWVkIGZvciBzZXZlcmFs IHJlYXNvbnMsIAogICAgICBmb3IgaW5zdGFuY2UgZ2F0ZXdheSBBJ3MgbW9zdCByZWNlbnQgYmkt ZGlyZWN0aW9uYWwgc2Vzc2lvbnMgbWF5IAogICAgICBiZSB3aXRoIGdhdGV3YXkgQywgd2hlcmVh cyBnYXRld2F5IEIncyBhcmUgd2l0aCBnYXRld2F5IEEgKHNvIAogICAgICBnYXRld2F5IEEgd2ls bCBwcmUtZW1wdCBBLXRvLUMgZmxvd3MgYW5kIGdhdGV3YXkgQiB3aWxsIHByZS1lbXB0IAogICAg ICBCLXRvLUEgZmxvd3MpLiBSYXRoZXIgdGhhbiBwcmUtZW1wdGluZyB0aGUgbW9zdCByZWNlbnQg KGxvdyAKICAgICAgcHJpb3JpdHkpIGZsb3csIGFuIGFsdGVybmF0aXZlIGFsZ29yaXRobSAoZm9y IGZ1cnRoZXIgc3R1ZHkpIG1heSAKICAgICAgYmUgdG8gc2VsZWN0IGZsb3dzIGJhc2VkIG9uIGEg aGFzaCBvZiBwYXJ0aWN1bGFyIGZpZWxkcyBpbiB0aGUgCiAgICAgIHBhY2tldCwgc3VjaCB0aGF0 IGJvdGggZ2F0ZXdheXMgcHJvZHVjZSB0aGUgc2FtZSBoYXNoIGZvciBmbG93cyBvZiAKICAgICAg dGhlIHNhbWUgYmktZGlyZWN0aW9uYWwgc2Vzc2lvbi4gV2UgYmVsaWV2ZSB0aGF0IHRoaXMgYXBw cm9hY2ggCiAgICAgIHNob3VsZCBiZSBpbnZlc3RpZ2F0ZWQgZnVydGhlci4gCgogICAgCgogICAg CgogICAgCgo1LjQuIEdsb2JhbCBmYWlybmVzcyAKCiAgIFRoZSBsaW1pdGF0aW9uIGhlcmUgaXMg dGhhdCAnaGlnaCBwcmlvcml0eScgdHJhZmZpYyBtYXkgYmUgcHJlLWVtcHRlZCAKICAgKG9yIG5v dCBhZG1pdHRlZCkgd2hlbiBhIGdsb2JhbCBkZWNpc2lvbiB3b3VsZCBpbnN0ZWFkIHByZS1lbXB0 IChvciAKICAgbm90IGFkbWl0KSAnbG93ZXIgcHJpb3JpdHknIHRyYWZmaWMgb24gYSBkaWZmZXJl bnQgYWdncmVnYXRlLiAKCiAgIEltYWdpbmUgdGhlIGZvbGxvd2luZyBzY2VuYXJpbyAoZXh0cmVt ZSB0byBpbGx1c3RyYXRlIHRoZSBwb2ludCAKICAgY2xlYXJseSkuIEFnZ3JlZ2F0ZV9hIGlzIGFs bCBBc3N1cmVkIFNlcnZpY2VzIChNTFBQKSB0cmFmZmljLCB3aGlsc3QgCiAgIGFnZ3JlZ2F0ZV9i IGlzIGFsbCBvcmRpbmFyeSB0cmFmZmljIChpLmUuIGNvbXBhcmF0aXZlbHkgbG93IAogICBwcmlv cml0eSkuIFRvZ2V0aGVyIHRoZSB0d28gYWdncmVnYXRlcyBjYXVzZSBhIHJvdXRlciB0byBiZSBh dCB0d2ljZSAKICAgaXRzIGNvbmZpZ3VyZWQtcHJlLWVtcHRpb24tcmF0ZS4gSWRlYWxseSB3ZSdk IGxpa2UgYWxsIG9mIGFnZ3JlZ2F0ZV9iIAogICB0byBiZSBwcmUtZW1wdGVkLCBhcyB0aGVuIGFs bCBvZiBhZ2dyZWdhdGVfYSBjb3VsZCBiZSBjYXJyaWVkLiAKICAgSG93ZXZlciwgdGhlIGFwcHJv YWNoIGRlc2NyaWJlZCBlYXJsaWVyIGluIHRoaXMgZG9jdW1lbnQgbGVhZHMgdG8gCiAgIGhhbGYg b2YgZWFjaCBhZ2dyZWdhdGUgYmVpbmcgcHJlLWVtcHRlZC4gCgoKCgoKCgogCiAKQnJpc2NvZSAg ICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdl IDM3XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04g ICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICAgICAgICAgICAgICAgICAgICAgIElBUl9i PTEgCiAgICAgICAgICAgICAgICAgICAgICAgICB2IAogICAgICAgICAgICAgICAgICAgICAgICAg diAKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgCiAgIElBUl9h PTEgLS0tLT4tLS0tLXwgQ1BSPTEgfC0tLS0tPiBTQVJfYT0wLjUgCiAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgfCAKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgIHYgCiAgICAgICAgICAgICAgICAgICAgICAgICB2 IAogICAgICAgICAgICAgICAgICAgICAgIFNBUl9hPTAuNSAKICAgIAogICBGaWd1cmUgNTogU2Nl bmFyaW8gdG8gaWxsdXN0cmF0ZSAnZ2xvYmFsIGZhaXJuZXNzJyBsaW1pdGF0aW9uIAogICAgCgog ICBTaW1pbGFybHksIGZvciBhZG1pc3Npb24gY29udHJvbCAtIFNlY3Rpb24gNC4xIGRlc2NyaWJl cyBob3cgaWYgdGhlIAogICBDb25nZXN0aW9uLUxldmVsLUVzdGltYXRlIGlzIGdyZWF0ZXIgdGhh biB0aGUgQ0xFLXRocmVzaG9sZCBhbGwgbmV3IAogICBzZXNzaW9ucyBhcmUgcmVmdXNlZC4gQnV0 IGl0IGlzIHVuc2F0aXNmYWN0b3J5IHRvIGJsb2NrIGVtZXJnZW5jeSAKICAgY2FsbHMsIGZvciBp bnN0YW5jZS4gIAoKICAgIAoKICAgUG90ZW50aWFsIHNvbHV0aW9uczogCgogICBvIGluIHRoZSBh ZG1pc3Npb24gY29udHJvbCBjYXNlLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFuIAogICAgICAn ZW1lcmdlbmN5IC8gQXNzdXJlZCBTZXJ2aWNlcycgY2FsbCBpcyBhZG1pdHRlZCBpbW1lZGlhdGVs eSBldmVuIAogICAgICBpZiB0aGUgQ0xFLXRocmVzaG9sZCBpcyBleGNlZWRlZC4gVXN1YWxseSB0 aGUgbmV0d29yayBjYW4gYWN0dWFsbHkgCiAgICAgIGhhbmRsZSB0aGUgYWRkaXRpb25hbCBtaWNy b2Zsb3csIGJlY2F1c2UgdGhlcmUgaXMgYSBzYWZldHkgbWFyZ2luIAogICAgICBiZXR3ZWVuIHRo ZSBjb25maWd1cmVkLWFkbWlzc2lvbi1yYXRlIGFuZCB0aGUgY29uZmlndXJlZC1wcmUtCiAgICAg IGVtcHRpb24tcmF0ZS4gTm9ybWFsIGNhbGwgdGVybWluYXRpb24gYmVoYXZpb3VyIHdpbGwgc29v biBicmluZyAKICAgICAgdGhlIHRyYWZmaWMgbGV2ZWwgZG93biBiZWxvdyB0aGUgY29uZmlndXJl ZC1hZG1pc3Npb24tcmF0ZS4gCiAgICAgIEhvd2V2ZXIsIGluIGV4Y2VwdGlvbmFsIGNpcmN1bXN0 YW5jZXMgdGhlICdlbWVyZ2VuY3kgLyBoaWdoZXIgCiAgICAgIHByZWNlZGVuY2UnIGNhbGwgbWF5 IGNhdXNlIHRoZSB0cmFmZmljIGxldmVsIHRvIGV4Y2VlZCB0aGUgCiAgICAgIGNvbmZpZ3VyZWQt cHJlLWVtcHRpb24tcmF0ZTsgdGhlbiB0aGUgdXN1YWwgcHJlLWVtcHRpb24gbWVjaGFuaXNtIAog ICAgICB3aWxsIHByZS1lbXB0IGVub3VnaCAobm9uICdlbWVyZ2VuY3kgLyBoaWdoZXIgcHJlY2Vk ZW5jZScpIAogICAgICBtaWNyb2Zsb3dzIHRvIGJyaW5nIHRoZSB0b3RhbCB0cmFmZmljIGJhY2sg dW5kZXIgdGhlIGNvbmZpZ3VyZWQtCiAgICAgIHByZS1lbXB0aW9uLXJhdGUuIAoKICAgbyBhbGwg ZWdyZXNzIGdhdGV3YXlzIHJlcG9ydCB0byBhIGdsb2JhbCBjb29yZGluYXRvciB0aGF0IG1ha2Vz IAogICAgICBkZWNpc2lvbnMgYWJvdXQgd2hhdCBmbG93cyB0byBwcmUtZW1wdC4gSG93ZXZlciB0 aGlzIHNvbHV0aW9uIGFkZHMgCiAgICAgIGNvbXBsZXhpdHkgYW5kIHByb2JhYmx5IGlzbid0IHNj YWxhYmxlLCBidXQgaXQgbWF5IGJlIGFuIG9wdGlvbiBpbiAKICAgICAgc29tZSBzY2VuYXJpb3Ms IGZvciBleGFtcGxlIHdoZXJlIGdhdGV3YXlzIGFyZW4ndCBoYW5kbGluZyB0b28gCiAgICAgIG1h bnkgZmxvd3MgKGJ1dCBub3RlIHRoYXQgdGhpcyBicmVha3MgdGhlIGFnZ3JlZ2F0aW9uIGFzc3Vt cHRpb24gCiAgICAgIG9mIFNlY3Rpb24gMi4yKS4gIAoKCgoKIAogCkJyaXNjb2UgICAgICAgICAg ICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzOF0gCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAg IE9jdG9iZXIgMjAwNiAKICAgIAoKICAgbyBpbnRyb2R1Y2UgYSBoZXVyaXN0aWMgcnVsZTogYmVm b3JlIHByZS1lbXB0aW5nIGEgJ2hpZ2ggcHJpb3JpdHknIAogICAgICBmbG93IHRoZSBlZ3Jlc3Mg Z2F0ZXdheSBzaG91bGQgd2FpdCB0byBzZWUgaWYgc3VmZmljaWVudCAobG93ZXIgCiAgICAgIHBy aW9yaXR5KSB0cmFmZmljIGlzIHByZS1lbXB0ZWQgb24gb3RoZXIgYWdncmVnYXRlcy4gVGhpcyBp cyBhIAogICAgICByZWFzb25hYmxlIG9wdGlvbi4gCgogICBvIGVuaGFuY2UgdGhlIGZ1bmN0aW9u YWxpdHkgb2YgYWxsIHRoZSBpbnRlcmlvciByb3V0ZXJzLCBzbyB0aGV5IGNhbiAKICAgICAgZGV0 ZWN0IHRoZSBwcmlvcml0eSBvZiBhIHBhY2tldCwgYW5kIHRoZW4gZGlmZmVyZW50aWFsbHkgbWFy ayAKICAgICAgdGhlbS4gQXMgd2VsbCBhcyBhZGRpbmcgY29tcGxleGl0eSwgaW4gZ2VuZXJhbCB0 aGlzIHdvdWxkIGJlIGFuIAogICAgICB1bmFjY2VwdGFibGUgc2VjdXJpdHkgcmlzayBmb3IgTUxQ UCB0cmFmZmljLCBzaW5jZSBvbmx5IGNvbnRyb2xsZWQgCiAgICAgIG5vZGVzIChsaWtlIGdhdGV3 YXlzKSBzaG91bGQga25vdyB3aGljaCBwYWNrZXRzIGFyZSBoaWdoIHByaW9yaXR5LCAKICAgICAg YXMgdGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgYWJ1c2VkIGJ5IGFuIGF0dGFja2VyLiAgCgogICBv IGRvIG5vdGhpbmcsIGkuZS4gYWNjZXB0IHRoZSBsaW1pdGF0aW9uLiBXaGlsc3QgaXQncyB1bmxp a2VseSB0aGF0IAogICAgICBoaWdoIHByaW9yaXR5IGNhbGxzIHdpbGwgYmUgcXVpdGUgc28gdW5i YWxhbmNlZCBhcyBpbiB0aGUgc2NlbmFyaW8gCiAgICAgIGFib3ZlLCBqdXN0IGFjY2VwdGluZyB0 aGlzIGxpbWl0YXRpb24gbWF5IGJlIHJpc2t5LiBUaGUgc29ydHMgb2YgCiAgICAgIHNpdHVhdGlv bnMgdGhhdCBjYXVzZSByb3V0ZXJzIHRvIHN0YXJ0IHByZS1lbXB0aW9uIG1hcmtpbmcgYXJlIAog ICAgICBhbHNvIGxpa2VseSB0byBjYXVzZSBhIHN1cmdlIG9mIGVtZXJnZW5jeSAvIE1MUFAgY2Fs bHMuICAKCiAgICAKCiAgICAKCjUuNS4gRmxhc2ggY3Jvd2RzIAoKICAgVGhpcyBsaW1pdGF0aW9u IGNvbmNlcm5zIGFkbWlzc2lvbiBjb250cm9sIGFuZCBhcmlzZXMgYmVjYXVzZSB0aGVyZSAKICAg aXMgYSB0aW1lIGxhZyBiZXR3ZWVuIHRoZSBhZG1pc3Npb24gY29udHJvbCBkZWNpc2lvbiAod2hp Y2ggZGVwZW5kcyAKICAgb24gdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgZHVyaW5nIFJT VlAgc2lnbmFsbGluZyBkdXJpbmcgY2FsbCAKICAgc2V0LXVwKSBhbmQgd2hlbiB0aGUgZGF0YSBp cyBhY3R1YWxseSBzZW50IChhZnRlciB0aGUgY2FsbGVkIHBhcnR5IAogICBoYXMgYW5zd2VyZWQp LiBJbiBQU1ROIHRlcm1zIHRoaXMgaXMgdGhlIHRpbWUgdGhlIHBob25lIHJpbmdzLiAKICAgTm9y bWFsbHkgdGhlIHRpbWUgbGFnIGRvZXNuJ3QgbWF0dGVyIG11Y2ggYmVjYXVzZSAoMSkgaW4gdGhl IENMLQogICByZWdpb24gdGhlcmUgYXJlIG1hbnkgZmxvd3MgYW5kIHRoZXkgdGVybWluYXRlIGFu ZCBhcmUgYW5zd2VyZWQgYXQgCiAgIHJvdWdobHkgdGhlIHNhbWUgcmF0ZSwgYW5kICgyKSB0aGUg bmV0d29yayBjYW4gc3RpbGwgb3BlcmF0ZSBzYWZlbHkgCiAgIHdoZW4gdGhlIHRyYWZmaWMgbGV2 ZWwgaXMgc29tZSBtYXJnaW4gYWJvdmUgdGhlIGNvbmZpZ3VyZWQtYWRtaXNzaW9uLQogICByYXRl LiAKCiAgIEEgJ2ZsYXNoIGNyb3dkJyBvY2N1cnMgd2hlbiBzb21ldGhpbmcgY2F1c2VzIG1hbnkg Y2FsbHMgdG8gYmUgCiAgIGluaXRpYXRlZCBpbiBhIHNob3J0IHBlcmlvZCBvZiB0aW1lIC0gZm9y IGluc3RhbmNlIGEgJ3RlbGUtdm90ZScuIFNvIAogICB0aGVyZSBpcyBhIGRhbmdlciB0aGF0IGEg J2ZsYXNoJyBvZiBjYWxscyBpcyBhY2NlcHRlZCwgYnV0IHdoZW4gdGhlIAogICBjYWxscyBhcmUg YW5zd2VyZWQgYW5kIGRhdGEgZmxvd3MgdGhlIHRyYWZmaWMgb3ZlcmxvYWRzIHRoZSBuZXR3b3Jr LiAKICAgVGhlcmVmb3JlIHBvdGVudGlhbGx5IHRoZSAnYWRkaXRpb25hbCBsb2FkJyBhc3N1bXB0 aW9uIG9mIFNlY3Rpb24gMi4yIAogICBkb2Vzbid0IGhvbGQuICAKCiAgIFBvdGVudGlhbCBzb2x1 dGlvbnM6IAoKCgoKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzOV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERl cGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAg byBUaGUgc2ltcGxlc3Qgb3B0aW9uIGlzIHRvIGRvIG5vdGhpbmc7IGFuIG9wZXJhdG9yIHJlbGll cyBvbiB0aGUgCiAgICAgIHByZS1lbXB0aW9uIG1lY2hhbmlzbSBpZiB0aGVyZSBpcyBhIHByb2Js ZW0uIFRoaXMgZG9lc24ndCBzZWVtIGEgCiAgICAgIGdvb2QgY2hvaWNlLCBhcyAnZmxhc2ggY3Jv d2RzJyBhcmUgcmVhc29uYWJseSBjb21tb24gb24gdGhlIFBTVE4sIAogICAgICB1bmxlc3MgdGhl IG9wZXJhdG9yIGNhbiBlbnN1cmUgdGhhdCBuZWFybHkgYWxsICdmbGFzaCBjcm93ZCcgCiAgICAg IGV2ZW50cyBhcmUgYmxvY2tlZCBpbiB0aGUgYWNjZXNzIG5ldHdvcmsgYW5kIHNvIGRvIG5vdCBp bXBhY3Qgb24gCiAgICAgIHRoZSBDTC1yZWdpb24uIAoKICAgbyBBIHNlY29uZCBvcHRpb24gaXMg dG8gc2VuZCAnZHVtbXkgZGF0YScgYXMgc29vbiBhcyB0aGUgY2FsbCBpcyAKICAgICAgYWRtaXR0 ZWQsIHRodXMgZWZmZWN0aXZlbHkgcmVzZXJ2aW5nIHRoZSBiYW5kd2lkdGggd2hpbHN0IHdhaXRp bmcgCiAgICAgIGZvciB0aGUgY2FsbGVkIHBhcnR5IHRvIGFuc3dlci4gUmVzZXJ2aW5nIGJhbmR3 aWR0aCBpbiBhZHZhbmNlIAogICAgICBtZWFucyB0aGF0IHRoZSBuZXR3b3JrIGNhbm5vdCBhZG1p dCBhcyBtYW55IGNhbGxzLiBGb3IgZXhhbXBsZSwgCiAgICAgIHN1cHBvc2Ugc2Vzc2lvbnMgbGFz dCAxMDAgc2Vjb25kcyBhbmQgcmluZ2luZyBmb3IgMTAgc2Vjb25kcywgdGhlIAogICAgICBjb3N0 IGlzIGEgMTAlIGxvc3Mgb2YgY2FwYWNpdHkuIEl0IG1heSBiZSBwb3NzaWJsZSB0byBvZmZzZXQg dGhpcyAKICAgICAgc29tZXdoYXQgYnkgaW5jcmVhc2luZyB0aGUgY29uZmlndXJlZC1hZG1pc3Np b24tcmF0ZSBpbiB0aGUgCiAgICAgIHJvdXRlcnMsIGJ1dCBpdCB3b3VsZCBuZWVkIGZ1cnRoZXIg aW52ZXN0aWdhdGlvbi4gQSBjb25jZXJuIHdpdGggCiAgICAgIHRoaXMgJ2R1bW15IGRhdGEnIG9w dGlvbiBpcyB0aGF0IGl0IG1heSBhbGxvdyBhbiBhdHRhY2tlciB0byAKICAgICAgaW5pdGlhdGUg bWFueSBjYWxscyB0aGF0IGFyZSBuZXZlciBhbnN3ZXJlZCAoYnkgYSBjb29wZXJhdGluZyAKICAg ICAgYXR0YWNrZXIpLCBzbyBldmVudHVhbGx5IHRoZSBuZXR3b3JrIHdvdWxkIG9ubHkgYmUgY2Fy cnlpbmcgJ2R1bW15IAogICAgICBkYXRhJy4gVGhlIGF0dGFjayBleHBsb2l0cyB0aGF0IGNoYXJn aW5nIG9ubHkgc3RhcnRzIHdoZW4gdGhlIGNhbGwgCiAgICAgIGlzIGFuc3dlcmVkIGFuZCBub3Qg d2hlbiBpdCBpcyBkaWFsbGVkLiBJdCBtYXkgYmUgcG9zc2libGUgdG8gCiAgICAgIGFsbGV2aWF0 ZSB0aGUgYXR0YWNrIGF0IHRoZSBzZXNzaW9uIGxheWVyIC0gZm9yIGV4YW1wbGUsIHdoZW4gdGhl IAogICAgICBpbmdyZXNzIGdhdGV3YXkgZ2V0cyBhbiBSU1ZQIFBBVEggbWVzc2FnZSBpdCBjaGVj a3MgdGhhdCB0aGUgCiAgICAgIHNvdXJjZSBoYXMgYmVlbiB3ZWxsLWJlaGF2ZWQgcmVjZW50bHk7 IGFuZCBsaW1pdGluZyB0aGUgbWF4aW11bSAKICAgICAgdGltZSB0aGF0IHJpbmdpbmcgY2FuIGxh c3QuIFdlIGJlbGlldmUgdGhhdCBpZiB0aGlzIGF0dGFjayBjYW4gYmUgCiAgICAgIGRlYWx0IHdp dGggdGhlbiB0aGlzIGlzIGEgZ29vZCBvcHRpb24uICAKCiAgIG8gQSB0aGlyZCBvcHRpb24gaXMg dGhhdCB0aGUgZWdyZXNzIGdhdGV3YXkgbGltaXRzIHRoZSByYXRlIGF0IHdoaWNoIAogICAgICBp dCBzZW5kcyBvdXQgdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUsIG9yIGxpbWl0cyB0aGUg cmF0ZSBhdCAKICAgICAgd2hpY2ggY2FsbHMgYXJlIGFjY2VwdGVkIGJ5IHJlcGx5aW5nIHdpdGgg YSBDb25nZXN0aW9uLUxldmVsLQogICAgICBFc3RpbWF0ZSBvZiAxMDAlICh0aGlzIGlzIHRoZSBl cXVpdmFsZW50IG9mICdjYWxsIGdhcHBpbmcnIGluIHRoZSAKICAgICAgUFNUTikuIFRoZXJlIGlz IGEgdHJhZGUtb2ZmLCB3aGljaCB3b3VsZCBuZWVkIHRvIGJlIGludmVzdGlnYXRlZCAKICAgICAg ZnVydGhlciwgYmV0d2VlbiB0aGUgZGVncmVlIG9mIHByb3RlY3Rpb24gYW5kIHBvc3NpYmxlIGFk dmVyc2UgCiAgICAgIHNpZGUtZWZmZWN0cyBsaWtlIHNsb3dpbmcgZG93biBjYWxsIHNldC11cC4g CgogICBvIEEgZmluYWwgb3B0aW9uIGlzIHRvIHJlLXBlcmZvcm0gYWRtaXNzaW9uIGNvbnRyb2wg YmVmb3JlIHRoZSBjYWxsIAogICAgICBpcyBhbnN3ZXJlZC4gVGhlIGluZ3Jlc3MgZ2F0ZXdheSBt b25pdG9ycyBDb25nZXN0aW9uLUxldmVsLQogICAgICBFc3RpbWF0ZSB1cGRhdGVzIHJlY2VpdmVk IGZyb20gZWFjaCBlZ3Jlc3MuIElmIGl0IG5vdGljZXMgdGhhdCBhIAogICAgICBDb25nZXN0aW9u LUxldmVsLUVzdGltYXRlIGhhcyByaXNlbiBhYm92ZSB0aGUgQ0xFLXRocmVzaG9sZCwgdGhlbiAK ICAgICAgaXQgdGVybWluYXRlcyBhbGwgdW5hbnN3ZXJlZCBjYWxscyB0aHJvdWdoIHRoYXQgZWdy ZXNzIChlLmcuIGJ5IAogICAgICBpbnN0cnVjdGluZyB0aGUgc2Vzc2lvbiBwcm90b2NvbCB0byBz dG9wIHRoZSAncmluZ2luZyB0b25lJykuIEZvciAKICAgICAgZXh0cmEgc2FmZXR5IHRoZSBDb25n ZXN0aW9uLUxldmVsLUVzdGltYXRlIGNvdWxkIGJlIHJlLWNoZWNrZWQgCiAgICAgIHdoZW4gdGhl IGNhbGwgaXMgYW5zd2VyZWQuIEEgcG90ZW50aWFsIGRyYXdiYWNrIGZvciBhbiBvcGVyYXRvciAK ICAgICAgdGhhdCB3YW50cyB0byBlbXVsYXRlIHRoZSBQU1ROIGlzIHRoYXQgdGhlIFBTVE4gbmV0 d29yayBuZXZlciAKICAgICAgZHJvcHMgYSAncmluZ2luZycgUFNUTiBjYWxsLiAgCgogICAgCgog CiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDQwXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2Rl bCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICAgCgo1LjYuIFByZS1l bXB0aW5nIHRvbyBmYXN0IAoKICAgQXMgYSBnZW5lcmFsIGlkZWEgaXQgc2VlbXMgZ29vZCB0byBw cmUtZW1wdCBleGNlc3MgZmxvd3MgcmFwaWRseSwgc28gCiAgIHRoYXQgdGhlIGZ1bGwgUW9TIGlz IHJlc3RvcmVkIHRvIHRoZSByZW1haW5pbmcgQ0wgdXNlcnMgYXMgc29vbiBhcyAKICAgcG9zc2li bGUsIGFuZCBwYXJ0aWFsIHNlcnZpY2UgaXMgcmVzdG9yZWQgdG8gbG93ZXIgcHJpb3JpdHkgdHJh ZmZpYyAKICAgY2xhc3NlcyBvbiBzaGFyZWQgbGlua3MuIFRoZXJlZm9yZSB0aGUgcHJlLWVtcHRp b24gbWVjaGFuaXNtIAogICBkZXNjcmliZWQgZWFybGllciBpbiB0aGlzIGRvY3VtZW50IHdvcmtz IGluICdvbmUgc2hvdCcsIGkuZS4gb25lIAogICBtZWFzdXJlbWVudCBpcyBtYWRlIG9mIHRoZSBz dXN0YWluYWJsZS1hZ2dyZWdhdGUtcmF0ZSBhbmQgdGhlIAogICBpbmdyZXNzLWFnZ3JlZ2F0ZS1y YXRlLCBhbmQgdGhlIGV4Y2VzcyBpcyBwcmUtZW1wdGVkIGltbWVkaWF0ZWx5LiAKICAgSG93ZXZl ciwgdGhlcmUgYXJlIHNvbWUgcmVhc29ucyB3aHkgYW4gb3BlcmF0b3IgbWF5IHBvdGVudGlhbGx5 IHdhbnQgCiAgIHRvIHByZS1lbXB0ICdtb3JlIHNsb3dseSc6IAoKICAgbyBUbyBhbGxvdyB0aW1l IHRvIG1vZGlmeSB0aGUgaW5ncmVzcyBnYXRld2F5J3MgcG9saWNlciwgYXMgdGhlIAogICAgICBp bmdyZXNzIHdhbnRzIHRvIGJlIGFibGUgdG8gZHJvcCBhbnkgcGFja2V0cyB0aGF0IGFycml2ZSBm cm9tIGEgCiAgICAgIHByZS1lbXB0ZWQgZmxvdy4gVGhlcmUgd2lsbCBiZSBhIGxpbWl0IG9uIGhv dyBtYW55IG5ldyBmaWx0ZXJzIGFuIAogICAgICBpbmdyZXNzIGdhdGV3YXkgY2FuIGluc3RhbGwg aW4gYSBjZXJ0YWluIHRpbWUgcGVyaW9kLiBPdGhlcndpc2UgCiAgICAgIHRoZSBzb3VyY2UgbWF5 IGNoZWF0IGFuZCBpZ25vcmUgdGhlIGluc3RydWN0aW9uIHRvIGRyb3AgaXRzIGZsb3cuICAKCiAg IG8gVGhlIG9wZXJhdG9yIG1heSBkZWNpZGUgdG8gc2xvdyBkb3duIHByZS1lbXB0aW9uIGluIG9y ZGVyIHRvIAogICAgICBhbWVsaW9yYXRlIHRoZSAnYmVhdCBkb3duJyBhbmQvb3IgJ2JpLWRpcmVj dGlvbmFsIHNlc3Npb25zJyAKICAgICAgbGltaXRhdGlvbnMgKHNlZSBhYm92ZSkgCgogICBvIFRv IGhlbHAgY29tYmF0IGluYWNjdXJhY2llcyBpbiBtZWFzdXJlbWVudHMgb2YgdGhlIHN1c3RhaW5h YmxlLQogICAgICBhZ2dyZWdhdGUtcmF0ZSBhbmQgaW5ncmVzcy1hZ2dyZWdhdGUtcmF0ZS4gRm9y IGEgQ0wtcmVnaW9uIHdoZXJlIAogICAgICBpdCdzIGFzc3VtZWQgdGhlcmUgYXJlIG1hbnkgZmxv d3MgaW4gYW4gYWdncmVnYXRlIHRoZXNlIAogICAgICBtZWFzdXJlbWVudHMgY2FuIGJlIG9idGFp bmVkIGluIGEgc2hvcnQgcGVyaW9kIG9mIHRpbWUsIGJ1dCB3aGVyZSAKICAgICAgdGhlcmUgYXJl IGZld2VyIGZsb3dzIGl0IHdpbGwgdGFrZSBsb25nZXIuIAoKICAgbyBUbyBoZWxwIGNvbWJhdCBv dmVyIHByZS1lbXB0aW9uIGJlY2F1c2UsIGR1cmluZyB0aGUgdGltZSBpdCB0YWtlcyAKICAgICAg dG8gcHJlLWVtcHQgZmxvd3MsIG90aGVycyBtYXkgYmUgZW5kaW5nIGFueXdheSAoZWl0aGVyIHRo ZSBjYWxsIAogICAgICBoYXMgbmF0dXJhbGx5IGVuZGVkLCBvciB0aGUgdXNlciBoYW5ncyB1cCBk dWUgdG8gcG9vciBRb1MpLiAKICAgICAgU2xvd2luZyBwcmUtZW1wdGlvbiBtYXkgc2VlbSBjb3Vu dGVyLWludHVpdGl2ZSBoZXJlLCBhcyBpdCBtYWtlcyAKICAgICAgaXQgbW9yZSBsaWtlbHkgdGhh dCBjYWxscyB3aWxsIHRlcm1pbmF0ZSBhbnl3YXkgLSBob3dldmVyIGl0IGFsc28gCiAgICAgIGdp dmVzIHRpbWUgdG8gYWRqdXN0IHRoZSBhbW91bnQgcHJlLWVtcHRlZCB0byB0YWtlIGFjY291bnQg b2YgCiAgICAgIHRoaXMuIAoKICAgbyBFYXJsaWVyIGluIHRoaXMgZG9jdW1lbnQgd2Ugc2FpZCB0 aGF0IGFuIGVncmVzcyBzdGFydHMgbWVhc3VyaW5nIAogICAgICB0aGUgc3VzdGFpbmFibGUtYWdn cmVnYXRlLXJhdGUgaW1tZWRpYXRlbHkgaXQgc2VlcyBhIHNpbmdsZSBwcmUtCiAgICAgIGVtcHRp b24gbWFya2VkIHBhY2tldC4gSG93ZXZlciwgd2hlbiBhIGxpbmsgb3Igcm91dGVyIGZhaWxzIHRo ZSAKICAgICAgbmV0d29yaydzIHVuZGVybHlpbmcgcmVjb3ZlcnkgbWVjaGFuaXNtIHdpbGwga2lj ayBpbiAoZS5nLiAKICAgICAgc3dpdGNoaW5nIHRvIGEgYmFjayB1cCBwYXRoKSwgd2hpY2ggbWF5 IHJlc3VsdCBpbiB0aGUgbmV0d29yayAKICAgICAgYWdhaW4gYmVpbmcgYWJsZSB0byBzdXBwb3J0 IGFsbCB0aGUgdHJhZmZpYy4gCgogICAgCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDQxXSAKDApJbnRlcm5ldC1E cmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAy MDA2IAogICAgCgogICAgCgogICBQb3RlbnRpYWwgc29sdXRpb25zIAoKICAgbyBUbyBjb21iYXQg dGhlIGZpbmFsIGlzc3VlLCB0aGUgZWdyZXNzIGNvdWxkIG1lYXN1cmUgdGhlIAogICAgICBzdXN0 YWluYWJsZS1hZ2dyZWdhdGUtcmF0ZSBvdmVyIGEgbG9uZ2VyIHRpbWUgcGVyaW9kIHRoYW4gdGhl IAogICAgICBuZXR3b3JrIHJlY292ZXJ5IHRpbWUgKHNheSAxMDBtcyB2cy4gNTBtcykuIElmIGl0 IGRldGVjdHMgbm8gcHJlLQogICAgICBlbXB0aW9uIG1hcmtlZCBwYWNrZXRzIHRvd2FyZHMgdGhl IGVuZCBvZiBpdHMgbWVhc3VyZW1lbnQgcGVyaW9kIAogICAgICAoc2F5IGluIHRoZSBsYXN0IDMw IG1zKSB0aGVuIGl0IGRvZXNuJ3Qgc2VuZCBhIHByZS1lbXB0aW9uIGFsZXJ0IAogICAgICBtZXNz YWdlIHRvIHRoZSBpbmdyZXNzLiAKCiAgIG8gV2Ugc3VnZ2VzdCB0aGF0IG9wdGlvbmFsbHkgKHRo ZSBjaG9pY2Ugb2YgdGhlIG9wZXJhdG9yKSBwcmUtCiAgICAgIGVtcHRpb24gaXMgc2xvd2VkIGJ5 IHByZS1lbXB0aW5nIHRyYWZmaWMgaW4gc2V2ZXJhbCByb3VuZHMgcmF0aGVyIAogICAgICB0aGFu IGluIG9uZSBzaG90LiBPbmUgcG9zc2libGUgYWxnb3JpdGhtIGlzIHRvIHByZS1lbXB0IG1vc3Qg b2YgCiAgICAgIHRoZSB0cmFmZmljIGluIHRoZSBmaXJzdCByb3VuZCBhbmQgdGhlIHJlc3QgaW4g dGhlIHNlY29uZCByb3VuZDsgCiAgICAgIHRoZSBhbW91bnQgcHJlLWVtcHRlZCBpbiB0aGUgc2Vj b25kIHJvdW5kIGlzIGluZmx1ZW5jZWQgYnkgYm90aCAKICAgICAgdGhlIGZpcnN0IGFuZCBzZWNv bmQgcm91bmQgbWVhc3VyZW1lbnRzOiAgICAgKiBSb3VuZCAxOiBwcmUtZW1wdCBoIAogICAgICAq IFNfMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoZXJlIDAuNSA8PSBoIDw9IDEg ICAgICAgICAgICAgICAgIAogICAgICB3aGVyZSBTXzEgaXMgdGhlIGFtb3VudCB0aGUgbm9ybWFs IG1lY2hhbmlzbSBjYWxjdWxhdGVzIHRoYXQgaXQgCiAgICAgIHNob3VsZCBzaGVkLCBpLmUuIHtp bmdyZXNzLWFnZ3JlZ2F0ZS1yYXRlIC0gc3VzdGFpbmFibGUtYWdncmVnYXRlLQogICAgICByYXRl fSAgICAgICAgKiBSb3VuZCAyOiBwcmUtZW1wdCBQcmVkaWN0ZWQtU18yIC0gaCAqIChQcmVkaWN0 ZWQtCiAgICAgIFNfMiAtIE1lYXN1cmVkLVNfMikgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICB3aGVyZSBQcmVkaWN0ZWQtU18yID0gKDEtaCkqU18x ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm90ZSAKICAgICAgdGhhdCB0aGUgc2Vjb25k IG1lYXN1cmVtZW50IHNob3VsZCBiZSBtYWRlIHdoZW4gc3VmZmljaWVudCB0aW1lIAogICAgICBo YXMgZWxhcHNlZCBmb3IgdGhlIGZpcnN0IHJvdW5kIG9mIHByZS1lbXB0aW9uIHRvIGhhdmUgaGFw cGVuZWQuIAogICAgICBPbmUgaWRlYSB0byBhY2hpZXZlIHRoaXMgaXMgZm9yIHRoZSBlZ3Jlc3Mg Z2F0ZXdheSB0byBjb250aW51b3VzbHkgCiAgICAgIG1lYXN1cmUgYW5kIHJlcG9ydCBpdHMgc3Vz dGFpbmFibGUtYWdncmVnYXRlLXJhdGUsIGluIChzYXkpIDEwMG1zIAogICAgICB3aW5kb3dzLiBU aGVyZWZvcmUgdGhlIGluZ3Jlc3MgZ2F0ZXdheSBrbm93cyB3aGVuIHRoZSBlZ3Jlc3MgCiAgICAg IGdhdGV3YXkgbWFkZSBpdHMgbWVhc3VyZW1lbnQgKGFzc3VtaW5nIHRoZSByb3VuZCB0cmlwIHRp bWUgaXMgCiAgICAgIGtub3duKS4gVGhlcmVmb3JlIHRoZSBpbmdyZXNzIGdhdGV3YXkga25vd3Mg d2hlbiBtZWFzdXJlbWVudHMgCiAgICAgIHNob3VsZCByZWZsZWN0IHRoYXQgaXQgaGFzIHByZS1l bXB0ZWQgZmxvd3MuICAKCiAKCiAKCjUuNy4gT3RoZXIgcG90ZW50aWFsIGV4dGVuc2lvbnMgCgog ICBJbiB0aGlzIHNlY3Rpb24gd2UgZGlzY3VzcyBzb21lIG90aGVyIHBvdGVudGlhbCBleHRlbnNp b25zIG5vdCAKICAgYWxyZWFkeSBjb3ZlcmVkIGFib3ZlLiAKCjUuNy4xLiBUdW5uZWxsaW5nIAoK ICAgSXQgaXMgcG9zc2libGUgdG8gdHVubmVsIGFsbCBDTCBwYWNrZXRzIGFjcm9zcyB0aGUgQ0wt cmVnaW9uLiAKICAgQWx0aG91Z2ggdGhlcmUgaXMgYSBjb3N0IG9mIHR1bm5lbGxpbmcgKGFkZGl0 aW9uYWwgaGVhZGVyIG9uIGVhY2ggCiAgIHBhY2tldCwgYWRkaXRpb25hbCBwcm9jZXNzaW5nIGF0 IHR1bm5lbCBpbmdyZXNzIGFuZCBlZ3Jlc3MpLCB0aGVyZSAKICAgYXJlIHRocmVlIHJlYXNvbnMg aXQgbWF5IGJlIGludGVyZXN0aW5nLiAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJl cyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0Ml0gCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAw NiAKICAgIAoKICAgRUNNUDogIAoKICAgVHVubmVsbGluZyBpcyBvbmUgb2YgdGhlIHBvc3NpYmxl IHNvbHV0aW9ucyBnaXZlbiBlYXJsaWVyIGluIFNlY3Rpb24gCiAgIDUuMSBvbiBFcXVhbCBDb3N0 IE11bHRpcGF0aCBSb3V0aW5nIChFQ01QKS4gCgogICBJbmdyZXNzIGdhdGV3YXkgZGV0ZXJtaW5h dGlvbjogCgogICBJZiBwYWNrZXRzIGFyZSB0dW5uZWxsZWQgZnJvbSBpbmdyZXNzIGdhdGV3YXkg dG8gZWdyZXNzIGdhdGV3YXksIHRoZSAKICAgZWdyZXNzIGdhdGV3YXkgY2FuIHZlcnkgZWFzaWx5 IGRldGVybWluZSBpbiB0aGUgZGF0YSBwYXRoIHdoaWNoIAogICBpbmdyZXNzIGdhdGV3YXkgYSBw YWNrZXQgY29tZXMgZnJvbSAoYnkgc2ltcGx5IGxvb2tpbmcgYXQgdGhlIHNvdXJjZSAKICAgYWRk cmVzcyBvZiB0aGUgdHVubmVsIGhlYWRlcikuIFRoaXMgY2FuIGZhY2lsaXRhdGUgb3BlcmF0aW9u cyBzdWNoIGFzIAogICBjb21wdXRpbmcgdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgb24g YSBwZXIgaW5ncmVzcyBnYXRld2F5IAogICBiYXNpcy4gCgogICBFbmQtdG8tZW5kIEVDTjogCgog ICBUaGUgRUNOIGZpZWxkIGlzIHVzZWQgZm9yIFBDTiBtYXJraW5nIChzZWUgW1BDTl0gZm9yIGRl dGFpbHMpLCBhbmQgc28gCiAgIGl0IG5lZWRzIHRvIGJlIHJlLXNldCBieSB0aGUgZWdyZXNzIGdh dGV3YXkgdG8gd2hhdGV2ZXIgaGFzIGJlZW4gCiAgIGFncmVlZCBhcyBhcHByb3ByaWF0ZSBmb3Ig dGhlIG5leHQgZG9tYWluLiBUaGVyZWZvcmUgaWYgYSBwYWNrZXQgCiAgIGFycml2ZXMgYXQgdGhl IGluZ3Jlc3MgZ2F0ZXdheSB3aXRoIGl0cyBFQ04gZmllbGQgYWxyZWFkeSBzZXQgKGkuZS4gCiAg IG5vdCAnMDAnKSwgaXQgbWF5IGxlYXZlIHRoZSBlZ3Jlc3MgZ2F0ZXdheSB3aXRoIGEgZGlmZmVy ZW50IHZhbHVlLiAKICAgSGVuY2UgdGhlIGVuZC10by1lbmQgbWVhbmluZyBvZiB0aGUgRUNOIGZp ZWxkIGlzIGxvc3QuICAKCiAgIEl0IGlzIG9wZW4gdG8gZGViYXRlIHdoZXRoZXIgZW5kLXRvLWVu ZCBjb25nZXN0aW9uIGNvbnRyb2wgaXMgZXZlciAKICAgbmVjZXNzYXJ5IHdpdGhpbiBhbiBlbmQt dG8tZW5kIHJlc2VydmF0aW9uLiBCdXQgaWYgYSBnZW51aW5lIG5lZWQgaXMgCiAgIGlkZW50aWZp ZWQgZm9yIGVuZC10by1lbmQgRUNOIHNlbWFudGljcyB3aXRoaW4gYSByZXNlcnZhdGlvbiwgdGhl biAKICAgb25lIHNvbHV0aW9uIGlzIHRvIHR1bm5lbCBDTCBwYWNrZXRzIGFjcm9zcyB0aGUgQ0wt cmVnaW9uLiBXaGVuIHRoZSAKICAgZWdyZXNzIGdhdGV3YXkgZGVjYXBzdWxhdGVzIHRoZW0gdGhl IG9yaWdpbmFsIEVDTiBmaWVsZCBpcyByZWNvdmVyZWQuICAKCiAKCjUuNy4yLiBNdWx0aS1kb21h aW4gYW5kIG11bHRpLW9wZXJhdG9yIHVzYWdlIAoKICAgVGhpcyBwb3RlbnRpYWwgZXh0ZW5zaW9u IHdvdWxkIGVsaW1pbmF0ZSB0aGUgdHJ1c3QgYXNzdW1wdGlvbiAKICAgKFNlY3Rpb24gMi4yKSwg c28gdGhhdCB0aGUgQ0wtcmVnaW9uIGNvdWxkIGNvbnNpc3Qgb2YgbXVsdGlwbGUgCiAgIGRvbWFp bnMgcnVuIGJ5IGRpZmZlcmVudCBvcGVyYXRvcnMgdGhhdCBkaWQgbm90IHRydXN0IGVhY2ggb3Ro ZXIuIAogICBUaGVuIG9ubHkgdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBnYXRld2F5cyBvZiB0aGUg Q0wtcmVnaW9uIHdvdWxkIHRha2UgCiAgIHBhcnQgaW4gdGhlIGFkbWlzc2lvbiBjb250cm9sIHBy b2NlZHVyZSwgaS5lLiBhdCB0aGUgaW5ncmVzcyB0byB0aGUgCiAgIGZpcnN0IGRvbWFpbiBhbmQg dGhlIGVncmVzcyBmcm9tIHRoZSBmaW5hbCBkb21haW4uIFRoZSBib3JkZXIgcm91dGVycyAKICAg YmV0d2VlbiBvcGVyYXRvcnMgd2l0aGluIHRoZSBDTC1yZWdpb24gd291bGQgb25seSBoYXZlIHRv IGRvIGJ1bGsgCiAgIGFjY291bnRpbmcgLSB0aGV5IHdvdWxkbid0IGRvIHBlciBtaWNyb2Zsb3cg bWV0ZXJpbmcgYW5kIHBvbGljaW5nLCAKICAgYW5kIHRoZXkgd291bGRuJ3QgdGFrZSBwYXJ0IGlu IHNpZ25hbCBwcm9jZXNzaW5nIG9yIGhvbGQgcGVyIGZsb3cgCiAgIHN0YXRlIFtCcmlzY29lXS4g W1JlLWZlZWRiYWNrXSBleHBsYWlucyBob3cgYSBkb3duc3RyZWFtIGRvbWFpbiBjYW4gCiAgIHBv bGljZSB0aGF0IGl0cyB1cHN0cmVhbSBkb21haW4gZG9lcyBub3QgJ2NoZWF0JyBieSBhZG1pdHRp bmcgdHJhZmZpYyAKICAgd2hlbiB0aGUgZG93bnN0cmVhbSBwYXRoIGlzIGNvbmdlc3RlZC4gW1Jl LVBDTl0gcHJvcG9zZXMgaG93IHRvIAogICBhY2hpZXZlIHRoaXMgd2l0aCB0aGUgaGVscCBvZiBh bm90aGVyIHJlY2VudGx5IHByb3Bvc2VkIGV4dGVuc2lvbiB0byAKICAgRUNOLCBpbnZvbHZpbmcg cmUtZWNob2luZyBFQ04gZmVlZGJhY2sgW1JlLUVDTl0uICAgCiAKIApCcmlzY29lICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNDNdIAoM CkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAg ICBPY3RvYmVyIDIwMDYgCiAgICAKCjUuNy4zLiBQcmVmZXJlbnRpYWwgZHJvcHBpbmcgb2YgcHJl LWVtcHRpb24gbWFya2VkIHBhY2tldHMgCgogICBXaGVuIHRoZSByYXRlIG9mIHJlYWwtdGltZSB0 cmFmZmljIGluIHRoZSBzcGVjaWZpZWQgY2xhc3MgZXhjZWVkcyB0aGUgCiAgIG1heGltdW0gY29u ZmlndXJlZCByYXRlLCB0aGVuIGEgcm91dGVyIGhhcyB0byBkcm9wIHNvbWUgcGFja2V0KHMpIAog ICBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhlbSBvbiB0aGUgb3V0LWdvaW5nIGxpbmsuIE5vdyB3 aGVuIHRoZSBlZ3Jlc3MgCiAgIGdhdGV3YXkgbWVhc3VyZXMgdGhlIFN1c3RhaW5hYmxlLUFnZ3Jl Z2F0ZS1SYXRlLCBuZWl0aGVyIGRyb3BwZWQgCiAgIHBhY2tldHMgbm9yIHByZS1lbXB0aW9uIG1h cmtlZCBwYWNrZXRzIGNvbnRyaWJ1dGUgdG8gaXQuIERyb3BwaW5nIAogICBub24tcHJlLWVtcHRp b24tbWFya2VkIHBhY2tldHMgdGhlcmVmb3JlIHJlZHVjZXMgdGhlIG1lYXN1cmVkIAogICBTdXN0 YWluYWJsZS1BZ2dyZWdhdGUtUmF0ZSBiZWxvdyBpdHMgdHJ1ZSB2YWx1ZS4gVGh1cyBhIHJvdXRl ciBzaG91bGQgCiAgIHByZWZlcmVudGlhbGx5IGRyb3AgcHJlLWVtcHRpb24gbWFya2VkIHBhY2tl dHMuICAKCiAgIE5vdGUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgb3BlcmF0b3IgZG9l c24ndCBzZXQgdGhlIAogICBjb25maWd1cmVkLXByZS1lbXB0aW9uLXJhdGUgZXF1YWwgdG8gdGhl IHJhdGUgYXQgd2hpY2ggcGFja2V0cyBzdGFydCAKICAgYmVpbmcgZHJvcHBlZCAoZm9yIHRoZSBz cGVjaWZpZWQgcmVhbC10aW1lIHNlcnZpY2UgY2xhc3MpLiBPdGhlcndpc2UgCiAgIHRoZSBlZ3Jl c3MgZ2F0ZXdheSBtYXkgbmV2ZXIgc2VlIGEgcHJlLWVtcHRpb24gbWFya2VkIHBhY2tldCBhbmQg c28gCiAgIHdvbid0IGJlIHRyaWdnZXJlZCBpbnRvIHRoZSBQcmUtZW1wdGlvbiBBbGVydCBzdGF0 ZS4gIAoKICAgVGhpcyBvcHRpbWlzYXRpb24gaXMgb3B0aW9uYWwuIFdoZW4gY29uc2lkZXJpbmcg d2hldGhlciB0byB1c2UgaXQgYW4gCiAgIG9wZXJhdG9yIHdpbGwgY29uc2lkZXIgaXNzdWVzIHN1 Y2ggYXMgd2hldGhlciB0aGUgb3Zlci1wcmUtZW1wdGlvbiBpcyAKICAgc2VyaW91cywgYW5kIHdo ZXRoZXIgdGhlIHBhcnRpY3VsYXIgcm91dGVycyBjYW4gZWFzaWx5IGRvIHRoaXMgc29ydCAKICAg b2Ygc2VsZWN0aXZlIGRyb3AuIAoKICAgIAoKNS43LjQuIEFkYXB0aXZlIGJhbmR3aWR0aCBmb3Ig dGhlIENvbnRyb2xsZWQgTG9hZCBzZXJ2aWNlIAoKICAgVGhlIGFkbWlzc2lvbiBjb250cm9sIG1l Y2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhc3N1bWVzIAogICB0aGF0IGVhY2gg cm91dGVyIGhhcyBhIGZpeGVkIGJhbmR3aWR0aCBhbGxvY2F0ZWQgdG8gQ0wgZmxvd3MuIEEgCiAg IHBvc3NpYmxlIGV4dGVuc2lvbiBpcyB0aGF0IHRoZSBiYW5kd2lkdGggaXMgZmxleGlibGUsIGRl cGVuZGluZyBvbiAKICAgdGhlIGxldmVsIG9mIG5vbi1DTCB0cmFmZmljLiBJZiBhIGxhcmdlIHNo YXJlIG9mIHRoZSBjdXJyZW50IGxvYWQgb24gCiAgIGEgcGF0aCBpcyBDTCwgdGhlbiBtb3JlIENM IHRyYWZmaWMgY2FuIGJlIGFkbWl0dGVkLiBBbmQgaWYgdGhlIAogICBncmVhdGVyIHNoYXJlIG9m IHRoZSBsb2FkIGlzIG5vbi1DTCwgdGhlbiB0aGUgYWRtaXNzaW9uIHRocmVzaG9sZCBjYW4gCiAg IGJlIHByb3BvcnRpb25hdGVseSBsb3dlci4gVGhlIGFwcHJvYWNoIHJlLWFycmFuZ2VzIHNoYXJp bmcgYmV0d2VlbiAKICAgY2xhc3NlcyB0byBhaW0gZm9yIGVjb25vbWljIGVmZmljaWVuY3ksIHdo YXRldmVyIHRoZSB0cmFmZmljIGxvYWQgCiAgIG1hdHJpeC4gSXQgYWxzbyBkZWFscyB3aXRoIHVu Zm9yZXNlZW4gY2hhbmdlcyB0byBjYXBhY2l0eSBkdXJpbmcgCiAgIGZhaWx1cmVzIGJldHRlciB0 aGFuIGNvbmZpZ3VyaW5nIGZpeGVkIGVuZ2luZWVyZWQgcmF0ZXMuIEFkYXB0aXZlIAogICBiYW5k d2lkdGggYWxsb2NhdGlvbiBjYW4gYmUgYWNoaWV2ZWQgYnkgY2hhbmdpbmcgdGhlIGFkbWlzc2lv biAKICAgbWFya2luZyBiZWhhdmlvdXIsIHNvIHRoYXQgdGhlIHByb2JhYmlsaXR5IG9mIGFkbWlz c2lvbiBtYXJraW5nIGEgCiAgIHBhY2tldCB3b3VsZCBub3cgZGVwZW5kIG9uIHRoZSBudW1iZXIg b2YgcXVldWVkIG5vbi1DTCBwYWNrZXRzIGFzIAogICB3ZWxsIGFzIHRoZSBzaXplIG9mIHRoZSB2 aXJ0dWFsIHF1ZXVlLiBUaGUgYWRhcHRpdmUgYmFuZHdpZHRoIAogICBhcHByb2FjaCB3b3VsZCBi ZSBzdXBwbGVtZW50ZWQgYnkgcGxhY2luZyBsaW1pdHMgb24gdGhlIGFkYXB0YXRpb24gdG8gCiAg IHByZXZlbnQgc3RhcnZhdGlvbiBvZiB0aGUgQ0wgYnkgb3RoZXIgdHJhZmZpYyBjbGFzc2VzIGFu ZCBvZiBvdGhlciAKICAgY2xhc3NlcyBieSBDTCB0cmFmZmljLiBbU29uZ2h1cnN0XSBoYXMgbW9y ZSBkZXRhaWxzIG9mIHRoZSBhZGFwdGl2ZSAKICAgYmFuZHdpZHRoIGFwcHJvYWNoLiAKCgoKIAog CkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAg ICAgICBbUGFnZSA0NF0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwg dXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKNS43LjUuIENvbnRyb2xsZWQg TG9hZCBzZXJ2aWNlIHdpdGggZW5kLXRvLWVuZCBQcmUtQ29uZ2VzdGlvbiAKICAgTm90aWZpY2F0 aW9uIAoKICAgSXQgbWF5IGJlIHBvc3NpYmxlIHRvIGV4dGVuZCB0aGUgZnJhbWV3b3JrIHRvIHBh cnRzIG9mIHRoZSBuZXR3b3JrIAogICB3aGVyZSB0aGVyZSBhcmUgb25seSBhIGxvdyBudW1iZXIg b2YgQ0wgbWljcm9mbG93cywgaS5lLiB0aGUgCiAgIGFnZ3JlZ2F0aW9uIGFzc3VtcHRpb24gKFNl Y3Rpb24gMi4yKSBkb2Vzbid0IGhvbGQuIEluIHRoZSBleHRyZW1lIGl0IAogICBtYXkgYmUgcG9z c2libGUgdG8gb3BlcmF0ZSB0aGUgZnJhbWV3b3JrIGVuZC10by1lbmQsIGkuZS4gYmV0d2VlbiBl bmQgCiAgIGhvc3RzLiBPbmUgcG90ZW50aWFsIG1ldGhvZCBpcyB0byBzZW5kIHByb2JlIHBhY2tl dHMgdG8gdGVzdCB3aGV0aGVyIAogICB0aGUgbmV0d29yayBjYW4gc3VwcG9ydCBhIHByb3NwZWN0 aXZlIG5ldyBDTCBtaWNyb2Zsb3cuIFRoZSBwcm9iZSAKICAgcGFja2V0cyB3b3VsZCBiZSBzZW50 IGF0IHRoZSBzYW1lIHRyYWZmaWMgcmF0ZSBhcyBleHBlY3RlZCBmb3IgdGhlIAogICBhY3R1YWwg bWljcm9mbG93LCBidXQgaW4gb3JkZXIgbm90IHRvIGRpc3R1cmIgZXhpc3RpbmcgQ0wgdHJhZmZp YyBhIAogICByb3V0ZXIgd291bGQgYWx3YXlzIHNjaGVkdWxlIHByb2JlIHBhY2tldHMgYmVoaW5k IENMIG9uZXMgKGNvbXBhcmUgCiAgIFtCcmVzbGF1MDBdKTsgdGhpcyBpbXBsaWVzIHRoZXkgaGF2 ZSBhIG5ldyBEU0NQLiBPdGhlcndpc2UgdGhlIAogICByb3V0ZXJzIHdvdWxkIHRyZWF0IHByb2Jl IHBhY2tldHMgaWRlbnRpY2FsbHkgdG8gQ0wgcGFja2V0cy4gSW4gb3JkZXIgCiAgIHRvIHBlcmZv cm0gYWRtaXNzaW9uIGNvbnRyb2wgcXVpY2tseSwgaW4gcGFydHMgb2YgdGhlIG5ldHdvcmsgd2hl cmUgCiAgIHRoZXJlIGFyZSBvbmx5IGEgZmV3IENMIG1pY3JvZmxvd3MsIHRoZSBhbGdvcml0aG0g Zm9yIEFkbWlzc2lvbiAKICAgTWFya2luZyBkZXNjcmliZWQgaW4gW1BDTl0gd291bGQgbmVlZCB0 byAic3dpdGNoIG9uIiB2ZXJ5IHJhcGlkbHksIGllIAogICBnbyBmcm9tIG1hcmtpbmcgbm8gcGFj a2V0cyB0byBtYXJraW5nIHRoZW0gYWxsIGZvciBvbmx5IGEgbWluaW1hbCAKICAgaW5jcmVhc2Ug aW4gdGhlIHNpemUgb2YgdGhlIHZpcnR1YWwgcXVldWUuIAoKNS43LjYuIE1QTFMtVEUgCgogICBb RUNOLU1QTFNdIGRpc2N1c3NlcyBob3cgdG8gZXh0ZW5kIHRoZSBkZXBsb3ltZW50IG1vZGVsIHRv IE1QTFMsIGkuZS4gCiAgIGZvciBhZG1pc3Npb24gY29udHJvbCBvZiBtaWNyb2Zsb3dzIGludG8g YSBzZXQgb2YgTVBMUy1URSBhZ2dyZWdhdGVzIAogICAoTXVsdGktcHJvdG9jb2wgbGFiZWwgc3dp dGNoaW5nIHRyYWZmaWMgZW5naW5lZXJpbmcpLiBJdCB3b3VsZCAKICAgcmVxdWlyZSB0aGF0IHRo ZSBNUExTIGhlYWRlciBjb3VsZCBpbmNsdWRlIHRoZSBFQ04gZmllbGQsIHdoaWNoIGlzIAogICBu b3QgcHJlY2x1ZGVkIGJ5IFJGQzMyNzAuIFNlZSBbRUNOLU1QTFNdLiAKCiAgICAKCiAgICAKCiAg ICAKCiAgICAKCiAgICAKCiAgICAKCiAgICAKCiAgICAKCiAgICAKCiAKIAogCkJyaXNjb2UgICAg ICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0 NV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAg ICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKNi4gUmVsYXRpb25zaGlwIHRvIG90aGVyIFFvUyBt ZWNoYW5pc21zIAoKNi4xLiBJbnRTZXJ2IENvbnRyb2xsZWQgTG9hZCAKCiAgIFRoZSBDTCBtZWNo YW5pc20gZGVsaXZlcnMgUW9TIHNpbWlsYXIgdG8gSW50ZWdyYXRlZCBTZXJ2aWNlcyAKICAgY29u dHJvbGxlZCBsb2FkLCBidXQgcmF0aGVyIGJldHRlci4gVGhlIHJlYXNvbiB0aGUgUW9TIGlzIGJl dHRlciBpcyAKICAgdGhhdCB0aGUgQ0wgbWVjaGFuaXNtIGtlZXBzIHRoZSByZWFsIHF1ZXVlcyBl bXB0eSwgYnkgZHJpdmluZyAKICAgYWRtaXNzaW9uIGNvbnRyb2wgZnJvbSBhIGJ1bGsgdmlydHVh bCBxdWV1ZSBvbiBlYWNoIGludGVyZmFjZS4gVGhlIAogICB2aXJ0dWFsIHF1ZXVlIFtBVlEsIHZx XSBjYW4gZGV0ZWN0IGEgcmlzZSBpbiBsb2FkIGJlZm9yZSB0aGUgcmVhbCAKICAgcXVldWUgYnVp bGRzLiBJdCBpcyBhbHNvIG1vcmUgcm9idXN0IHRvIHJvdXRlIGNoYW5nZXMuICAKCjYuMi4gSW50 ZWdyYXRlZCBzZXJ2aWNlcyBvcGVyYXRpb24gb3ZlciBEaWZmU2VydiAKCiAgIE91ciBhcHByb2Fj aCB0byBlbmQtdG8tZW5kIFFvUyBpcyBzaW1pbGFyIHRvIHRoYXQgZGVzY3JpYmVkIGluIAogICBb UkZDMjk5OF0gZm9yIEludGVncmF0ZWQgc2VydmljZXMgb3BlcmF0aW9uIG92ZXIgRGlmZlNlcnYg bmV0d29ya3MuIAogICBMaWtlIFtSRkMyOTk4XSwgYW4gSW50U2VydiBjbGFzcyAoQ0wgaW4gb3Vy IGNhc2UpIGlzIGFjaGlldmVkIGVuZC10by0KICAgZW5kLCB3aXRoIGEgQ0wtcmVnaW9uIHZpZXdl ZCBhcyBhIHNpbmdsZSByZXNlcnZhdGlvbiBob3AgaW4gdGhlIHRvdGFsIAogICBlbmQtdG8tZW5k IHBhdGguIEludGVyaW9yIHJvdXRlcnMgb2YgdGhlIENMLXJlZ2lvbiBkbyBub3QgcHJvY2VzcyAK ICAgZmxvdyBzaWduYWxsaW5nIG5vciBkbyB0aGV5IGhvbGQgcGVyIGZsb3cgc3RhdGUuIFVubGlr ZSBbUkZDMjk5OF0gd2UgCiAgIGRvIG5vdCByZXF1aXJlIHRoZSBlbmQtdG8tZW5kIHNpZ25hbGxp bmcgbWVjaGFuaXNtIHRvIGJlIFJTVlAsIAogICBhbHRob3VnaCBpdCBjYW4gYmUuICAKCiAgIEJl YXJpbmcgaW4gbWluZCB0aGVzZSBkaWZmZXJlbmNlcywgd2UgY2FuIGRlc2NyaWJlIG91ciBhcmNo aXRlY3R1cmUgCiAgIGluIHRoZSB0ZXJtcyBvZiB0aGUgb3B0aW9ucyBpbiBbUkZDMjk5OF0uIFRo ZSBEaWZmU2VydiBuZXR3b3JrIHJlZ2lvbiAKICAgaXMgUlNWUC1hd2FyZSwgYnV0IGF3YXJlbmVz cyBpcyBjb25maW5lZCB0byAod2hhdCBbUkZDMjk5OF0gY2FsbHMpIAogICB0aGUgImJvcmRlciBy b3V0ZXJzIiBvZiB0aGUgRGlmZlNlcnYgcmVnaW9uLiBXZSB1c2UgZXhwbGljaXQgCiAgIGFkbWlz c2lvbiBjb250cm9sIGludG8gdGhpcyByZWdpb24sIHdpdGggc3RhdGljIHByb3Zpc2lvbmluZyB3 aXRoaW4gCiAgIGl0LiBUaGUgaW5ncmVzcyAiYm9yZGVyIHJvdXRlciIgZG9lcyBwZXIgbWljcm9m bG93IHBvbGljaW5nIGFuZCBzZXRzIAogICB0aGUgRFNDUCBhbmQgRUNOIGZpZWxkcyB0byBpbmRp Y2F0ZSB0aGUgcGFja2V0cyBhcmUgQ0wgb25lcyAoaS5lLiB3ZSAKICAgdXNlIHJvdXRlciBtYXJr aW5nIHJhdGhlciB0aGFuIGhvc3QgbWFya2luZykuIAoKNi4zLiBEaWZmZXJlbnRpYXRlZCBTZXJ2 aWNlcyAKCiAgIFRoZSBEaWZmU2VydiBhcmNoaXRlY3R1cmUgZG9lcyBub3Qgc3BlY2lmeSBhbnkg d2F5IGZvciBkZXZpY2VzIAogICBvdXRzaWRlIHRoZSBkb21haW4gdG8gZHluYW1pY2FsbHkgcmVz ZXJ2ZSByZXNvdXJjZXMgb3IgcmVjZWl2ZSAKICAgaW5kaWNhdGlvbnMgb2YgbmV0d29yayByZXNv dXJjZSBhdmFpbGFiaWxpdHkuICBJbiBwcmFjdGljZSwgc2VydmljZSAKICAgcHJvdmlkZXJzIHJl bHkgb24gc3Vic2NyaXB0aW9uLXRpbWUgU2VydmljZSBMZXZlbCBBZ3JlZW1lbnRzIChTTEFzKSAK ICAgdGhhdCBzdGF0aWNhbGx5IGRlZmluZSB0aGUgcGFyYW1ldGVycyBvZiB0aGUgdHJhZmZpYyB0 aGF0IHdpbGwgYmUgCiAgIGFjY2VwdGVkIGZyb20gYSBjdXN0b21lci4gVGhlIENMIG1lY2hhbmlz bSBhbGxvd3MgZHluYW1pYyByZXNlcnZhdGlvbiAKICAgb2YgcmVzb3VyY2VzIHRocm91Z2ggdGhl IERpZmZTZXJ2IGRvbWFpbiBhbmQsIHdpdGggdGhlIHBvdGVudGlhbCAKICAgZXh0ZW5zaW9uIG1l bnRpb25lZCBpbiBTZWN0aW9uIDUuNy4yLCBpdCBjYW4gc3BhbiBtdWx0aXBsZSBkb21haW5zIAog ICB3aXRob3V0IGFjdGl2ZSBwb2xpY2luZyBtZWNoYW5pc21zIGF0IHRoZSBib3JkZXJzICh1bmxp a2UgRGlmZlNlcnYpLiAKICAgVGhlcmVmb3JlIHdlIGRvIG5vdCB1c2UgdGhlIHRyYWZmaWMgY29u ZGl0aW9uaW5nIGFncmVlbWVudHMgKFRDQXMpIG9mIAogICB0aGUgKGluZm9ybWF0aW9uYWwpIERp ZmZTZXJ2IGFyY2hpdGVjdHVyZSBbUkZDMjQ3NV0uICAKCiAgIEFuIGltcG9ydGFudCBiZW5lZml0 IGFyaXNlcyBmcm9tIHRoZSBmYWN0IHRoYXQgdGhlIGxvYWQgaXMgY29udHJvbGxlZCAKICAgZHlu YW1pY2FsbHkgcmF0aGVyIHRoYW4gd2l0aCB0cmFmZmljIGNvbmRpdGlvbmluZyBhZ3JlZW1lbnRz IChUQ0FzKS4gCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgNDZdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBs b3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIFRD QXMgd2VyZSBvcmlnaW5hbGx5IGludHJvZHVjZWQgaW4gdGhlIChpbmZvcm1hdGlvbmFsKSBEaWZm U2VydiAKICAgYXJjaGl0ZWN0dXJlIFtSRkMyNDc1XSBhcyBhbiBhbHRlcm5hdGl2ZSB0byByZXNl cnZhdGlvbiBwcm9jZXNzaW5nIGluIAogICB0aGUgaW50ZXJpb3IgcmVnaW9uIGluIG9yZGVyIHRv IHJlZHVjZSB0aGUgYnVyZGVuIG9uIGludGVyaW9yIAogICByb3V0ZXJzLiBXaXRoIFRDQXMsIGlu IHByYWN0aWNlIHNlcnZpY2UgcHJvdmlkZXJzIHJlbHkgb24gCiAgIHN1YnNjcmlwdGlvbi10aW1l IFNlcnZpY2UgTGV2ZWwgQWdyZWVtZW50cyB0aGF0IHN0YXRpY2FsbHkgZGVmaW5lIHRoZSAKICAg cGFyYW1ldGVycyBvZiB0aGUgdHJhZmZpYyB0aGF0IHdpbGwgYmUgYWNjZXB0ZWQgZnJvbSBhIGN1 c3RvbWVyLiBUaGUgCiAgIHByb2JsZW0gYXJpc2VzIGJlY2F1c2UgdGhlIFRDQSBhdCB0aGUgaW5n cmVzcyBtdXN0IGFsbG93IGFueSAKICAgZGVzdGluYXRpb24gYWRkcmVzcywgaWYgaXQgaXMgdG8g cmVtYWluIHNjYWxhYmxlLiBCdXQgZm9yIGxvbmdlciAKICAgdG9wb2xvZ2llcywgdGhlIGNoYW5j ZXMgaW5jcmVhc2UgdGhhdCB0cmFmZmljIHdpbGwgZm9jdXMgb24gYW4gCiAgIGludGVyaW9yIHJl c291cmNlLCBldmVuIHRob3VnaCBpdCBpcyB3aXRoaW4gY29udHJhY3QgYXQgdGhlIGluZ3Jlc3Mg CiAgIFtSZWlkXSwgZS5nLiBhbGwgZmxvd3MgY29udmVyZ2Ugb24gdGhlIHNhbWUgZWdyZXNzIGdh dGV3YXkuIEV2ZW4gCiAgIHRob3VnaCBuZXR3b3JrcyBjYW4gYmUgZW5naW5lZXJlZCB0byBtYWtl IHN1Y2ggZmFpbHVyZXMgcmFyZSwgd2hlbiAKICAgdGhleSBvY2N1ciBhbGwgaW5lbGFzdGljIGZs b3dzIHRocm91Z2ggdGhlIGNvbmdlc3RlZCByZXNvdXJjZSBmYWlsIAogICBjYXRhc3Ryb3BoaWNh bGx5LiAgCgogICBbSm9obnNvbl0gY29tcGFyZXMgYWRtaXNzaW9uIGNvbnRyb2wgd2l0aCBhICdn ZW5lcm91c2x5IGRpbWVuc2lvbmVkJyAKICAgRGlmZlNlcnYgbmV0d29yayBhcyB3YXlzIHRvIGFj aGlldmUgUW9TLiBUaGUgZm9ybWVyIGlzIHJlY29tbWVuZGVkLiAgCgo2LjQuIEVDTiAKCiAgIFRo ZSBtYXJraW5nIGJlaGF2aW91ciBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBjb21wbGllcyB3 aXRoIHRoZSAKICAgRUNOIGFzcGVjdHMgb2YgdGhlIElQIHdpcmUgcHJvdG9jb2wgUkZDMzE2OCwg YnV0IHByb3ZpZGVzIGl0cyBvd24gCiAgIGVkZ2UtdG8tZWRnZSBmZWVkYmFjayBpbnN0ZWFkIG9m IHRoZSBUQ1AgYXNwZWN0cyBvZiBSRkMzMTY4LiBBbGwgCiAgIHJvdXRlcnMgd2l0aGluIHRoZSBD TC1yZWdpb24gYXJlIHVwZ3JhZGVkIHdpdGggdGhlIGFkbWlzc2lvbiBtYXJraW5nIAogICBhbmQg cHJlLWVtcHRpb24gbWFya2luZyBvZiBQcmUtQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24sIHNvIHRo ZSAKICAgcmVxdWlyZW1lbnRzIG9mIFtGbG95ZF0gYXJlIG1ldCBiZWNhdXNlIHRoZSBDTC1yZWdp b24gaXMgYW4gZW5jbG9zZWQgCiAgIGVudmlyb25tZW50LiBUaGUgb3BlcmF0b3IgcHJldmVudHMg dHJhZmZpYyBhcnJpdmluZyBhdCBhIHJvdXRlciB0aGF0IAogICBkb2Vzbid0IHVuZGVyc3RhbmQg Q0wgYnkgYWRtaW5pc3RyYXRpdmUgY29uZmlndXJhdGlvbiBvZiB0aGUgcmluZyBvZiAKICAgZ2F0 ZXdheXMgYXJvdW5kIHRoZSBDTC1yZWdpb24uICAKCjYuNS4gUlRFQ04gCgogICBSZWFsLXRpbWUg RUNOIChSVEVDTikgW1JURUNOLCBSVEVDTi11c2FnZV0gaGFzIGEgc2ltaWxhciBhaW0gdG8gdGhp cyAKICAgZG9jdW1lbnQgKHRvIGFjaGlldmUgYSBsb3cgZGVsYXksIGppdHRlciBhbmQgbG9zcyBz ZXJ2aWNlIHN1aXRhYmxlIAogICBmb3IgUlQgdHJhZmZpYykgYW5kIGEgc2ltaWxhciBhcHByb2Fj aCAocGVyIG1pY3JvZmxvdyBhZG1pc3Npb24gCiAgIGNvbnRyb2wgY29tYmluZWQgd2l0aCBhbiAi ZWFybHkgd2FybmluZyIgb2YgcG90ZW50aWFsIGNvbmdlc3Rpb24gCiAgIHRocm91Z2ggc2V0dGlu ZyB0aGUgQ0UgY29kZXBvaW50KS4gQnV0IGl0IGV4cGxvcmVzIGEgZGlmZmVyZW50IAogICBhcmNo aXRlY3R1cmUgd2l0aG91dCB0aGUgYWdncmVnYXRpb24gYXNzdW1wdGlvbjogaG9zdC10by1ob3N0 IHJhdGhlciAKICAgdGhhbiBlZGdlLXRvLWVkZ2UuIFdlIHBsYW4gdG8gZG9jdW1lbnQgc3VjaCBh IGhvc3QtdG8taG9zdCBmcmFtZXdvcmsgCiAgIGluIGEgcGFyYWxsZWwgZHJhZnQgdG8gdGhpcyBv bmUsIGFuZCB0byBkZXNjcmliZSBpZiBhbmQgaG93IFtQQ05dIGNhbiAKICAgd29yayBpbiB0aGlz IGZyYW1ld29yay4gIAoKICAgIAoKCgoKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJl cyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0N10gCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAw NiAKICAgIAoKNi42LiBSTUQgCgogICBSZXNvdXJjZSBNYW5hZ2VtZW50IGluIERpZmZTZXJ2IChS TUQpIFtSTURdIGlzIHNpbWlsYXIgdG8gdGhpcyB3b3JrLCAKICAgaW4gdGhhdCBpdCBwdXNoZXMg Y29tcGxleCBjbGFzc2lmaWNhdGlvbiwgdHJhZmZpYyBjb25kaXRpb25pbmcgYW5kIAogICBhZG1p c3Npb24gY29udHJvbCBmdW5jdGlvbnMgdG8gdGhlIGVkZ2Ugb2YgYSBEaWZmU2VydiBkb21haW4g YW5kIAogICBzaW1wbGlmaWVzIHRoZSBvcGVyYXRpb24gb2YgdGhlIGludGVyaW9yIHJvdXRlcnMu IE9uZSBvZiB0aGUgUk1EIAogICBtb2RlcyAoIkNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIGZ1bmN0 aW9uIGJhc2VkIG9uIHByb2JpbmciKSB1c2VzIAogICBtZWFzdXJlbWVudC1iYXNlZCBhZG1pc3Np b24gY29udHJvbCBpbiBhIHNpbWlsYXIgd2F5IHRvIHRoaXMgCiAgIGRvY3VtZW50LiBUaGUgbWFp biBkaWZmZXJlbmNlIGlzIHRoYXQgaW4gUk1EIHByb2JpbmcgcGxheXMgYSAKICAgc2lnbmlmaWNh bnQgcm9sZSBpbiB0aGUgYWRtaXNzaW9uIGNvbnRyb2wgcHJvY2Vzcy4gT3RoZXIgZGlmZmVyZW5j ZXMgCiAgIGFyZSB0aGF0IHRoZSBhZG1pc3Npb24gY29udHJvbCBkZWNpc2lvbiBpcyB0YWtlbiBv biB0aGUgZWdyZXNzIAogICBnYXRld2F5IChyYXRoZXIgdGhhbiB0aGUgaW5ncmVzcyk7ICdhZG1p c3Npb24gbWFya2luZycgaXMgZW5jb2RlZCBpbiAKICAgYSBwYWNrZXQgYXMgYSBuZXcgRFNDUCAo cmF0aGVyIHRoYW4gaW4gdGhlIEVDTiBmaWVsZCksIGFuZCB0aGF0IHRoZSAKICAgTlNJUyBwcm90 b2NvbHMgYXJlIHVzZWQgZm9yIHNpZ25hbGxpbmcgKHJhdGhlciB0aGFuIFJTVlApLiAKCiAgIFJN RCBhbHNvIGluY2x1ZGVzIHRoZSBjb25jZXB0IG9mIFNldmVyZSBDb25nZXN0aW9uIGhhbmRsaW5n LiBUaGUgcHJlLQogICBlbXB0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhlIENMIGFyY2hp dGVjdHVyZSBoYXMgc2ltaWxhciAKICAgb2JqZWN0aXZlcyBidXQgcmVsaWVzIG9uIGRpZmZlcmVu dCBtZWNoYW5pc21zLiBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzIAogICB0aGF0IHRoZSBpbnRlcmlv ciByb3V0ZXJzIG1lYXN1cmUgdGhlIGRhdGEgcmF0ZSB0aGF0IGNhdXNlcyBhbiAKICAgb3Zlcmxv YWQgYW5kIG1hcmsgcGFja2V0cyBhY2NvcmRpbmcgdG8gdGhpcyByYXRlLiAgCgo2LjcuIFJTVlAg QWdncmVnYXRpb24gb3ZlciBNUExTLVRFIAoKICAgTXVsdGktcHJvdG9jb2wgbGFiZWwgc3dpdGNo aW5nIHRyYWZmaWMgZW5naW5lZXJpbmcgKE1QTFMtVEUpIGFsbG93cyAKICAgc2NhbGFibGUgcmVz ZXJ2YXRpb24gb2YgcmVzb3VyY2VzIGluIHRoZSBjb3JlIGZvciBhbiBhZ2dyZWdhdGUgb2YgCiAg IG1hbnkgbWljcm9mbG93cy4gVG8gYWNoaWV2ZSBlbmQtdG8tZW5kIHJlc2VydmF0aW9ucywgYWRt aXNzaW9uIAogICBjb250cm9sIGFuZCBwb2xpY2luZyBvZiBtaWNyb2Zsb3dzIGludG8gdGhlIGFn Z3JlZ2F0ZSBjYW4gYmUgYWNoaWV2ZWQgCiAgIHVzaW5nIHRlY2huaXF1ZXMgc3VjaCBhcyBSU1ZQ IEFnZ3JlZ2F0aW9uIG92ZXIgTVBMUyBURSBUdW5uZWxzIGFzIHBlciAKICAgW0FHR1JFLVRFXS4g SG93ZXZlciwgaW4gdGhlIGNhc2Ugb2YgaW50ZXItcHJvdmlkZXIgZW52aXJvbm1lbnRzLCAKICAg dGhlc2UgdGVjaG5pcXVlcyByZXF1aXJlIHRoYXQgYWRtaXNzaW9uIGNvbnRyb2wgYW5kIHBvbGlj aW5nIGJlIAogICByZXBlYXRlZCBhdCBlYWNoIHRydXN0IGJvdW5kYXJ5IG9yIHRoYXQgTVBMUyBU RSB0dW5uZWxzIHNwYW4gbXVsdGlwbGUgCiAgIGRvbWFpbnMuICAKCjYuOC4gT3RoZXIgTmV0d29y ayBBZG1pc3Npb24gQ29udHJvbCBBcHByb2FjaGVzIAoKICAgTGluayBhZG1pc3Npb24gY29udHJv bCAoTEFDKSBkZXNjcmliZXMgaG93IGFkbWlzc2lvbiBjb250cm9sIChBQykgY2FuIAogICBiZSBk b25lIG9uIGEgc2luZ2xlIGxpbmsgYW5kIGNvbXByaXNlcywgZS5nLiwgdGhlIGNhbGN1bGF0aW9u IG9mIAogICBlZmZlY3RpdmUgYmFuZHdpZHRocyB3aGljaCBtYXkgYmUgdGhlIGJhc2UgZm9yIGEg cGFyYW1ldGVyLWJhc2VkIEFDLiAKICAgSW4gY29udHJhc3QsIG5ldHdvcmsgQUMgKE5BQykgZGVz Y3JpYmVzIGhvdyBBQyBjYW4gYmUgZG9uZSBmb3IgYSAKICAgbmV0d29yayBhbmQgZm9jdXNlcyBv biB0aGUgbG9jYXRpb25zIGZyb20gd2hpY2ggZGF0YSBpcyBnYXRoZXJlZCBmb3IgCiAgIHRoZSBh ZG1pc3Npb24gZGVjaXNpb24uIE1vc3QgYXBwcm9hY2hlcyBpbXBsZW1lbnQgYSBsaW5rIGJ1ZGdl dCBiYXNlZCAKICAgTkFDIChMQiBOQUMpIHdoZXJlIGVhY2ggbGluayBoYXMgYSBjZXJ0YWluIEFD LWJ1ZGdldC4gUlNWUCB3b3JrcyAKICAgYWNjb3JkaW5nIHRvIHRoYXQgcHJpbmNpcGxlLCBidXQg YWxzbyB0aGUgbmV3IGNvbmNlcHQgYWRtaXRzIAogICBhZGRpdGlvbmFsIGZsb3dzIGFzIGxvbmcg YXMgZWFjaCBsaW5rIG9uIHRoZSBuZXcgZmxvdydzIHBhdGggc3RpbGwgCiAgIGhhcyByZXNvdXJj ZXMgYXZhaWxhYmxlLiBUaGUgYm9yZGVyLXRvLWJvcmRlciBidWRnZXQgYmFzZWQgTkFDIChCQkIg CiAgIE5BQykgcHJlLWNvbmZpZ3VyZXMgYW4gQUMgYnVkZ2V0IGZvciBhbGwgYm9yZGVyLXRvLWJv cmRlciAKICAgcmVsYXRpb25zaGlwcyAoPSBDTC1yZWdpb24tYWdncmVnYXRlcykgYW5kIGlmIHRo aXMgY2FwYWNpdHkgYnVkZ2V0IGlzIAogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVz IEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDQ4XSAKDApJbnRlcm5ldC1EcmFm dCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2 IAogICAgCgogICBleGhhdXN0ZWQsIG5ldyBmbG93cyBhcmUgcmVqZWN0ZWQuIFRoZSBUQ0EtYmFz ZWQgYWRtaXNzaW9uIGNvbnRyb2wgCiAgIHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgRGlm ZlNlcnYgYXJjaGl0ZWN0dXJlIGltcGxlbWVudHMgYW4gCiAgIGluZ3Jlc3MgYnVkZ2V0IGJhc2Vk IE5BQyAoSUIgTkFDKS4gVGhlc2UgYmFzaWNhbGx5IGRpZmZlcmVudCBjb25jZXB0cyAKICAgaGF2 ZSBkaWZmZXJlbnQgZmxleGliaWxpdHkgYW5kIGVmZmljaWVuY3kgd2l0aCByZWdhcmQgdG8gdGhl IHVzZSBvZiAKICAgbGluayBiYW5kd2lkdGhzIFtOQUMtYSxOQUMtYl0uIFRoZXkgY2FuIGJlIG1h ZGUgcmVzaWxpZW50IGJ5IGNob29zaW5nIAogICB0aGUgYnVkZ2V0cyBpbiBzdWNoIGEgd2F5IHRo YXQgdGhlIG5ldHdvcmsgd2lsbCBub3QgYmUgY29uZ2VzdGVkIAogICBhZnRlciByZXJvdXRpbmcg ZHVlIHRvIGEgZmFpbHVyZS4gVGhlIGVmZmljaWVuY3kgb2YgdGhlIGFwcHJvYWNoZXMgaXMgCiAg IGRpZmZlcmVudCB3aXRoIGFuZCB3aXRob3V0IHN1Y2ggcmVzaWxpZW50IHJlcXVpcmVtZW50cy4g CgogCgo3LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAKCiAgIFRvIHByb3RlY3QgYWdhaW5zdCBk ZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzLCB0aGUgaW5ncmVzcyBnYXRld2F5IG9mIAogICB0aGUg Q0wtcmVnaW9uIG5lZWRzIHRvIHBvbGljZSBhbGwgQ0wgcGFja2V0cyBhbmQgZHJvcCBwYWNrZXRz IGluIAogICBleGNlc3Mgb2YgdGhlIHJlc2VydmF0aW9uLiBUaGlzIGlzIHNpbWlsYXIgdG8gb3Bl cmF0aW9ucyB3aXRoIAogICBleGlzdGluZyBJbnRTZXJ2IGJlaGF2aW91ci4gCgogICBGb3IgcHJl LWVtcHRpb24sIGl0IGlzIGNvbnNpZGVyZWQgYWNjZXB0YWJsZSBmcm9tIGEgc2VjdXJpdHkgCiAg IHBlcnNwZWN0aXZlIHRoYXQgdGhlIGluZ3Jlc3MgZ2F0ZXdheSBjYW4gdHJlYXQgImVtZXJnZW5j eS9taWxpdGFyeSIgCiAgIENMIGZsb3dzIHByZWZlcmVudGlhbGx5IGNvbXBhcmVkIHdpdGggIm9y ZGluYXJ5IiBDTCBmbG93cy4gSG93ZXZlciwgCiAgIGluIHRoZSByZXN0IG9mIHRoZSBDTC1yZWdp b24gdGhleSBhcmUgbm90IGRpc3Rpbmd1aXNoZWQgKG5vbmV0aGVsZXNzLCAKICAgb3VyIHByb3Bv c2VkIHRlY2huaXF1ZSBkb2VzIG5vdCBwcmVjbHVkZSB0aGUgdXNlIG9mIGRpZmZlcmVudCBEU0NQ cyAKICAgYXQgdGhlIHBhY2tldCBsZXZlbCBhcyB3ZWxsIGFzIGRpZmZlcmVudCBwcmlvcml0aWVz IGF0IHRoZSBmbG93IAogICBsZXZlbC4pLiBLZWVwaW5nIGVtZXJnZW5jeSB0cmFmZmljIGluZGlz dGluZ3Vpc2hhYmxlIGF0IHRoZSBwYWNrZXQgCiAgIGxldmVsIG1pbmltaXNlcyB0aGUgb3Bwb3J0 dW5pdHkgZm9yIG5ldyBzZWN1cml0eSBhdHRhY2tzLiBGb3IgCiAgIGV4YW1wbGUsIGlmIGluc3Rl YWQgYSBtZWNoYW5pc20gdXNlZCBkaWZmZXJlbnQgRFNDUHMgZm9yIAogICAiZW1lcmdlbmN5L21p bGl0YXJ5IiBhbmQgIm9yZGluYXJ5IiBwYWNrZXRzLCB0aGVuIGFuIGF0dGFja2VyIGNvdWxkIAog ICBzcGVjaWZpY2FsbHkgdGFyZ2V0IHRoZSBmb3JtZXIgaW4gdGhlIGRhdGEgcGxhbmUgKHBlcmhh cHMgZm9yIERvUyBvciAKICAgZm9yIGVhdmVzZHJvcHBpbmcpLiAKCiAgIEZ1cnRoZXIgc2VjdXJp dHkgYXNwZWN0cyB0byBiZSBjb25zaWRlcmVkIGxhdGVyLiAgIAoKICAgIAoKOC4gQWNrbm93bGVk Z2VtZW50cyAKCiAgIFRoZSBhZG1pc3Npb24gY29udHJvbCBtZWNoYW5pc20gZXZvbHZlZCBmcm9t IHRoZSB3b3JrIGxlZCBieSBNYXJ0aW4gCiAgIEthcnN0ZW4gb24gdGhlIEd1YXJhbnRlZWQgU3Ry ZWFtIFByb3ZpZGVyIGRldmVsb3BlZCBpbiB0aGUgTTNJIAogICBwcm9qZWN0IFtHU1BhLCBHU1At VFJdLCB3aGljaCBpbiB0dXJuIHdhcyBiYXNlZCBvbiB0aGUgdGhlb3JldGljYWwgCiAgIHdvcmsg b2YgR2liYmVucyBhbmQgS2VsbHkgW0RDQUNdLiBLZW5uZWR5IENoZW5nLCBHYWJyaWVsZSBDb3Js aWFubywgCiAgIENhcmxhIERpIENhaXJhbm8tR2lsZmVkZGVyLCBLYXNoYWYgS2hhbiwgUGV0ZXIg SG92ZWxsLCBBcm5hdWQgSmFjcXVldCAKICAgYW5kIEp1bmUgVGF5IChCVCkgaGVscGVkIGRldmVs b3AgYW5kIGV2YWx1YXRlIHRoaXMgYXBwcm9hY2guIAoKICAgTWFueSB0aGFua3MgdG8gdGhvc2Ug d2hvIGhhdmUgY29tbWVudGVkIG9uIHRoaXMgd29yayBhdCBUcmFuc3BvcnQgCiAgIEFyZWEgV29y a2luZyBHcm91cCBtZWV0aW5ncyBhbmQgb24gdGhlIG1haWxpbmcgbGlzdCwgaW5jbHVkaW5nOiBL ZW4gCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDQ5XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVu dCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBDYXJsYmVy ZywgUnVlZGlnZXIgR2VpYiwgTGFycyBXZXN0YmVyZywgRGF2aWQgQmxhY2ssIFJvYmVydCBIYW5j b2NrLCAKICAgQ29ybmVsaWEgS2FwcGxlciwgTWljaGFlbCBNZW50aC4gCgo5LiBDb21tZW50cyBz b2xpY2l0ZWQgCgogICBDb21tZW50cyBhbmQgcXVlc3Rpb25zIGFyZSBlbmNvdXJhZ2VkIGFuZCB2 ZXJ5IHdlbGNvbWUuIFRoZXkgY2FuIGJlIAogICBzZW50IHRvIHRoZSBUcmFuc3BvcnQgQXJlYSBX b3JraW5nIEdyb3VwJ3MgbWFpbGluZyBsaXN0LCAKICAgdHN2d2dAaWV0Zi5vcmcsIGFuZC9vciB0 byB0aGUgYXV0aG9ycy4gCgogICAgCgoxMC4gQ2hhbmdlcyBmcm9tIGVhcmxpZXIgdmVyc2lvbnMg b2YgdGhlIGRyYWZ0IAoKICAgVGhlIG1haW4gY2hhbmdlcyBhcmU6IAoKICAgRnJvbSAtMDAgdG8g LTAxICAKCiAgIFRoZSB3aG9sZSBvZiB0aGUgUHJlLWVtcHRpb24gbWVjaGFuaXNtIGlzIGFkZGVk LiAKCiAgIFRoZXJlIGFyZSBzZXZlcmFsIG1vZGlmaWNhdGlvbnMgdG8gdGhlIGFkbWlzc2lvbiBj b250cm9sIG1lY2hhbmlzbS4gCgogICAgCgogICBGcm9tIC0wMSB0byAtMDIgCgogICBUaGUgcHJl LWNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIGFsZ29yaXRobXMgZm9yIGFkbWlzc2lvbiBtYXJraW5n IGFuZCAKICAgcHJlLWVtcHRpb24gbWFya2luZyBhcmUgbm93IGRlc2NyaWJlZCBpbiBbUENOXS4g CgogICBUaGVyZSBhcmUgbmV3IHN1Yi1zZWN0aW9ucyBpbiBTZWN0aW9uIDQgb24gRmFpbHVyZXMs IEFkbWlzc2lvbiBvZiAKICAgJ2VtZXJnZW5jeSAvIGhpZ2hlciBwcmVjZWRlbmNlJyBzZXNzaW9u LCBhbmQgVHVubmVsbGluZzsgYW5kIGEgbmV3IAogICBzdWItc2VjdGlvbiBpbiBTZWN0aW9uIDUg b24gTWVjaGFuaXNtcyB0byBkZWFsIHdpdGggJ0ZsYXNoIGNyb3dkcycuIAoKICAgIAoKICAgRnJv bSAtMDIgdG8gLTAzIAoKICAgU2VjdGlvbiA1IGhhcyBiZWVuIHVwZGF0ZWQgYW5kIGV4cGFuZGVk LiBJdCBpcyBub3cgYWJvdXQgdGhlIAogICAnbGltaXRhdGlvbnMnIG9mIHRoZSBQQ04gbWVjaGFu aXNtLCBhcyBkZXNjcmliZWQgaW4gdGhlIGVhcmxpZXIgCiAgIHNlY3Rpb25zLCBwbHVzIGRpc2N1 c3Npb24gb2YgJ3Bvc3NpYmxlIHNvbHV0aW9ucycgdG8gdGhvc2UgCiAgIGxpbWl0YXRpb25zLiAg CgogICBUaGUgbWVhc3VyZW1lbnQgb2YgdGhlIENvbmdlc3Rpb24tTGV2ZWwtRXN0aW1hdGUgbm93 IGluY2x1ZGVzIHByZS0KICAgZW1wdGlvbiBtYXJrZWQgcGFja2V0cyBhcyB3ZWxsIGFzIGFkbWlz c2lvbiBtYXJrZWQgb25lcy4gU2VjdGlvbiAKICAgMy4xLjIgZXhwbGFpbnMuICAgCgogICAgCgog CiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDUwXSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2Rl bCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBGcm9tIC0wMyB0byAt MDQgCgogICBEZXRhaWxlZCByZXZpZXcgYnkgTWljaGFlbCBNZW50aC4gSW4gcmVzcG9uc2UsIEFi c3RyYWN0LCBTdW1tYXJ5IGFuZCAKICAgS2V5IGJlbmVmaXRzIHNlY3Rpb25zIHJlLXdyaXR0ZW4u IE51bWVyb3VzIGRldGFpbGVkIGNvbW1lbnRzIG9uIAogICBTZWN0aW9ucyA1IGFuZCBmb2xsb3dp bmcgc2VjdGlvbnMuICAKCiAgICAKCiAgICAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcg ICAgICAgICAgICAgICAgW1BhZ2UgNTFdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3lt ZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgICAKCjEx LiBBcHBlbmRpY2VzIAoKMTEuMS4gQXBwZW5kaXggQTogRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3Rp ZmljYXRpb24gCgogICBUaGlzIEFwcGVuZGl4IHByb3ZpZGVzIGEgYnJpZWYgc3VtbWFyeSBvZiBF eHBsaWNpdCBDb25nZXN0aW9uIAogICBOb3RpZmljYXRpb24gKEVDTikuIAoKICAgW1JGQzMxNjhd IHNwZWNpZmllcyB0aGUgaW5jb3Jwb3JhdGlvbiBvZiBFQ04gdG8gVENQIGFuZCBJUCwgaW5jbHVk aW5nIAogICBFQ04ncyB1c2Ugb2YgdHdvIGJpdHMgaW4gdGhlIElQIGhlYWRlci4gSXQgc3BlY2lm aWVzIGEgbWV0aG9kIGZvciAKICAgaW5kaWNhdGluZyBpbmNpcGllbnQgY29uZ2VzdGlvbiB0byBl bmQtaG9zdHMgKGUuZy4gYXMgaW4gUkVELCBSYW5kb20gCiAgIEVhcmx5IERldGVjdGlvbiksIHdo ZXJlIHRoZSBub3RpZmljYXRpb24gaXMgdGhyb3VnaCBFQ04gbWFya2luZyAKICAgcGFja2V0cyBy YXRoZXIgdGhhbiBkcm9wcGluZyB0aGVtLiAgIAoKICAgRUNOIHVzZXMgdHdvIGJpdHMgaW4gdGhl IElQIGhlYWRlciBvZiBib3RoIElQdjQgYW5kIElQdjYgcGFja2V0czogCgogICAgICAgICAgICAw ICAgICAxICAgICAyICAgICAzICAgICA0ICAgICA1ICAgICA2ICAgICA3IAogICAgICAgICArLS0t LS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rIAogICAgICAgICB8 ICAgICAgICAgIERTIEZJRUxELCBEU0NQICAgICAgICAgICB8IEVDTiBGSUVMRCB8IAogICAgICAg ICArLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rLS0tLS0rIAogICAg CiAgICAgICAgICAgRFNDUDogZGlmZmVyZW50aWF0ZWQgc2VydmljZXMgY29kZXBvaW50IAogICAg ICAgICAgIEVDTjogIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIAogICAgCiAgIEZp Z3VyZSBBLjE6IFRoZSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBhbmQgRUNOIEZpZWxkcyBpbiBJ UC4gCgogICBUaGUgdHdvIGJpdHMgb2YgdGhlIEVDTiBmaWVsZCBoYXZlIGZvdXIgRUNOIGNvZGVw b2ludHMsICcwMCcgdG8gJzExJzogCiAgICAgICAgICstLS0tLSstLS0tLSsgCiAgICAgICAgIHwg RUNOIEZJRUxEIHwgCiAgICAgICAgICstLS0tLSstLS0tLSsgCiAgICAgICAgICAgRUNUICAgQ0Ug ICAgICAgICAgCiAgICAgICAgICAgIDAgICAgIDAgICAgICAgICBOb3QtRUNUIAogICAgICAgICAg ICAwICAgICAxICAgICAgICAgRUNUKDEpIAogICAgICAgICAgICAxICAgICAwICAgICAgICAgRUNU KDApIAogICAgICAgICAgICAxICAgICAxICAgICAgICAgQ0UgCiAgICAKICAgRmlndXJlIEEuMjog VGhlIEVDTiBGaWVsZCBpbiBJUC4gCgogICBUaGUgbm90LUVDVCBjb2RlcG9pbnQgJzAwJyBpbmRp Y2F0ZXMgYSBwYWNrZXQgdGhhdCBpcyBub3QgdXNpbmcgRUNOLiAKCiAgIFRoZSBDRSBjb2RlcG9p bnQgJzExJyBpcyBzZXQgYnkgYSByb3V0ZXIgdG8gaW5kaWNhdGUgY29uZ2VzdGlvbiB0byAKICAg dGhlIGVuZCBob3N0cy4gVGhlIHRlcm0gJ0NFIHBhY2tldCcgZGVub3RlcyBhIHBhY2tldCB0aGF0 IGhhcyB0aGUgQ0UgCiAgIGNvZGVwb2ludCBzZXQuICAgCgogICBUaGUgRUNOLUNhcGFibGUgVHJh bnNwb3J0IChFQ1QpIGNvZGVwb2ludHMgJzEwJyBhbmQgJzAxJyAoRUNUKDApIGFuZCAKICAgRUNU KDEpIHJlc3BlY3RpdmVseSkgYXJlIHNldCBieSB0aGUgZGF0YSBzZW5kZXIgdG8gaW5kaWNhdGUg dGhhdCB0aGUgCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgNTJdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBs b3ltZW50IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIGVu ZC1wb2ludHMgb2YgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBhcmUgRUNOLWNhcGFibGUuIFJvdXRl cnMgdHJlYXQgCiAgIHRoZSBFQ1QoMCkgYW5kIEVDVCgxKSBjb2RlcG9pbnRzIGFzIGVxdWl2YWxl bnQuIFNlbmRlcnMgYXJlIGZyZWUgdG8gCiAgIHVzZSBlaXRoZXIgdGhlIEVDVCgwKSBvciB0aGUg RUNUKDEpIGNvZGVwb2ludCB0byBpbmRpY2F0ZSBFQ1QsIG9uIGEgCiAgIHBhY2tldC1ieS1wYWNr ZXQgYmFzaXMuIFRoZSBtb3RpdmF0aW9uIGZvciBoYXZpbmcgdHdvIGNvZGVwb2ludHMgKHRoZSAK ICAgJ0VDTiBub25jZScpIGlzIHRoZSBkZXNpcmUgdG8gY2hlY2sgdHdvIHRoaW5nczogZm9yIHRo ZSBkYXRhIHNlbmRlciAKICAgdG8gdmVyaWZ5IHRoYXQgbmV0d29yayBlbGVtZW50cyBhcmUgbm90 IGVyYXNpbmcgdGhlIENFIGNvZGVwb2ludDsgYW5kIAogICBmb3IgdGhlIGRhdGEgc2VuZGVyIHRv IHZlcmlmeSB0aGF0IGRhdGEgcmVjZWl2ZXJzIGFyZSBwcm9wZXJseSAKICAgcmVwb3J0aW5nIHRv IHRoZSBzZW5kZXIgdGhlIHJlY2VpcHQgb2YgcGFja2V0cyB3aXRoIHRoZSBDRSBjb2RlcG9pbnQg CiAgIHNldC4gCgogICBFQ04gcmVxdWlyZXMgc3VwcG9ydCBmcm9tIHRoZSB0cmFuc3BvcnQgcHJv dG9jb2wsIGluIGFkZGl0aW9uIHRvIHRoZSAKICAgZnVuY3Rpb25hbGl0eSBnaXZlbiBieSB0aGUg RUNOIGZpZWxkIGluIHRoZSBJUCBwYWNrZXQgaGVhZGVyLiAKICAgW1JGQzMxNjhdIGFkZHJlc3Nl cyB0aGUgYWRkaXRpb24gb2YgRUNOIENhcGFiaWxpdHkgdG8gVENQLCBzcGVjaWZ5aW5nIAogICB0 aHJlZSBuZXcgcGllY2VzIG9mIGZ1bmN0aW9uYWxpdHk6IG5lZ290aWF0aW9uIGJldHdlZW4gdGhl IGVuZHBvaW50cyAKICAgZHVyaW5nIGNvbm5lY3Rpb24gc2V0dXAgdG8gZGV0ZXJtaW5lIGlmIHRo ZXkgYXJlIGJvdGggRUNOLWNhcGFibGU7IGFuIAogICBFQ04tRWNobyAoRUNFKSBmbGFnIGluIHRo ZSBUQ1AgaGVhZGVyIHNvIHRoYXQgdGhlIGRhdGEgcmVjZWl2ZXIgY2FuIAogICBpbmZvcm0gdGhl IGRhdGEgc2VuZGVyIHdoZW4gYSBDRSBwYWNrZXQgaGFzIGJlZW4gcmVjZWl2ZWQ7IGFuZCBhIAog ICBDb25nZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIChDV1IpIGZsYWcgaW4gdGhlIFRDUCBoZWFkZXIg c28gdGhhdCB0aGUgCiAgIGRhdGEgc2VuZGVyIGNhbiBpbmZvcm0gdGhlIGRhdGEgcmVjZWl2ZXIg dGhhdCB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgCiAgIGhhcyBiZWVuIHJlZHVjZWQuIAoKICAgVGhl IHRyYW5zcG9ydCBsYXllciAoZS5nLi4gVENQKSBtdXN0IHJlc3BvbmQsIGluIHRlcm1zIG9mIGNv bmdlc3Rpb24gCiAgIGNvbnRyb2wsIHRvIGEgKnNpbmdsZSogQ0UgcGFja2V0IGFzIGl0IHdvdWxk IHRvIGEgcGFja2V0IGRyb3AuICAKCiAgIFRoZSBhZHZhbnRhZ2Ugb2Ygc2V0dGluZyB0aGUgQ0Ug Y29kZXBvaW50IGFzIGFuIGluZGljYXRpb24gb2YgCiAgIGNvbmdlc3Rpb24sIGluc3RlYWQgb2Yg cmVseWluZyBvbiBwYWNrZXQgZHJvcHMsIGlzIHRoYXQgaXQgYWxsb3dzIHRoZSAKICAgcmVjZWl2 ZXIocykgdG8gcmVjZWl2ZSB0aGUgcGFja2V0LCB0aHVzIGF2b2lkaW5nIHRoZSBwb3RlbnRpYWwg Zm9yIAogICBleGNlc3NpdmUgZGVsYXlzIGR1ZSB0byByZXRyYW5zbWlzc2lvbnMgYWZ0ZXIgcGFj a2V0IGxvc3Nlcy4gIAoKICAgIAoKMTEuMi4gQXBwZW5kaXggQjogV2hhdCBpcyBkaXN0cmlidXRl ZCBtZWFzdXJlbWVudC1iYXNlZCBhZG1pc3Npb24gCiAgIGNvbnRyb2w/ICAKCiAgIFRoaXMgQXBw ZW5kaXggYnJpZWZseSBleHBsYWlucyB3aGF0IGRpc3RyaWJ1dGVkIG1lYXN1cmVtZW50LWJhc2Vk IAogICBhZG1pc3Npb24gY29udHJvbCBpcyBbQnJlc2xhdTk5XS4gIAoKICAgVHJhZGl0aW9uYWwg YWRtaXNzaW9uIGNvbnRyb2wgYWxnb3JpdGhtcyBmb3IgJ2hhcmQnIHJlYWwtdGltZSAKICAgc2Vy dmljZXMgKHRob3NlIHByb3ZpZGluZyBhIGZpcm0gZGVsYXkgYm91bmQgZm9yIGV4YW1wbGUpIGd1 YXJhbnRlZSAKICAgUW9TIGJ5IHVzaW5nICd3b3JzdCBjYXNlIGFuYWx5c2lzJy4gRWFjaCB0aW1l IGEgZmxvdyBpcyBhZG1pdHRlZCBpdHMgCiAgIHRyYWZmaWMgcGFyYW1ldGVycyBhcmUgZXhhbWlu ZWQgYW5kIHRoZSBuZXR3b3JrIHJlLWNhbGN1bGF0ZXMgdGhlIAogICByZW1haW5pbmcgcmVzb3Vy Y2VzLiBXaGVuIHRoZSBuZXR3b3JrIGdldHMgYSBuZXcgcmVxdWVzdCBpdCB0aGVyZWZvcmUgCiAg IGtub3dzIGZvciBjZXJ0YWluIHdoZXRoZXIgdGhlIHByb3NwZWN0aXZlIGZsb3csIHdpdGggaXRz IHBhcnRpY3VsYXIgCiAgIHBhcmFtZXRlcnMsIHNob3VsZCBiZSBhZG1pdHRlZC4gSG93ZXZlciwg cGFyYW1ldGVyLWJhc2VkIGFkbWlzc2lvbiAKICAgY29udHJvbCBhbGdvcml0aG1zIHJlc3VsdCBp biB1bmRlci11dGlsaXNhdGlvbiB3aGVuIHRoZSB0cmFmZmljIGlzIAogICBidXJzdHkuIFRoZXJl Zm9yZSAnc29mdCcgcmVhbCB0aW1lIHNlcnZpY2VzIC0gbGlrZSBDb250cm9sbGVkIExvYWQgLSAK ICAgY2FuIHVzZSBhIG1vcmUgcmVsYXhlZCBhZG1pc3Npb24gY29udHJvbCBhbGdvcml0aG0uICAK IAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSA1M10gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9k ZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgVGhpcyBpbnNpZ2h0 IHN1Z2dlc3RzIG1lYXN1cmVtZW50LWJhc2VkIGFkbWlzc2lvbiBjb250cm9sIChNQkFDKS4gVGhl IAogICBhaW0gb2YgTUJBQyBpcyB0byBwcm92aWRlIGEgc3RhdGlzdGljYWwgc2VydmljZSBndWFy YW50ZWUuIFRoZSAKICAgY2xhc3NpYyBzY2VuYXJpbyBmb3IgTUJBQyBpcyB3aGVyZSBlYWNoIHJv dXRlciBwYXJ0aWNpcGF0ZXMgaW4gaG9wLQogICBieS1ob3AgYWRtaXNzaW9uIGNvbnRyb2wsIGNo YXJhY3RlcmlzaW5nIGV4aXN0aW5nIHRyYWZmaWMgbG9jYWxseSAKICAgdGhyb3VnaCBtZWFzdXJl bWVudHMgKGluc3RlYWQgb2Yga2VlcGluZyBhbiBhY2N1cmF0ZSB0cmFjayBvZiB0cmFmZmljIAog ICBhcyBpdCBpcyBhZG1pdHRlZCksIGluIG9yZGVyIHRvIGRldGVybWluZSB0aGUgY3VycmVudCB2 YWx1ZSBvZiBzb21lIAogICBwYXJhbWV0ZXIgZS5nLiBsb2FkLiBOb3RlIHRoYXQgZm9yIHNjYWxh YmlsaXR5IHRoZSBtZWFzdXJlbWVudCBpcyBvZiAKICAgdGhlIGFnZ3JlZ2F0ZSBvZiB0aGUgZmxv d3MgaW4gdGhlIGxvY2FsIHN5c3RlbS4gVGhlIG1lYXN1cmVkIAogICBwYXJhbWV0ZXIocykgaXMg dGhlbiBjb21wYXJlZCB0byB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBwcm9zcGVjdGl2ZSAKICAg ZmxvdyB0byBzZWUgd2hldGhlciBpdCBzaG91bGQgYmUgYWRtaXR0ZWQuICAKCiAgIE1CQUMgbWF5 IGFsc28gYmUgcGVyZm9ybWVkIGNlbnRyYWxseSBmb3IgYSBuZXR3b3JrLCBpdCB3aGljaCBjYXNl IGl0IAogICB1c2VzIGNlbnRyYWxpc2VkIG1lYXN1cmVtZW50cyBieSBhIGJhbmR3aWR0aCBicm9r ZXIuICAKCiAgIFdlIHVzZSBkaXN0cmlidXRlZCBNQkFDLiAiRGlzdHJpYnV0ZWQiIG1lYW5zIHRo YXQgdGhlIG1lYXN1cmVtZW50IGlzIAogICBhY2N1bXVsYXRlZCBmb3IgdGhlICd3aG9sZS1wYXRo JyB1c2luZyBpbi1iYW5kIHNpZ25hbGxpbmcuIEluIG91ciAKICAgY2FzZSwgdGhpcyBtZWFucyB0 aGF0IHRoZSBtZWFzdXJlbWVudCBvZiBleGlzdGluZyB0cmFmZmljIGlzIGZvciB0aGUgCiAgIHNh bWUgcGFpciBvZiBpbmdyZXNzIGFuZCBlZ3Jlc3MgZ2F0ZXdheXMgYXMgdGhlIHByb3NwZWN0aXZl IAogICBtaWNyb2Zsb3cuICAKCiAgIEluIGZhY3Qgb3VyIG1lY2hhbmlzbSBjYW4gYmUgc2FpZCB0 byBiZSBkaXN0cmlidXRlZCBpbiB0aHJlZSB3YXlzOiAKICAgYWxsIHJvdXRlcnMgb24gdGhlIGlu Z3Jlc3MtZWdyZXNzIHBhdGggYWZmZWN0IHRoZSBDb25nZXN0aW9uLUxldmVsLQogICBFc3RpbWF0 ZTsgdGhlIGFkbWlzc2lvbiBjb250cm9sIGRlY2lzaW9uIGlzIG1hZGUganVzdCBvbmNlIG9uIGJl aGFsZiAKICAgb2YgYWxsIHRoZSByb3V0ZXJzIG9uIHRoZSBwYXRoIGFjcm9zcyB0aGUgQ0wtcmVn aW9uOyBhbmQgdGhlIGluZ3Jlc3MgCiAgIGFuZCBlZ3Jlc3MgZ2F0ZXdheXMgY29vcGVyYXRlIHRv IHBlcmZvcm0gTUJBQy4gIAoKICAgIAoKMTEuMy4gQXBwZW5kaXggQzogQ2FsY3VsYXRpbmcgdGhl IEV4cG9uZW50aWFsbHkgd2VpZ2h0ZWQgbW92aW5nIGF2ZXJhZ2UgCiAgIChFV01BKSAKCiAgIEF0 IHRoZSBlZ3Jlc3MgZ2F0ZXdheSwgZm9yIGV2ZXJ5IENMIHBhY2tldCBhcnJpdmFsOiAKCiAgIFtF V01BLXRvdGFsLWJpdHNdbisxICA9ICAodyAqIGJpdHMtaW4tcGFja2V0KSAgKyAgKCgxLXcpICog W0VXTUEtIAogICB0b3RhbC1iaXRzXW4gKSAKCiAgIFtFV01BLU0tYml0c11uKzEgID0gIChCICog dyAqIGJpdHMtaW4tcGFja2V0KSAgKyAgKCgxLXcpICogW0VXTUEtTS0KICAgYml0c11uICkgCgog ICBUaGVuLCBwZXIgbmV3IGZsb3cgYXJyaXZhbDogCgogICBbQ29uZ2VzdGlvbi1MZXZlbC1Fc3Rp bWF0ZV1uKzEgID0gIFtFV01BLU0tYml0c11uKzEgIC8gIFtFV01BLXRvdGFsLQogICBiaXRzXW4r MSAgCgogICAgCgogICB3aGVyZSAKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBB cHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA1NF0gCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgIERlcGxveW1lbnQgTW9kZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAK ICAgIAoKICAgRVdNQS10b3RhbC1iaXRzIGlzIHRoZSB0b3RhbCBudW1iZXIgb2YgYml0cyBpbiBD TCBwYWNrZXRzLCBjYWxjdWxhdGVkIAogICBhcyBhbiBleHBvbmVudGlhbGx5IHdlaWdodGVkIG1v dmluZyBhdmVyYWdlIChFV01BKSAKCiAgIEVXTUEtTS1iaXRzIGlzIHRoZSB0b3RhbCBudW1iZXIg b2YgYml0cyBpbiBDTCBwYWNrZXRzIHRoYXQgYXJlIAogICBBZG1pc3Npb24gTWFya2VkIG9yIFBy ZS1lbXB0aW9uIE1hcmtlZCwgYWdhaW4gY2FsY3VsYXRlZCBhcyBhbiBFV01BLiAgCgogICBCIGlz IGVpdGhlciAwIG9yIDE6IAoKICAgICBCID0gMCBpZiB0aGUgQ0wgcGFja2V0IGlzIG5vdCBhZG1p c3Npb24gbWFya2VkICAKCiAgICAgQiA9IDEgaWYgdGhlIENMIHBhY2tldCBpcyBhZG1pc3Npb24g bWFya2VkIAoKICAgdyBpcyB0aGUgZXhwb25lbnRpYWwgd2VpZ2h0aW5nIGZhY3Rvci4gIAoKICAg IAogICBWYXJ5aW5nIHRoZSB2YWx1ZSBvZiB0aGUgd2VpZ2h0IHRyYWRlcyBvZmYgYmV0d2VlbiB0 aGUgc21vb3RobmVzcyBhbmQgCiAgIHJlc3BvbnNpdmVuZXNzIG9mIHRoZSBDb25nZXN0aW9uLUxl dmVsLUVzdGltYXRlLiBIb3dldmVyLCBpbiBnZW5lcmFsIAogICBib3RoIGNhbiBiZSBhY2hpZXZl ZCwgZ2l2ZW4gb3VyIG9yaWdpbmFsIGFzc3VtcHRpb24gb2YgbWFueSBDTCAKICAgbWljcm9mbG93 cyBhbmQgcmVtZW1iZXJpbmcgdGhhdCB0aGUgRVdNQSBpcyBjYWxjdWxhdGVkIG9uIHRoZSBiYXNp cyAKICAgb2YgYWdncmVnYXRlIHRyYWZmaWMgYmV0d2VlbiB0aGUgaW5ncmVzcyBhbmQgZWdyZXNz IGdhdGV3YXlzLiAgIAogICBUaGVyZSB3aWxsIGJlIGEgdGhyZXNob2xkIGludGVyLWFycml2YWwg dGltZSBiZXR3ZWVuIHBhY2tldHMgb2YgdGhlIAogICBzYW1lIGFnZ3JlZ2F0ZSBiZWxvdyB3aGlj aCB0aGUgZWdyZXNzIHdpbGwgY29uc2lkZXIgdGhlIGVzdGltYXRlIG9mIAogICB0aGUgQ29uZ2Vz dGlvbi1MZXZlbC1Fc3RpbWF0ZSBhcyB0b28gc3RhbGUsIGFuZCBpdCB3aWxsIHRoZW4gdHJpZ2dl ciAKICAgZ2VuZXJhdGlvbiBvZiBwcm9iZXMgYnkgdGhlIGluZ3Jlc3MuICAKICAgIAogICBUaGUg Zmlyc3QgdHdvIHBlci1wYWNrZXQgYWxnb3JpdGhtcyBjYW4gYmUgc2ltcGxpZmllZCwgaWYgdGhl aXIgb25seSAKICAgdXNlIHdpbGwgYmUgd2hlcmUgdGhlIHJlc3VsdCBvZiBvbmUgaXMgZGl2aWRl ZCBieSB0aGUgcmVzdWx0IG9mIHRoZSAKICAgb3RoZXIgaW4gdGhlIHRoaXJkLCBwZXItZmxvdyBh bGdvcml0aG0uIAogICAgCiAgIFtFV01BLXRvdGFsLWJpdHNdJ24rMSAgPSAgYml0cy1pbi1wYWNr ZXQgICsgICh3JyAqIFtFV01BLSB0b3RhbC0KICAgYml0c11uICkgCgogICBbRVdNQS1BTS1iaXRz XSduKzEgID0gIChCICogYml0cy1pbi1wYWNrZXQpICArICAodycgKiBbRVdNQS1BTS1iaXRzXW4g CiAgICkgCgogICB3aGVyZSB3JyA9ICgxLXcpL3cuIAoKICAgSWYgdycgaXMgYXJyYW5nZWQgdG8g YmUgYSBwb3dlciBvZiAyLCB0aGVzZSBwZXIgcGFja2V0IGFsZ29yaXRobXMgY2FuIAogICBiZSBp bXBsZW1lbnRlZCBzb2xlbHkgd2l0aCBhIHNoaWZ0IGFuZCBhbiBhZGQuIAoKICAgIAoKCgogCiAK QnJpc2NvZSAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAg ICAgIFtQYWdlIDU1XSAKDApJbnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1 c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAyMDA2IAogICAgCgogICBUaGVyZSBhcmUgYWx0ZXJu YXRpdmUgcG9zc2liaWxpdGllcyBmb3Igc21vb3RoaW5nIG91dCB0aGUgY29uZ2VzdGlvbi0KICAg bGV2ZWwtZXN0aW1hdGUuIEZvciBleGFtcGxlIFtURVdNQV0gZGVhbHMgYmV0dGVyIHdpdGggdGhl IGlzc3VlIG9mIAogICBzdGFsZSBpbmZvcm1hdGlvbiB3aGVuIHRoZSB0cmFmZmljIHJhdGUgZm9y ICAKCiAgICAgCiAgICAKCjEyLiBSZWZlcmVuY2VzIAoKICAgQSBsYXRlciB2ZXJzaW9uIHdpbGwg ZGlzdGluZ3Vpc2ggbm9ybWF0aXZlIGFuZCBpbmZvcm1hdGl2ZSAKICAgcmVmZXJlbmNlcy4gCgog ICBbQUdHUkUtVEVdICAgIEZyYW5jb2lzIExlIEZhdWNoZXVyLCBNaWNoYWVsIERpYmlhc2lvLCBC cnVjZSBEYXZpZSwgCiAgICAgICAgICAgICAgICAgTWljaGFlbCBEYXZlbnBvcnQsIENocmlzIENo cmlzdG91LCBKZXJyeSBBc2gsIEJ1ciAKICAgICAgICAgICAgICAgICBHb29kZSwgJ0FnZ3JlZ2F0 aW9uIG9mIFJTVlAgUmVzZXJ2YXRpb25zIG92ZXIgTVBMUyAKICAgICAgICAgICAgICAgICBURS9E Uy1URSBUdW5uZWxzJywgZHJhZnQtaWV0Zi10c3Z3Zy1yc3ZwLWRzdGUtMDMgKHdvcmsgCiAgICAg ICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDYgIAoKICAgW0FOU0kuTUxQUC5TcGVj XSBBbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAKICAgICAgICAgICAgICAg ICAiVGVsZWNvbW11bmljYXRpb25zLSBJbnRlZ3JhdGVkIFNlcnZpY2VzIERpZ2l0YWwgCiAgICAg ICAgICAgICAgICAgTmV0d29yayAoSVNETikgLSBNdWx0aS1MZXZlbCBQcmVjZWRlbmNlIGFuZCBQ cmUtCiAgICAgICAgICAgICAgICAgZW1wdGlvbiAoTUxQUCkgU2VydmljZSBDYXBhYmlsaXR5Iiwg QU5TSSBUMS42MTktMTk5MiAKICAgICAgICAgICAgICAgICAoUjE5OTkpLCAxOTkyLiAKCiAgIFtB TlNJLk1MUFAuU3VwcGxlbWVudF0gQW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0 ZSwgIk1MUFAgCiAgICAgICAgICAgICAgICAgU2VydmljZSBEb21haW4gQ2F1c2UgVmFsdWUgQ2hh bmdlcyIsIEFOU0kgQU5TSSAKICAgICAgICAgICAgICAgICBUMS42MTlhLTE5OTQgKFIxOTk5KSwg MTk5MC4gCgogICBbQVZRXSAgICAgICAgIFMuIEt1bm5peXVyIGFuZCBSLiBTcmlrYW50ICJBbmFs eXNpcyBhbmQgRGVzaWduIG9mIGFuIAogICAgICAgICAgICAgICAgIEFkYXB0aXZlIFZpcnR1YWwg UXVldWUgKEFWUSkgQWxnb3JpdGhtIGZvciBBY3RpdmUgCiAgICAgICAgICAgICAgICAgUXVldWUg TWFuYWdlbWVudCIsIEluOiBQcm9jLiBBQ00gU0lHQ09NTScwMSwgQ29tcHV0ZXIgCiAgICAgICAg ICAgICAgICAgQ29tbXVuaWNhdGlvbiBSZXZpZXcgMzEgKDQpIChPY3RvYmVyLCAyMDAxKS4gCgog ICBbQnJlc2xhdTk5XSAgIEwuIEJyZXNsYXUsIFMuIEphbWluLCBTLiBTaGVua2VyICJNZWFzdXJl bWVudC1iYXNlZCAKICAgICAgICAgICAgICAgICBhZG1pc3Npb24gY29udHJvbDogd2hhdCBpcyB0 aGUgcmVzZWFyY2ggYWdlbmRhPyIsIEluOiAKICAgICAgICAgICAgICAgICBQcm9jLiBJbnQnbCBX b3Jrc2hvcCBvbiBRdWFsaXR5IG9mIFNlcnZpY2UgMTk5OS4gCgogICBbQnJlc2xhdTAwXSAgIEwu IEJyZXNsYXUsIEUuIEtuaWdodGx5LCBTLiBTaGVua2VyLCBJLiBTdG9pY2EsIEguIAogICAgICAg ICAgICAgICAgIFpoYW5nICJFbmRwb2ludCBBZG1pc3Npb24gQ29udHJvbDogQXJjaGl0ZWN0dXJh bCAKICAgICAgICAgICAgICAgICBJc3N1ZXMgYW5kIFBlcmZvcm1hbmNlIiwgSW46IEFDTSBTSUdD T01NIDIwMDAgIAoKICAgW0JyaXNjb2VdICAgICBCb2IgQnJpc2NvZSBhbmQgU3RldmUgUnVka2lu LCAiQ29tbWVyY2lhbCBNb2RlbHMgZm9yIAogICAgICAgICAgICAgICAgIElQIFF1YWxpdHkgb2Yg U2VydmljZSBJbnRlcmNvbm5lY3QiLCBCVCBUZWNobm9sb2d5IAogICAgICAgICAgICAgICAgIEpv dXJuYWwsIFZvbCAyMyBObyAyLCBBcHJpbCAyMDA1LiAKCgogCiAKQnJpc2NvZSAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDU2XSAKDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAg T2N0b2JlciAyMDA2IAogICAgCgogICBbRENBQ10gICAgICAgIFJpY2hhcmQgSi4gR2liYmVucyBh bmQgRnJhbmsgUC4gS2VsbHkgIkRpc3RyaWJ1dGVkIAogICAgICAgICAgICAgICAgIGNvbm5lY3Rp b24gYWNjZXB0YW5jZSBjb250cm9sIGZvciBhIGNvbm5lY3Rpb25sZXNzIAogICAgICAgICAgICAg ICAgIG5ldHdvcmsiLCBJbjogUHJvYy4gSW50ZXJuYXRpb25hbCBUZWxldHJhZmZpYyBDb25ncmVz cyAKICAgICAgICAgICAgICAgICAoSVRDMTYpLCBFZGluYnVyZ2gsIHBwLiA5NDGXOTUyICgxOTk5 KS4gCgogICBbRUNOLU1QTFNdICAgIEJydWNlIERhdmllLCBCb2IgQnJpc2NvZSwgSnVuZSBUYXks ICJFeHBsaWNpdCAKICAgICAgICAgICAgICAgICBDb25nZXN0aW9uIE1hcmtpbmcgaW4gTVBMUyIs ICAgICAgICAgICAgICAgICAgICBkcmFmdC0KICAgICAgICAgICAgICAgICBkYXZpZS1lY24tbXBs cy0wMC50eHQgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDYgCgogICBbRU1FUkctUlFUU10g IENhcmxiZXJnLCBLLiBhbmQgUi4gQXRraW5zb24sICJHZW5lcmFsIFJlcXVpcmVtZW50cyAKICAg ICAgICAgICAgICAgICBmb3IgRW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2UgKEVU UykiLCBSRkMgCiAgICAgICAgICAgICAgICAgMzY4OSwgRmVicnVhcnkgMjAwNC4gCgogICBbRU1F UkctVEVMXSAgIENhcmxiZXJnLCBLLiBhbmQgUi4gQXRraW5zb24sICJJUCBUZWxlcGhvbnkgCiAg ICAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRp b24gU2VydmljZSAKICAgICAgICAgICAgICAgICAoRVRTKSIsIFJGQyAzNjkwLCBGZWJydWFyeSAy MDA0LiAKCiAgIFtGbG95ZF0gICAgICAgUy4gRmxveWQsICdTcGVjaWZ5aW5nIEFsdGVybmF0ZSBT ZW1hbnRpY3MgZm9yIHRoZSAKICAgICAgICAgICAgICAgICBFeHBsaWNpdCBDb25nZXN0aW9uIE5v dGlmaWNhdGlvbiAoRUNOKSBGaWVsZCcsIGRyYWZ0LQogICAgICAgICAgICAgICAgIGZsb3lkLWVj bi1hbHRlcm5hdGVzLTAyLnR4dCAod29yayBpbiBwcm9ncmVzcyksIEF1Z3VzdCAKICAgICAgICAg ICAgICAgICAyMDA1ICAKCiAgIFtHU1BhXSAgICAgICAgS2Fyc3RlbiAoRWQuKSwgTWFydGluICJH U1AvRUNOIFRlY2hub2xvZ3kgJiAKICAgICAgICAgICAgICAgICBFeHBlcmltZW50cyIsIERlbGl2 ZXJhYmxlOiAxNS4zIFB0SUlJLCBNM0kgRXUgVnRoIAogICAgICAgICAgICAgICAgIEZyYW1ld29y ayBQcm9qZWN0IElTVC0xOTk5LTExNDI5LCBVUkw6IAogICAgICAgICAgICAgICAgIGh0dHA6Ly93 d3cubTNpLm9yZy8gKEZlYnJ1YXJ5LCAyMDAyKSAoc3VwZXJzZWRlZCBieSAKICAgICAgICAgICAg ICAgICBbR1NQLVRSXSkgCgogICBbR1NQLVRSXSAgICAgIE1hcnRpbiBLYXJzdGVuIGFuZCBKZW5z IFNjaG1pdHQsICJBZG1pc3Npb24gQ29udHJvbCAKICAgICAgICAgICAgICAgICBCYXNlZCBvbiBQ YWNrZXQgTWFya2luZyBhbmQgRmVlZGJhY2sgU2lnbmFsbGluZyCtLS0gCiAgICAgICAgICAgICAg ICAgTWVjaGFuaXNtcywgSW1wbGVtZW50YXRpb24gYW5kIEV4cGVyaW1lbnRzIiwgVFUtCiAgICAg ICAgICAgICAgICAgRGFybXN0YWR0IFRlY2huaWNhbCBSZXBvcnQgVFItS09NLTIwMDItMDMsIFVS TDogCiAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5rb20uZS10ZWNobmlrLnR1LQogICAgICAg ICAgICAgICAgIGRhcm1zdGFkdC5kZS9wdWJsaWNhdGlvbnMvYWJzdHJhY3RzL0tTMDItNS5odG1s IChNYXksIAogICAgICAgICAgICAgICAgIDIwMDIpICAKCiAgIFtJVFUuTUxQUC4xOTkwXSBJbnRl cm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0aW9ucyBVbmlvbiwgIk11bHRpbGV2ZWwgCiAgICAgICAg ICAgICAgICAgUHJlY2VkZW5jZSBhbmQgUHJlLWVtcHRpb24gU2VydmljZSAoTUxQUCkiLCBJVFUt VCAKICAgICAgICAgICAgICAgICBSZWNvbW1lbmRhdGlvbiBJLjI1NS4zLCAxOTkwLiAgCgogICBb Sm9obnNvbl0gICAgIERNIEpvaG5zb24sICdRb1MgY29udHJvbCB2ZXJzdXMgZ2VuZXJvdXMgCiAg ICAgICAgICAgICAgICAgZGltZW5zaW9uaW5nJywgQlQgVGVjaG5vbG9neSBKb3VybmFsLCBWb2wg MjMgTm8gMiwgCiAgICAgICAgICAgICAgICAgQXByaWwgMjAwNSAKCgoKCiAKIApCcmlzY29lICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2Ug NTddIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVsIHVzaW5nIFBDTiAg ICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIFtMb2FkQmFsYW5jaW5nLWFdIFJ1ZWRpZ2Vy IE1hcnRpbiwgTWljaGFlbCBNZW50aCwgYW5kIE1pY2hhZWwgCiAgICAgICAgICAgICAgICAgSGVt bWtlcHBsZXI6ICJBY2N1cmFjeSBhbmQgRHluYW1pY3Mgb2YgSGFzaC1CYXNlZCBMb2FkIAogICAg ICAgICAgICAgICAgIEJhbGFuY2luZyBBbGdvcml0aG1zIGZvciBNdWx0aXBhdGggSW50ZXJuZXQg Um91dGluZyIsIAogICAgICAgICAgICAgICAgIElFRUUgQnJvYWRuZXRzLCBTYW4gSm9zZSwgQ0Es IFVTQSwgT2N0b2JlciAyMDA2IAogICAgICAgICAgICAgICAgIGh0dHA6Ly93d3czLmluZm9ybWF0 aWsudW5pLQogICAgICAgICAgICAgICAgIHd1ZXJ6YnVyZy5kZS9+bWVudGgvUHVibGljYXRpb25z L01lbnRoMDZwLnBkZiAKCiAgIFtMb2FkQmFsYW5jaW5nLWJdIFJ1ZWRpZ2VyIE1hcnRpbiwgTWlj aGFlbCBNZW50aCwgYW5kIE1pY2hhZWwgCiAgICAgICAgICAgICAgICAgSGVtbWtlcHBsZXI6ICJB Y2N1cmFjeSBhbmQgRHluYW1pY3Mgb2YgTXVsdGktU3RhZ2UgCiAgICAgICAgICAgICAgICAgTG9h ZCBCYWxhbmNpbmcgZm9yIE11bHRpcGF0aCBJbnRlcm5ldCBSb3V0aW5nIiwgCiAgICAgICAgICAg ICAgICAgY3VycmVudGx5IHVuZGVyIHN1Ym1pc3Npb24gaHR0cDovL3d3dzMuaW5mb3JtYXRpay51 bmktCiAgICAgICAgICAgICAgICAgd3VlcnpidXJnLmRlL35tZW50aC9QdWJsaWNhdGlvbnMvTWVu dGgwNy1TdWItNi5wZGYgIAoKICAgW0xvd10gICAgICAgICBTLiBMb3csIEwuIEFuZHJldywgQi4g V3lkcm93c2tpLCAnVW5kZXJzdGFuZGluZyBYQ1A6IAogICAgICAgICAgICAgICAgIGVxdWlsaWJy aXVtIGFuZCBmYWlybmVzcycsIElFRUUgSW5mb0NvbSAyMDA1IAoKICAgW05BQy1hXSAgICAgICBN aWNoYWVsIE1lbnRoOiAiRWZmaWNpZW50IEFkbWlzc2lvbiBDb250cm9sIGFuZCAKICAgICAgICAg ICAgICAgICBSb3V0aW5nIGluIFJlc2lsaWVudCBDb21tdW5pY2F0aW9uIE5ldHdvcmtzIiwgUGhE IAogICAgICAgICAgICAgICAgIHRoZXNpcywgSnVseSAyMDA0LCBodHRwOi8vb3B1cy5iaWJsaW90 aGVrLnVuaS0KICAgICAgICAgICAgICAgICB3dWVyemJ1cmcuZGUvb3B1cy92b2xsdGV4dGUvMjAw NC85OTQvcGRmL01lbnRoMDQucGRmIAoKICAgW05BQy1iXSAgICAgICBNaWNoYWVsIE1lbnRoLCBT dGVmYW4gS29wZiwgSm9hY2hpbSBDaGFyemluc2tpLCBhbmQgCiAgICAgICAgICAgICAgICAgS2Fy bCBTY2hyb2RpOiAiUmVzaWxpZW50IE5ldHdvcmsgQWRtaXNzaW9uIENvbnRyb2wiLCAKICAgICAg ICAgICAgICAgICBjdXJyZW50bHkgdW5kZXIgc3VibWlzc2lvbi4gCiAgICAgICAgICAgICAgICAg aHR0cDovL3d3dzMuaW5mb3JtYXRpay51bmktCiAgICAgICAgICAgICAgICAgd3VlcnpidXJnLmRl L35tZW50aC9QdWJsaWNhdGlvbnMvTWVudGgwNy1TdWItMy5wZGYgIAoKICAgW1BDTl0gICAgICAg ICBCLiBCcmlzY29lLCBQLiBFYXJkbGV5LCBELiBTb25naHVyc3QsIEYuIExlIEZhdWNoZXVyLCAK ICAgICAgICAgICAgICAgICBBLiBDaGFybnksIFYuIExpYXRzb3MsIFMuIER1ZGxleSwgSi4gQmFi aWFyeiwgSy4gQ2hhbiwgCiAgICAgICAgICAgICAgICAgRy4gS2FyYWdpYW5uaXMsIEEuIEJhZGVy LCBMLiBXZXN0YmVyZy4gJ1ByZS1Db25nZXN0aW9uIAogICAgICAgICAgICAgICAgIE5vdGlmaWNh dGlvbiBtYXJraW5nJywgZHJhZnQtYnJpc2NvZS10c3Z3Zy1jbC1waGItMDIgCiAgICAgICAgICAg ICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDYuIAoKICAgW1JlLUVDTl0gICAgICBC b2IgQnJpc2NvZSwgQXJuYXVkIEphY3F1ZXQsIEFsZXNzYW5kcm8gU2FsdmF0b3JpLCAKICAgICAg ICAgICAgICAgICAnUmUtRUNOOiBBZGRpbmcgQWNjb3VudGFiaWxpdHkgZm9yIENhdXNpbmcgQ29u Z2VzdGlvbiAKICAgICAgICAgICAgICAgICB0byBUQ1AvSVAnLCBkcmFmdC1icmlzY29lLXRzdndn LXJlLWVjbi10Y3AtMDEgKHdvcmsgaW4gCiAgICAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBNYXJj aCAyMDA2LiAKCiAgIFtSZS1mZWVkYmFja10gQm9iIEJyaXNjb2UsIEFybmF1ZCBKYWNxdWV0LCBD YXJsYSBEaSBDYWlyYW5vLQogICAgICAgICAgICAgICAgIEdpbGZlZGRlciwgQW5kcmVhIFNvcHBl cmEsICdSZS1mZWVkYmFjayBmb3IgUG9saWNpbmcgCiAgICAgICAgICAgICAgICAgQ29uZ2VzdGlv biBSZXNwb25zZSBpbiBhbiBJbnRlci1uZXR3b3JrJywgQUNNIFNJR0NPTU0gCiAgICAgICAgICAg ICAgICAgMjAwNSwgQXVndXN0IDIwMDUuIAoKICAgW1JlLVBDTl0gICAgICBCLiBCcmlzY29lLCAn RW11bGF0aW5nIEJvcmRlciBGbG93IFBvbGljaW5nIHVzaW5nIFJlLQogICAgICAgICAgICAgICAg IEVDTiBvbiBCdWxrIERhdGEnLCBkcmFmdC1icmlzY29lLXRzdndnLXJlLWVjbi1ib3JkZXItCiAg ICAgICAgICAgICAgICAgY2hlYXQtMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDA2 LiAKCiAKIApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAg ICAgICAgICAgICAgW1BhZ2UgNThdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50 IE1vZGVsIHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIFtSZWlkXSAg ICAgICAgQUJEIFJlaWQsICdFY29ub21pY3MgYW5kIHNjYWxhYmlsaXR5IG9mIFFvUyAKICAgICAg ICAgICAgICAgICBzb2x1dGlvbnMnLCBCVCBUZWNobm9sb2d5IEpvdXJuYWwsIFZvbCAyMyBObyAy LCBBcHJpbCAKICAgICAgICAgICAgICAgICAyMDA1IAoKICAgW1JGQzIyMTFdICAgICBKLiBXcm9j bGF3c2tpLCBTcGVjaWZpY2F0aW9uIG9mIHRoZSBDb250cm9sbGVkLUxvYWQgCiAgICAgICAgICAg ICAgICAgTmV0d29yayBFbGVtZW50IFNlcnZpY2UsIFNlcHRlbWJlciAxOTk3IAoKICAgW1JGQzIz MDldICAgICBCcmFkZW4sIEIuLCBldCBhbC4sICJSZWNvbW1lbmRhdGlvbnMgb24gUXVldWUgCiAg ICAgICAgICAgICAgICAgTWFuYWdlbWVudCBhbmQgQ29uZ2VzdGlvbiBBdm9pZGFuY2UgaW4gdGhl IEludGVybmV0IiwgCiAgICAgICAgICAgICAgICAgUkZDIDIzMDksIEFwcmlsIDE5OTguIAoKICAg W1JGQzI0NzRdICAgICBOaWNob2xzLCBLLiwgQmxha2UsIFMuLCBCYWtlciwgRi4gYW5kIEQuIEJs YWNrLCAKICAgICAgICAgICAgICAgICAiRGVmaW5pdGlvbiBvZiB0aGUgRGlmZmVyZW50aWF0ZWQg U2VydmljZXMgRmllbGQgKERTIAogICAgICAgICAgICAgICAgIEZpZWxkKSBpbiB0aGUgSVB2NCBh bmQgSVB2NiBIZWFkZXJzIiwgUkZDIDI0NzQsIAogICAgICAgICAgICAgICAgIERlY2VtYmVyIDE5 OTggCgogICBbUkZDMjQ3NV0gICAgIEJsYWtlLCBTLiwgQmxhY2ssIEQuLCBDYXJsc29uLCBNLiwg RGF2aWVzLCBFLiwgV2FuZywgCiAgICAgICAgICAgICAgICAgWi4gYW5kIFcuIFdlaXNzLCAnQSBm cmFtZXdvcmsgZm9yIERpZmZlcmVudGlhdGVkIAogICAgICAgICAgICAgICAgIFNlcnZpY2VzJywg UkZDIDI0NzUsIERlY2VtYmVyIDE5OTguIAoKICAgW1JGQzI1OTddICAgICBIZWluYW5lbiwgSi4s IEJha2VyLCBGLiwgV2Vpc3MsIFcuIGFuZCBKLiBXcm9ja2xhd3NraSwgCiAgICAgICAgICAgICAg ICAgIkFzc3VyZWQgRm9yd2FyZGluZyBQSEIgR3JvdXAiLCBSRkMgMjU5NywgSnVuZSAxOTk5LiAK CiAgIFtSRkMyOTk4XSAgICAgQmVybmV0LCBZLiwgWWF2YXRrYXIsIFIuLCBGb3JkLCBQLiwgQmFr ZXIsIEYuLCBaaGFuZywgCiAgICAgICAgICAgICAgICAgTC4sIFNwZWVyLCBNLiwgQnJhZGVuLCBS LiwgRGF2aWUsIEIuLCBXcm9jbGF3c2tpLCBKLiAKICAgICAgICAgICAgICAgICBhbmQgRS4gRmVs c3RhaW5lLCAiQSBGcmFtZXdvcmsgZm9yIEludGVncmF0ZWQgU2VydmljZXMgCiAgICAgICAgICAg ICAgICAgT3BlcmF0aW9uIE92ZXIgRGlmZlNlcnYgTmV0d29ya3MiLCBSRkMgMjk5OCwgTm92ZW1i ZXIgCiAgICAgICAgICAgICAgICAgMjAwMC4gCgogICBbUkZDMzE2OF0gICAgIFJhbWFrcmlzaG5h biwgSy4sIEZsb3lkLCBTLiBhbmQgRC4gQmxhY2sgIlRoZSBBZGRpdGlvbiAKICAgICAgICAgICAg ICAgICBvZiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBJUCIsIFJG QyAKICAgICAgICAgICAgICAgICAzMTY4LCBTZXB0ZW1iZXIgMjAwMS4gCgogICBbUkZDMzI0Nl0g ICAgIEIuIERhdmllLCBBLiBDaGFybnksIEouQy5SLiBCZW5uZXQsIEsuIEJlbnNvbiwgSi5ZLiBM ZSAKICAgICAgICAgICAgICAgICBCb3VkZWMsIFcuIENvdXJ0bmV5LCBTLiBEYXZhcmksIFYuIEZp cm9pdSwgRC4gCiAgICAgICAgICAgICAgICAgU3RpbGlhZGlzLCAnQW4gRXhwZWRpdGVkIEZvcndh cmRpbmcgUEhCIChQZXItSG9wIAogICAgICAgICAgICAgICAgIEJlaGF2aW9yKScsIFJGQyAzMjQ2 LCBNYXJjaCAyMDAyLiAKCiAgIFtSRkMzMjcwXSAgICAgTGUgRmF1Y2hldXIsIEYuLCBXdSwgTC4s IERhdmllLCBCLiwgRGF2YXJpLCBTLiwgCiAgICAgICAgICAgICAgICAgVmFhbmFuZW4sIFAuLCBL cmlzaG5hbiwgUi4sIENoZXZhbCwgUC4sIGFuZCBKLiAKICAgICAgICAgICAgICAgICBIZWluYW5l biwgIk11bHRpLSBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIAogICAgICAgICAgICAg ICAgIFN1cHBvcnQgb2YgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMiLCBSRkMgMzI3MCwgTWF5IAog ICAgICAgICAgICAgICAgIDIwMDIuIAoKICAgW1JGQzQ1NDJdICAgICBGLiBCYWtlciAmIEouIFBv bGssICJJbXBsZW1lbnRpbmcgYW4gRW1lcmdlbmN5IAogICAgICAgICAgICAgICAgIFRlbGVjb21t dW5pY2F0aW9ucyBTZXJ2aWNlIGZvciBSZWFsIFRpbWUgU2VydmljZXMgaW4gCiAgICAgICAgICAg ICAgICAgdGhlIEludGVybmV0IFByb3RvY29sIFN1aXRlIiwgUkZDIDQ1NDIsIE1heSAyMDA2LiAK IAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSA1OV0gCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIERlcGxveW1lbnQgTW9k ZWwgdXNpbmcgUENOICAgICAgICAgIE9jdG9iZXIgMjAwNiAKICAgIAoKICAgW1JNRF0gICAgICAg ICBBdHRpbGEgQmFkZXIsIExhcnMgV2VzdGJlcmcsIEdlb3JnaW9zIEthcmFnaWFubmlzLCAKICAg ICAgICAgICAgICAgICBDb3JuZWxpYSBLYXBwbGVyLCBUb20gUGhlbGFuLCAnUk1ELVFPU00gLSBU aGUgUmVzb3VyY2UgCiAgICAgICAgICAgICAgICAgTWFuYWdlbWVudCBpbiBEaWZmU2VydiBRb1Mg bW9kZWwnLCBkcmFmdC1pZXRmLW5zaXMtCiAgICAgICAgICAgICAgICAgcm1kLTAzIFdvcmsgaW4g UHJvZ3Jlc3MsIEp1bmUgMjAwNS4gCgogICBbUlNWUC1QQ05dICAgIEZyYW5jb2lzIExlIEZhdWNo ZXVyLCBBbm5hIENoYXJueSwgQm9iIEJyaXNjb2UsIFBoaWxpcCAKICAgICAgICAgICAgICAgICBF YXJkbGV5LCBKb2UgQmFyYmlheiwgS3dvay1IbyBDaGFuLCAnUlNWUCBFeHRlbnNpb25zIAogICAg ICAgICAgICAgICAgIGZvciBBZG1pc3Npb24gQ29udHJvbCBvdmVyIERpZmZTZXJ2IHVzaW5nIFBy ZS0KICAgICAgICAgICAgICAgICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoUENOKScsIGRyYWZ0 LWxlZmF1Y2hldXItcnN2cC0KICAgICAgICAgICAgICAgICBlY24tMDEgKHdvcmsgaW4gcHJvZ3Jl c3MpLCBKdW5lIDIwMDYuIAoKICAgW1JTVlAtUFJFRU1QVElPTl0gSGVyem9nLCBTLiwgIlNpZ25h bGVkIFByZWVtcHRpb24gUHJpb3JpdHkgUG9saWN5IAogICAgICAgICAgICAgICAgIEVsZW1lbnQi LCBSRkMgMzE4MSwgT2N0b2JlciAyMDAxLiAgCgogICBbUlNWUC1FTUVSR0VOQ1ldIExlIEZhdWNo ZXVyIGV0IGFsLiwgUlNWUCBFeHRlbnNpb25zIGZvciBFbWVyZ2VuY3kgCiAgICAgICAgICAgICAg ICAgU2VydmljZXMsIGRyYWZ0LWxlZmF1Y2hldXItZW1lcmdlbmN5LXJzdnAtMDIudHh0IAoKICAg W1JURUNOXSAgICAgICBCYWJpYXJ6LCBKLiwgQ2hhbiwgSy4gYW5kIFYuIEZpcm9pdSwgJ0Nvbmdl c3Rpb24gCiAgICAgICAgICAgICAgICAgTm90aWZpY2F0aW9uIFByb2Nlc3MgZm9yIFJlYWwtVGlt ZSBUcmFmZmljJywgZHJhZnQtCiAgICAgICAgICAgICAgICAgYmFiaWFyei10c3Z3Zy1ydGVjbi0w NCBXb3JrIGluIFByb2dyZXNzLCBKdWx5IDIwMDUuIAoKICAgW1JURUNOLXVzYWdlXSBBbGV4YW5k ZXIsIEMuLCBFZC4sIEJhYmlhcnosIEouIGFuZCBKLiBNYXR0aGV3cywgCiAgICAgICAgICAgICAg ICAgJ0FkbWlzc2lvbiBDb250cm9sIFVzZSBDYXNlIGZvciBSZWFsLXRpbWUgRUNOJywgZHJhZnQt CiAgICAgICAgICAgICAgICAgYWxleGFuZGVyLXJ0ZWNuLWFkbWlzc2lvbi1jb250cm9sLXVzZS1j YXNlLTAwLCBXb3JrIGluIAogICAgICAgICAgICAgICAgIFByb2dyZXNzLCBGZWJydWFyeSAyMDA1 LiAKCiAgIFtTb25naHVyc3RdICAgRGF2aWQgSi4gU29uZ2h1cnN0LCBQaGlsaXAgRWFyZGxleSwg Qm9iIEJyaXNjb2UsIENhcmxhIAogICAgICAgICAgICAgICAgIERpIENhaXJhbm8gR2lsZmVkZGVy IGFuZCBKdW5lIFRheSwgJ0d1YXJhbnRlZWQgUW9TIAogICAgICAgICAgICAgICAgIFN5bnRoZXNp cyBmb3IgQWRtaXNzaW9uIENvbnRyb2wgd2l0aCBTaGFyZWQgQ2FwYWNpdHknLCAKICAgICAgICAg ICAgICAgICBCVCBUZWNobmljYWwgUmVwb3J0IFRSLUNYUjktMjAwNi0wMDEsIEZlYiAyMDA2LCAK ICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LmNzLnVjbC5hYy51ay9zdGFmZi9CLkJyaXNjb2Uv cHJvamVjdHMvaXBlMmUKICAgICAgICAgICAgICAgICBxb3MvZ3FzL3BhcGVycy9HUVNfc2hhcmVk X3RyLnBkZiAgCgogICBbdnFdICAgICAgICAgIENvc3RhcyBDb3VyY291YmV0aXMgYW5kIFJpY2hh cmQgV2ViZXIgIkJ1ZmZlciBPdmVyZmxvdyAKICAgICAgICAgICAgICAgICBBc3ltcHRvdGljcyBm b3IgYSBTd2l0Y2ggSGFuZGxpbmcgTWFueSBUcmFmZmljIAogICAgICAgICAgICAgICAgIFNvdXJj ZXMiIEluOiBKb3VybmFsIEFwcGxpZWQgUHJvYmFiaWxpdHkgMzMgcHAuIDg4Ni0tCiAgICAgICAg ICAgICAgICAgOTAzICgxOTk2KS4gCgogICAgCgoKCgoKCgogCiAKQnJpc2NvZSAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDYwXSAKDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAg T2N0b2JlciAyMDA2IAogICAgCgpBdXRob3JzJyBBZGRyZXNzZXMgCgogICBCb2IgQnJpc2NvZSAK ICAgQlQgUmVzZWFyY2ggCiAgIEI1NC83NywgU2lyaXVzIEhvdXNlIAogICBBZGFzdHJhbCBQYXJr IAogICBNYXJ0bGVzaGFtIEhlYXRoIAogICBJcHN3aWNoLCBTdWZmb2xrIAogICBJUDUgM1JFIAog ICBVbml0ZWQgS2luZ2RvbSAKICAgRW1haWw6IGJvYi5icmlzY29lQGJ0LmNvbSAKICAgIAogICBE YXZlIFNvbmdodXJzdCAKICAgQlQgUmVzZWFyY2ggCiAgIEI1NC82OSwgU2lyaXVzIEhvdXNlIAog ICBBZGFzdHJhbCBQYXJrIAogICBNYXJ0bGVzaGFtIEhlYXRoIAogICBJcHN3aWNoLCBTdWZmb2xr IAogICBJUDUgM1JFIAogICBVbml0ZWQgS2luZ2RvbSAKICAgRW1haWw6IGRzb25naHVyc3RAanVu Z2xlLmJ0LmNvLnVrIAogICAgCiAgIFBoaWxpcCBFYXJkbGV5IAogICBCVCBSZXNlYXJjaCAKICAg QjU0Lzc3LCBTaXJpdXMgSG91c2UgCiAgIEFkYXN0cmFsIFBhcmsgCiAgIE1hcnRsZXNoYW0gSGVh dGggCiAgIElwc3dpY2gsIFN1ZmZvbGsgCiAgIElQNSAzUkUgCiAgIFVuaXRlZCBLaW5nZG9tIAog ICBFbWFpbDogcGhpbGlwLmVhcmRsZXlAYnQuY29tIAogICAgCiAgIEZyYW5jb2lzIExlIEZhdWNo ZXVyICAKICAgQ2lzY28gU3lzdGVtcywgSW5jLiAgCiAgIFZpbGxhZ2UgZCdFbnRyZXByaXNlIEdy ZWVuIFNpZGUgLSBCYXRpbWVudCBUMyAgCiAgIDQwMCwgQXZlbnVlIGRlIFJvdW1hbmlsbGUgIAog ICAwNjQxMCBCaW90IFNvcGhpYS1BbnRpcG9saXMgIAogICBGcmFuY2UgICAgICAgICAgICAgICAg ICAgIAogICBFbWFpbDogZmxlZmF1Y2hAY2lzY28uY29tICAKICAgIAogICBBbm5hIENoYXJueSAg CiAgIENpc2NvIFN5c3RlbXMgIAogICAzMDAgQXBvbGxvIERyaXZlICAKICAgQ2hlbG1zZm9yZCwg TUEgMDE4MjQgIAogICBVU0EgIAogICBFbWFpbDogYWNoYXJueUBjaXNjby5jb20gIAogICAgCiAK IApCcmlzY29lICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjUsIDIwMDcgICAgICAgICAg ICAgICAgW1BhZ2UgNjFdIAoMCkludGVybmV0LURyYWZ0ICAgICAgICBEZXBsb3ltZW50IE1vZGVs IHVzaW5nIFBDTiAgICAgICAgICBPY3RvYmVyIDIwMDYgCiAgICAKCiAgIEt3b2sgSG8gQ2hhbiAg CiAgIE5vcnRlbCBOZXR3b3JrcyAgCiAgIDYwMCBUZWNobm9sb2d5IFBhcmsgRHJpdmUgIAogICBC aWxsZXJpY2EsIE1BICAwMTgyMSAgCiAgIFVTQSAgCiAgIEVtYWlsOiBraGNoYW5Abm9ydGVsLmNv bSAgCiAgICAgICAgCgogICBKb3plZiBaLiBCYWJpYXJ6ICAKICAgTm9ydGVsIE5ldHdvcmtzICAK ICAgMzUwMCBDYXJsaW5nIEF2ZW51ZSAgCiAgIE90dGF3YSwgT250ICBLMkggOEU5ICAKICAgQ2Fu YWRhICAKICAgRW1haWw6IGJhYmlhcnpAbm9ydGVsLmNvbSAKICAgIAogICBTdGVwaGVuIER1ZGxl eSAKICAgTm9ydGVsIE5ldHdvcmtzIAogICA0MDAxIEUuIENoYXBlbCBIaWxsIE5lbHNvbiBIaWdo d2F5IAogICBQLk8uIEJveCAxMzAxMCwgbXMgNTcwLTAxLTBWOCAKICAgUmVzZWFyY2ggVHJpYW5n bGUgUGFyaywgTkMgMjc3MDkgCiAgIFVTQSAKICAgRW1haWw6IHNtZHVkbGV5QG5vcnRlbC5jb20g CiAgICAKICAgR2Vvcmdpb3MgS2FyYWdpYW5uaXMgCiAgIFVuaXZlcnNpdHkgb2YgVHdlbnRlIAog ICBQLk8uIEJPWCAyMTcgCiAgIDc1MDAgQUUgRW5zY2hlZGUsICAKICAgVGhlIE5ldGhlcmxhbmRz IAogICBFTWFpbDogZy5rYXJhZ2lhbm5pc0Bld2kudXR3ZW50ZS5ubCAgCiAgICAgICAgICAgICAg ICAgICAgIAogICBBdHRpbGEgQuFkZXIgIAogICBhdHRpbGEuYmFkZXJAZXJpY3Nzb24uY29tIAog ICAgCiAgIExhcnMgV2VzdGJlcmcgCiAgIEVyaWNzc29uIEFCIAogICBTRS0xNjQgODAgU3RvY2to b2xtIAogICBTd2VkZW4gCiAgIEVNYWlsOiBMYXJzLldlc3RiZXJnQGVyaWNzc29uLmNvbSAKICAg IAogICAgCiAgICAKICAgIAogICAgCgoKCgogCiAKQnJpc2NvZSAgICAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDI1LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDYyXSAKDApJbnRlcm5ldC1E cmFmdCAgICAgICAgRGVwbG95bWVudCBNb2RlbCB1c2luZyBQQ04gICAgICAgICAgT2N0b2JlciAy MDA2IAogICAgCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IAoKICAgVGhlIElFVEYg dGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkg CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWln aHQgYmUgY2xhaW1lZCB0byAKICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNl IG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiAKICAgdGhpcyBkb2N1bWVudCBvciB0aGUg ZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzIAogICBtaWdodCBv ciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBo YXMgCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCBy aWdodHMuICBJbmZvcm1hdGlvbiAKICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRv IHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZSAKICAgZm91bmQgaW4gQkNQIDc4IGFuZCBC Q1AgNzkuIAoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNl Y3JldGFyaWF0IGFuZCBhbnkgCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBh dmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4g YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiAKICAgc3VjaCBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgCiAgIHNw ZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVw b3NpdG9yeSBhdCAKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIAoKICAgVGhlIElFVEYgaW52 aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSAK ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeSAKICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkg YmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50IAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0IAogICBpZXRmLWlwckBpZXRmLm9yZyAK CkRpc2NsYWltZXIgb2YgVmFsaWRpdHkgCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4gCiAgICJBUyBJUyIgYmFz aXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5U UyAKICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBB TkQgVEhFIElOVEVSTkVUIAogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBX QVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIAogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1J VEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIAogICBJTkZPUk1BVElPTiBI RVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCAKICAgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UuIAoKQ29weXJpZ2h0IFN0YXRlbWVudCAKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDYpLiAKCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUg cmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIAogICBjb250YWluZWQgaW4gQkNQIDc4 LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyAKICAgcmV0YWlu IGFsbCB0aGVpciByaWdodHMuIAoKIAoKCgoKIAogCkJyaXNjb2UgICAgICAgICAgICAgICAgRXhw aXJlcyBBcHJpbCAyNSwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA2M10gCgwK ------_=_NextPart_001_01C6F67B.B18DAA23 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C6F67B.B18DAA23-- From pcn-bounces@ietf.org Mon Oct 23 23:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCzS-0005kz-P2; Mon, 23 Oct 2006 23:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCzR-0005ku-9k for pcn@ietf.org; Mon, 23 Oct 2006 23:30:09 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcCzO-0003yM-TL for pcn@ietf.org; Mon, 23 Oct 2006 23:30:09 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k9O3NKo07482 for ; Mon, 23 Oct 2006 23:23:20 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.102.178.253] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 23:30:03 -0400 Message-Id: <6.2.5.6.0.20061023232416.033d4a30@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Oct 2006 23:29:58 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" In-Reply-To: <6.2.5.6.0.20061023025818.03b6a708@nortel.com> References: <6.2.5.6.0.20061023025818.03b6a708@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Oct 2006 03:30:03.0683 (UTC) FILETIME=[B190A730:01C6F71C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi: Please notice I have submitted an update to the Problem-Statement draft. Please see the link to the draft at: http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.txt There were couple of minor cleanups. I have also added a new section just to set up the discussion of trust, with the trust assumptions and security still in the assumptions and security sections (as they were in -00). Thanks! -- Kwok -- At 03:04 AM 10/23/2006, you wrote: >This is the submission of an update (version 01) to an individual draft. > >Title: Pre-Congestion Notification Problem Statement > >Filename: draft-chan-pcn-problem-statement-01.txt > >Abstract: > DiffServ mechanisms have been developed to support Quality of Service > (QoS). However, the level of assurance that can be provided with > DiffServ without substantial over-provisioning is limited. Pre- > Congestion Notification (PCN) investigates the use of per-flow > admission control to provide the required service guarantees for the > admitted traffic. While admission control will protect the QoS under > normal operating conditions, an additional flow pre-emption mechanism > is necessary in the times of heavy congestion (e.g. caused by route > changes due to link or node failure). > > This document provides a problem statement on the addition of flow > admission control and flow pre-emption functionality to a DiffServ > network, in particular for the support of real time services such as > voice and video. > > >If there is any question or problem related to this submission, >please contact: >Kwok Ho Chan >E-Mail: khchan@nortel.com >Phone: 978-288-8175 > >The text version of the draft is attached. > >Thank You! >-- Kwok -- > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 24 15:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRnu-0002eE-KI; Tue, 24 Oct 2006 15:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRnt-0002e4-6t for pcn@ietf.org; Tue, 24 Oct 2006 15:19:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRnp-0006mP-Pm for pcn@ietf.org; Tue, 24 Oct 2006 15:19:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 15:19:10 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OJJ9GB024706 for ; Tue, 24 Oct 2006 15:19:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9OJJ3DY000118 for ; Tue, 24 Oct 2006 15:19:09 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 15:19:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Oct 2006 15:19:05 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: updated PCN draft charter and drafts Thread-Index: Acb3oUXNCZxlvUB8QZ24hz4U+FTwrQ== From: "Anna Charny \(acharny\)" To: X-OriginalArrivalTime: 24 Oct 2006 19:19:06.0919 (UTC) FILETIME=[4660EB70:01C6F7A1] DKIM-Signature: a=rsa-sha1; q=dns; l=6221; t=1161717549; x=1162581549; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:updated=20PCN=20draft=20charter=20and=20drafts |To:; X=v=3Dcisco.com=3B=20h=3DLzEj4Y1fn9/ZKUTM1LxsBEtJmIE=3D; b=nMrvSkjoK3FRBr9ppS26noHV1J9iuV1cY71myb86oY74ddpKIIptyT7t2bjOwWFIYORGUFAj y3OnFxUuKOW4hTGzDZNbTb/xlswKj+cwFC8WyfKEojTgp5C3aD9xdglx; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [PCN] updated PCN draft charter and drafts X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear all, Below is an updated proposed charter for the discussion at the PCN BOF in San Diego. Also, a quick update on PCN-related draft activities: the following drafts related to PCN work have recently been updated and/or posted for the first time: draft-chan-pcn-problem-statement-01.txt (this is PCN Problem Statement) draft-briscoe-tsvwg-cl-architecture-04.txt (this is PCN architecture) draft-briscoe-cl-phb-03 (this is PCN marking) draft-babiarz-pcn-sip-cap-00 (this is Sip-controlled Admission and Preepmtion) draft-zhang-pcn-performance-evaluation-00.txt (this is PCN simulation draft) draft-charny-pcn-single-marking-00.txt (this is about using single marking for PCN admission and pre-emption) Comments on all of these are welcome! Regards, Anna --------------------- PCN Draft Charter (Pre-Congestion Notification) The PCN WG will tackle the problem of how to provide scalable, resilient admission control and strong QoS assurance while using packet marking techniques.=20 Current attempts to deliver QoS using only packet marking (e.g. DiffServ) are limited in the level of QoS assurance that can be provided without substantial over-provisioning. To improve the QoS assurance, PCN will add flow admission control and flow pre-emption. In normal circumstances admission control should protect the QoS of previously admitted flows. In times of heavy congestion (for example caused by route changes due to link or router failure) pre-emption of some flows should preserve the QoS of remaining flows. While the WG will address both admission and pre-emption, it is assumed that these mechanisms can be used independently of each other, and the use of one does not mandate the use of the other. =20 The initial scope of the WG is the use of PCN within a single DiffServ region. The overall approach will be based on a separation of functionality between the interior routers and edge nodes of the DiffServ region. Interior routers mark packet headers when their traffic is above a certain level, as an early warning of incipient congestion ("pre-congestion"); this builds on concepts from RFC 3168 "The Addition of Explicit Congestion Notification to IP". Edge nodes of the DiffServ Region monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the edge nodes or by a centralized system (which is informed of the edge nodes measurements).=20 The WG will address the following specific problems and develop standards track solutions to them: 1. When should an interior router mark a packet (i.e. at what traffic level) in order to give early warning of its own congestion? 2. How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? 3. How should these markings (at packet granularity) be converted into=20 admission control and flow pre-emption decisions (at flow granularity)? To support this, the WG will work on the following Informational documents: 1. a Problem Statement, to describe the problems the group is tackling=20 and the assumptions made 2. at least two deployment models, initially to help focus the problem statement and later to check that the solutions being developed satisfy the deployment scenario. Possible deployment models may be:=20 (a) IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled and its edge nodes decide about admission and flow pre-emption (b) SIP Controlled Admission and Preemption: routers within the DiffServ region are PCN-capable and trusted SIP endpoints (gateway or host) perform admission and flow pre-emption =20 (c) Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with the PWE3 WG) 3. a generic analysis of the signaling extensions required to support PCN. Note that extensions/enhancements to specific signaling protocols=20 (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. 4. at least one example solution implementing the framework and its performance evaluation (e.g. simulation results), to provide evidence of the viability of the proposed standard in the proposed deployment models 5. an analysis of the tradeoffs of different encoding possibilities (e.g. ECN and DCSP marking) The initial scope of the WG will restrict the problem space in the following ways: 1. By assuming the PCN-enabled Internet Region is a controlled environment, i.e. all the interior routers and edge nodes of the region run PCN and trust each other 2. By assuming there are many flows on any bottleneck link in the PCN-enabled region=20 3. By focusing on the QoS assurance required by real time applications generating inelastic traffic like voice and video requiring low delay, jitter and packet loss, i.e. as defined by the Controlled Load Service [RFC2211].=20 4. By keeping specific handling of emergency and other precedence (911, GETS, WPS, MLPP etc.) calls out of scope of the WG while (a) ensuring that the edge nodes are not precluded from taking appropriate actions that may be necessary for handling such calls and (b) assuming that PCN Internal Nodes may not be precedence-aware but are DSCP aware.=20 Subsequent re-chartering may investigate solutions for when some of these=20 restrictions are not in place.=20 Topics out of scope for the WG include a general investigation of admission control mechanisms. =20 The WG will draw on the substantial prior academic and IETF work on=20 measurement-based admission control.=20 Milestones Nov 2006 initial Problem statement Nov 2006 initial deployment models March 2007 initial router marking behavior (including encoding) March 2007 initial flow admission control and pre-emption mechanism (including edge node measurements) March/July 2007 submit Problem statement March/July 2007 submit deployment models Nov 2007 submit router marking behavior Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism Nov 2007 initial signaling analysis Mar 2008 re-charter or close _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 25 05:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcejC-00021s-FH; Wed, 25 Oct 2006 05:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcejB-00021k-2q for pcn@ietf.org; Wed, 25 Oct 2006 05:07:13 -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 1Gcej3-0005LX-3A for pcn@ietf.org; Wed, 25 Oct 2006 05:07:13 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 147A7417D; Wed, 25 Oct 2006 11:07:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0A65E4434; Wed, 25 Oct 2006 11:07:00 +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 6FE95417D; Wed, 25 Oct 2006 11:06:59 +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 k9P96ws19877; Wed, 25 Oct 2006 11:06:58 +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 053D16F58E; Wed, 25 Oct 2006 11:05:18 +0200 (CEST) Message-ID: <453F28B5.2090109@informatik.uni-wuerzburg.de> Date: Wed, 25 Oct 2006 11:04:53 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kwok-Ho Chan Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission References: <6.2.5.6.0.20061023025818.03b6a708@nortel.com> <6.2.5.6.0.20061023232416.033d4a30@nortel.com> In-Reply-To: <6.2.5.6.0.20061023232416.033d4a30@nortel.com> Content-Type: multipart/mixed; boundary="------------020902000404080405070302" X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e9ab5f45a4d3b23749a2b40ff114cf2d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --------------020902000404080405070302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I browsed through the drafts and have some comments on Section 5 "Aggregate Traffic Characteristics" which says: "However, too little [traffic] variation can also be a problem [for the PCN marking]. For example, if all the sources are constant bit rate and are synchronised, then the total traffic level at a router's interface could be (almost) at its capacity and all packets could still be serviced instantly. However, admitting one more flow could tip the router over its capacity, so its queue grew indefinitely until it had to drop packets. "Some" traffic variation means that as the traffic level nears the capacity limit, some packets are PCN-marked but there's still enough capacity to cope with the traffic fluctuations. Hence new flows can be blocked and packets are never dropped." With PCN, all packets are "stop admission marked" if the currently observed rate exceeds the configured "admissible interface rate". The configured "admissible interface rate" is usually substantially smaller than the physical link bandwidth. In the context of RED marking, only those packets are marked that exceed a certain threshold of the physical queue which is served at link rate. If the traffic exceeds the link rate preliminarily on a small time scale, a queue builds up and some of the queued packets are marked. This can also happen if the aggregate rate is low, but if bursts arrive. In contrast, if the rate of the aggregate reaches almost the link bandwidth, but if it is sufficiently smooth, no queue builds up. Thus, the problem with RED-like marking is that it can give EARLY warning only if the current traffic rate is below the link rate but exceeds it due to short term variations. From my perspective, PCN marking does not have this problem because it reacts if the sent rate exceeds the configured rate and that can be well observed on a larger time scale than packet level, short term variations are not required to this end. Therefore, PCN marking leads to more stable results than RED marking and it does not need to give a warning if the configured "admissible interface rate" is not achieved on a medium time scale (~1s). Therefore, early warning can be perfectly done also for extremely smooth CBR traffic. Best wishes, Michael Kwok-Ho Chan wrote: > Hi: > Please notice I have submitted an update to the Problem-Statement draft. > Please see the link to the draft at: > http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.txt > > There were couple of minor cleanups. > I have also added a new section just to set up the discussion of trust, > with the trust assumptions and security still in the assumptions and > security sections (as they were in -00). > Thanks! > -- Kwok -- > > > At 03:04 AM 10/23/2006, you wrote: >> This is the submission of an update (version 01) to an individual draft. >> >> Title: Pre-Congestion Notification Problem Statement >> >> Filename: draft-chan-pcn-problem-statement-01.txt >> >> Abstract: >> DiffServ mechanisms have been developed to support Quality of Service >> (QoS). However, the level of assurance that can be provided with >> DiffServ without substantial over-provisioning is limited. Pre- >> Congestion Notification (PCN) investigates the use of per-flow >> admission control to provide the required service guarantees for the >> admitted traffic. While admission control will protect the QoS under >> normal operating conditions, an additional flow pre-emption mechanism >> is necessary in the times of heavy congestion (e.g. caused by route >> changes due to link or node failure). >> >> This document provides a problem statement on the addition of flow >> admission control and flow pre-emption functionality to a DiffServ >> network, in particular for the support of real time services such as >> voice and video. >> >> >> If there is any question or problem related to this submission, >> please contact: >> Kwok Ho Chan >> E-Mail: khchan@nortel.com >> Phone: 978-288-8175 >> >> The text version of the draft is attached. >> >> Thank You! >> -- Kwok -- >> >> >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn -- 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 --------------020902000404080405070302 Content-Type: text/plain; name="draft-briscoe-tsvwg-cl-architecture-04.txt" Content-Disposition: inline; filename="draft-briscoe-tsvwg-cl-architecture-04.txt" Content-Transfer-Encoding: quoted-printable TSVWG B. Briscoe=20 Internet Draft P. Eardley =20 draft-briscoe-tsvwg-cl-architecture-04.txt D. Songhurst =20 Expires: April 2007 BT=20 =20 F. Le Faucheur=20 A. Charny=20 Cisco Systems, Inc=20 =20 J. Babiarz=20 K. Chan=20 S. Dudley=20 Nortel=20 =20 G. Karagiannis=20 University of Twente / Ericsson=20 =20 A. Bader=20 L. Westberg=20 Ericsson=20 =20 25 October, 2006=20 =20 =20 An edge-to-edge Deployment Model for Pre-Congestion Notification: =20 Admission Control over a DiffServ Region=20 draft-briscoe-tsvwg-cl-architecture-04.txt=20 Status of this Memo=20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been or will be disclosed, and any of which he or she becomes=20 aware will be disclosed, in accordance with Section 6 of BCP 79.=20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress".=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 1]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html=20 This Internet-Draft will expire on September 6, 2006.=20 Copyright Notice=20 Copyright (C) The Internet Society (2006). All Rights Reserved.=20 Abstract =20 This document describes a deployment model for pre-congestion=20 notification (PCN) operating in a large DiffServ-based region of the=20 Internet. PCN-based admission control protects the quality of service=20 of existing flows in normal circumstances, whilst if necessary (eg=20 after a large failure) pre-emption of some flows preserves the quality=20 of service of the remaining flows. Each link has a configured- admission-rate and a configured-pre-emption-rate, and a router marks=20 packets that exceed these rates. Hence routers give an early warning of=20 their own potential congestion, before packets need to be dropped.=20 Gateways around the edges of the PCN-region convert measurements of=20 packet rates and their markings into decisions about whether to admit=20 new flows, and (if necessary) into the rate of excess traffic that=20 should be pre-empted. Per-flow admission states are kept at the=20 gateways only, while the PCN markers that are required for all routers=20 operate on the aggregate traffic - hence there is no scalability impact=20 on interior routers. =20 Authors' Note (TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION)=20 This document is posted as an Internet-Draft with the intention of=20 eventually becoming an INFORMATIONAL RFC.=20 =20 =20 =20 =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 2]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Table of Contents=20 =20 1. Introduction................................................5=20 1.1. Summary................................................5=20 1.2. Key benefits...........................................8=20 1.3. Terminology............................................9=20 1.4. Existing terminology...................................11=20 1.5. Standardisation requirements...........................11=20 1.6. Structure of rest of the document......................12=20 2. Key aspects of the deployment model.........................13=20 2.1. Key goals.............................................13=20 2.2. Key assumptions........................................14=20 3. Deployment model...........................................17=20 3.1. Admission control......................................17=20 3.1.1. Pre-Congestion Notification for Admission Marking..17=20 3.1.2. Measurements to support admission control..........17=20 3.1.3. How edge-to-edge admission control supports end-to-end=20 QoS signalling..........................................18=20 3.1.4. Use case.........................................18=20 3.2. Flow pre-emption.......................................20=20 3.2.1. Alerting an ingress gateway that flow pre-emption may be=20 needed..................................................20=20 3.2.2. Determining the right amount of CL traffic to drop.23=20 3.2.3. Use case for flow pre-emption.....................24=20 3.3. Both admission control and pre-emption.................25=20 4. Summary of Functionality....................................27=20 4.1. Ingress gateways.......................................27=20 4.2. Interior routers.......................................28=20 4.3. Egress gateways........................................28=20 4.4. Failures..............................................29=20 5. Limitations and some potential solutions....................31=20 5.1. ECMP..................................................31=20 5.2. Beat down effect.......................................33=20 5.3. Bi-directional sessions................................35=20 5.4. Global fairness........................................37=20 5.5. Flash crowds..........................................39=20 5.6. Pre-empting too fast...................................41=20 5.7. Other potential extensions.............................42=20 5.7.1. Tunnelling........................................42=20 5.7.2. Multi-domain and multi-operator usage.............43=20 5.7.3. Preferential dropping of pre-emption marked packets44=20 5.7.4. Adaptive bandwidth for the Controlled Load service.44=20 5.7.5. Controlled Load service with end-to-end Pre-Congestion=20 Notification............................................45=20 5.7.6. MPLS-TE..........................................45=20 6. Relationship to other QoS mechanisms........................46=20 =20 =20 Briscoe Expires April 25, 2007 [Page 3]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 6.1. IntServ Controlled Load................................46=20 6.2. Integrated services operation over DiffServ............46=20 6.3. Differentiated Services................................46=20 6.4. ECN...................................................47=20 6.5. RTECN.................................................47=20 6.6. RMD...................................................48=20 6.7. RSVP Aggregation over MPLS-TE..........................48=20 6.8. Other Network Admission Control Approaches.............48=20 7. Security Considerations.....................................49=20 8. Acknowledgements...........................................49=20 9. Comments solicited.........................................50=20 10. Changes from earlier versions of the draft.................50=20 11. Appendices................................................52=20 11.1. Appendix A: Explicit Congestion Notification..........52=20 11.2. Appendix B: What is distributed measurement-based admission=20 control?...................................................53=20 11.3. Appendix C: Calculating the Exponentially weighted moving=20 average (EWMA).............................................54=20 12. References................................................56=20 Authors' Addresses............................................61=20 Intellectual Property Statement................................63=20 Disclaimer of Validity........................................63=20 Copyright Statement...........................................63=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 4]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 1. Introduction=20 1.1. Summary =20 This document describes a deployment model to achieve an end-to-end=20 Controlled Load service by using (within a large region of the=20 Internet) DiffServ and edge-to-edge distributed measurement-based=20 admission control and flow pre-emption. Controlled load service is a=20 quality of service (QoS) closely approximating the QoS that the same=20 flow would receive from a lightly loaded network element [RFC2211].=20 Controlled Load (CL) is useful for inelastic flows such as those for=20 real-time media.=20 In line with the "IntServ over DiffServ" framework defined in=20 [RFC2998], the CL service is supported end-to-end and RSVP signalling=20 [RFC2205] is used end-to-end, over an edge-to-edge DiffServ region.=20 We call the DiffServ region the "CL-region".=20 ___ ___ _______________________________________ ____ ___=20 | | | | |Ingress Interior Egress| | | | |=20 | | | | |gateway routers gateway| | | | |=20 | | | | |-------+ +-------+ +-------+ +------| | | | |=20 | | | | | PCN- | | PCN- | | PCN- | | | | | | |=20 | |..| |..|marking|..|marking|..|marking|..| Meter|..| |..| |=20 | | | | |-------+ +-------+ +-------+ +------| | | | |=20 | | | | | \ / | | | | |=20 | | | | | \ / | | | | |=20 | | | | | \ Congestion-Level-Estimate / | | | | |=20 | | | | | \ (for admission control) / | | | | |=20 | | | | | --<-----<----<----<-----<-- | | | | |=20 | | | | | Sustainable-Aggregate-Rate | | | | |=20 | | | | | (for flow pre-emption) | | | | |=20 |___| |___| |_______________________________________| |____| |___|=20 =20 Sx Access CL-region Access Rx=20 End Network Network End=20 Host Host=20 <------ edge-to-edge signalling ----->=20 (for admission control & flow pre-emption)=20 =20 <-------------------end-to-end QoS signalling protocol--------------->=20 =20 Figure 1: Overall QoS architecture (NB terminology explained later)=20 =20 =20 Briscoe Expires April 25, 2007 [Page 5]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 Figure 1 shows an example of an overall QoS architecture, where the=20 two access networks are connected by a CL-region. Another possibility=20 is that there are several CL-regions between the access networks -=20 each would operate the Pre-Congestion Notification mechanisms=20 separately. The document assumes RSVP as the end-to-end QoS=20 signalling protocol. However, the RSVP signalling may itself be=20 originated or terminated by proxies still closer to the edge of the=20 network, such as home hubs or the like, triggered in turn by=20 application layer signalling. [RFC2998] and our approach are compared=20 further in Section 6.2.=20 Flows must enter and leave the CL-region through its ingress and=20 egress gateways, and they need traffic descriptors that are policed=20 by the ingress gateway (NB the policing function is out of this=20 document's scope). The overall CL-traffic between two border routers=20 is called a "CL-region-aggregate".=20 The document introduces a mechanism for flow admission control:=20 should a new flow be admitted into a specific CL-region-aggregate?=20 Admission control protects the QoS of existing CL-flows in normal=20 circumstances. In abnormal circumstances, for instance a disaster=20 affecting multiple interior routers, then the QoS on existing CL=20 microflows may degrade even if care was exercised when admitting=20 those microflows before those circumstances. Therefore we also=20 propose a mechanism for flow pre-emption: how much traffic, in a=20 specific CL-region-aggregate, should be pre-empted in order to=20 preserve the QoS of the remaining CL-flows? Flow pre-emption also=20 restores QoS to lower priority traffic. =20 As a fundamental building block to enable these two mechanisms, each=20 link of the CL-region is associated with a configured-admission-rate=20 and configured-pre-emption-rate; the former is usually significantly=20 larger than the latter. If traffic in a specific DiffServ class ("CL- traffic") on the link exceeds these rates then packets are marked=20 with "Admission Marking" or "Pre-emption Marking". The algorithms=20 that determine the number of packets marked are outlined in Section 3=20 and detailed in [PCN]. PCN marking (Pre-Congestion Notification)=20 builds on the concepts of RFC 3168, "The addition of Explicit=20 Congestion Notification to IP" (which is briefly summarised in=20 Appendix A).=20 =20 =20 Briscoe Expires April 25, 2007 [Page 6]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 =20 Traffic rate on link ^=20 | =20 | Drop packets=20 link bandwidth -|--------------------------- =20 | =20 | Pre-emption Mark packets=20 configured-pre-emption-rate -|---------------------------=20 | =20 | Admission Mark packets=20 configured-admission-rate -|---------------------------=20 |=20 | No marking of packets=20 |=20 +---------------------------=20 =20 Figure 2: Packet Marking by Routers=20 =20 Gateways of the CL-region make measurements of packet rates and their=20 PCN markings and convert them into decisions about whether to admit=20 new flows, and (if necessary) into the rate of excess traffic that=20 should be pre-empted. These mechanisms are detailed in Section 3 and=20 briefly outlined in the next few paragraphs. =20 The admission control mechanism for a new flow entering the network=20 at ingress gateway G0 and leaving it at egress gateway G1 relies on=20 feedback from the egress gateway G1 about the existing CL-region- aggregate between G0 and G1. This feedback is generated as follows.=20 All routers meter the rate of the CL-traffic on their outgoing links=20 and mark the packets with the Admission Mark if the configured- admission-rate is exceeded. Egress gateway G1 measures the Admission=20 Marks for each of its CL-region-aggregates separately. If the=20 fraction of traffic on a CL-region-aggregate that is Admission Marked=20 exceeds some threshold, no further flows should be admitted into this=20 CL-region-aggregate. Because sources vary their data rates (amongst=20 other reasons) the rate of the CL-traffic on a link may fluctuate=20 above and below the configured-admission-rate. Hence to get more=20 stable information, the egress gateway measures the fraction as a=20 moving average, called the Congestion-Level-Estimate. This is=20 signalled from the egress G1 to the ingress G0, to enable the ingress=20 to block new flows. =20 Admission control seems most useful for DiffServ's Controlled load=20 service. In order to support CL traffic we would expect PCN to=20 supplement the existing scheduling behaviour Expedited Forwarding=20 =20 =20 Briscoe Expires April 25, 2007 [Page 7]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 (EF). Since PCN gives an "early warning" of potential congestion=20 (hence "pre-congestion notification"), admission control can kick in=20 before there is any significant build up of packets in routers -=20 which is exactly the performance required for CL. However, PCN is not=20 only intended to supplement EF. PCN is specified (in [PCN]) as a=20 building block which can supplement the scheduling behaviour of other=20 PHBs.=20 The function to pre-empt flows (or allow the potential to pre-empt=20 them) relies on feedback from the egress gateway about the CL-region- aggregates. This feedback is generated as follows. All routers meter=20 the rate of the CL-traffic on their outgoing links, and if the rate=20 is in excess of the configured-pre-emption-rate then packets=20 amounting to the excess rate are Pre-emption Marked. If the egress=20 gateway G1 sees a Pre-emption Marked packet then it measures, for=20 this CL-region-aggregate, the rate of all received packets that=20 aren't Pre-emption Marked. This is the rate of CL-traffic that the=20 network can actually support from G0 to G1, and we thus call it the=20 Sustainable-Aggregate-Rate. The ingress gateway G0 compares the=20 Sustainable-Aggregate-Rate with the rate that it is sending towards=20 G1, and hence determines the required traffic rate reduction. The=20 document assumes flow pre-emption as the way of reacting to this=20 information, ie stopping sufficient flows to reduce the rate to the=20 Sustainable-Aggregate-Rate. However, this isn't mandated, for=20 instance policy or regulation may prevent pre-emption of some flows -=20 such considerations are out of scope of this document.=20 1.2. Key benefits=20 We believe that the mechanisms described in this document are simple,=20 scalable, and robust because:=20 o Per flow state is only required at the ingress gateways to prevent=20 non-admitted CL traffic from entering the PCN-region. Other=20 network entities are not aware of individual flows.=20 o For each of its links a router has Admission Marking and Pre- emption Marking behaviours. These markers operate on the overall=20 CL traffic of the respective link. Therefore, there are no=20 scalability concerns.=20 o The information of these measurements is implicitly signalled to=20 the egress gateways by the marks in the packet headers. No=20 protocol actions (explicit messages) are required.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 8]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o The egress gateways make separate measurements for each ingress=20 gateway of packets. Each meter operates on the overall CL traffic=20 of a particular CL-region-aggregate. Therefore, there are no=20 scalability concerns as long as the number of ingress gateways is=20 not overwhelmingly large.=20 o Feedback signalling is required between all pairs of ingress and=20 egress gateways and the signalled information is on the basis of=20 the corresponding CL-region-aggregate, i.e. it is also unaware of=20 individual flows.=20 o The configured-admission-rates can be chosen small enough that=20 admitted traffic can still be carried after a rerouting in most=20 failure cases. This is an important feature as QoS violations in=20 core networks due to link failures are more likely than QoS=20 violations due to increased traffic volume.=20 o The admitted load is controlled dynamically. Therefore it adapts=20 as the traffic matrix changes, and also if the network topology=20 changes (eg after a link failure). Hence an operator can be less=20 conservative when deploying network capacity, and less accurate in=20 their prediction of the traffic matrix. Also, controlling the load=20 using statically provisioned capacity per ingress (regardless of=20 the egress of a flow), as is typical in the DiffServ architecture=20 [RFC2475], can lead to focussed overload: many flows happen to=20 focus on a particular link and then all flows through the=20 congested link fail catastrophically (Section 6.2).=20 o The pre-emption function complements admission control. It allows=20 the network to recover from sudden unexpected surges of CL-traffic=20 on some links, thus restoring QoS to the remaining flows. Such=20 scenarios are very unlikely but not impossible. They can be caused=20 by large network failures that redirect lots of admitted CL- traffic to other links, or by malfunction of the measurement-based=20 admission control in the presence of admitted flows that send for=20 a while with an atypically low rate and increase their rates in a=20 correlated way.=20 =20 =20 1.3. Terminology=20 EDITOR'S NOTE: Terminology in this document is (hopefully) consistent=20 with that in [PCN]. However, it may not be consistent with the=20 =20 =20 Briscoe Expires April 25, 2007 [Page 9]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 terminology in other PCN-related documents. The PCN Working Group (if=20 formed) will need to agree a single set of terminology. =20 This terminology is copied from the pre-congestion notification=20 marking draft [PCN]:=20 o Pre-Congestion Notification (PCN): two new algorithms that=20 determine when a PCN-enabled router Admission Marks and Pre- emption Marks a packet, depending on the traffic level. =20 o Admission Marking condition: the traffic level is such that the=20 router Admission Marks packets. The router provides an "early=20 warning" that the load is nearing the engineered admission control=20 capacity, before there is any significant build-up of CL packets=20 in the queue.=20 o Pre-emption Marking condition: the traffic level is such that the=20 router Pre-emption Marks packets. The router warns explicitly that=20 pre-emption may be needed.=20 o Configured-admission-rate: the reference rate used by the=20 admission marking algorithm in a PCN-enabled router. =20 o Configured-pre-emption-rate - the reference rate used by the pre- emption marking algorithm in a PCN-enabled router.=20 =20 The following terms are defined here:=20 o Ingress gateway: router at an ingress to the CL-region. A CL- region may have several ingress gateways. =20 o Egress gateway: router at an egress from the CL-region. A CL- region may have several egress gateways.=20 o Interior router: a router which is part of the CL-region, but=20 isn't an ingress or egress gateway.=20 o CL-region: A region of the Internet in which all traffic=20 enters/leaves through an ingress/egress gateway and all routers=20 run Pre-Congestion Notification marking. A CL-region is a DiffServ=20 region (a DiffServ region is either a single DiffServ domain or=20 set of contiguous DiffServ domains), but note that the CL-region=20 does not use the traffic conditioning agreements (TCAs) of the=20 (informational) DiffServ architecture.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 10]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o CL-region-aggregate: all the microflows between a specific pair of=20 ingress and egress gateways. Note there is no field in the flow=20 packet headers that uniquely identifies the aggregate.=20 o Congestion-Level-Estimate: the number of bits in CL packets that=20 are admission marked (or pre-emption marked), divided by the=20 number of bits in all CL packets. It is calculated as an=20 exponentially weighted moving average. It is calculated by an=20 egress gateway for the CL packets from a particular ingress=20 gateway, i.e. there is a Congestion-Level-Estimate for each CL- region-aggregate. =20 o Sustainable-Aggregate-Rate: the rate of traffic that the network=20 can actually support for a specific CL-region-aggregate. So it is=20 measured by an egress gateway for the CL packets from a particular=20 ingress gateway.=20 o Ingress-Aggregate-Rate: the rate of traffic that is being sent on=20 a specific CL-region-aggregate. So it is measured by an ingress=20 gateway for the CL packets sent towards a particular egress=20 gateway.=20 =20 =20 1.4. Existing terminology=20 This is a placeholder for useful terminology that is defined=20 elsewhere.=20 1.5. Standardisation requirements=20 The framework described in this document has two new standardisation=20 requirements: =20 o new Pre-Congestion Notification for Admission Marking and Pre- emption Marking are required, as detailed in [PCN]. =20 o the end-to-end signalling protocol needs to be modified to carry=20 the Congestion-Level-Estimate report (for admission control) and=20 the Sustainable-Aggregate-Rate (for flow pre-emption). With our=20 assumption of RSVP (Section 2.2) as the end-to-end signalling=20 protocol, it means that extensions to RSVP are required, as=20 detailed in [RSVP-PCN], for example to carry the Congestion-Level- Estimate and Sustainable-Aggregate-Rate information from egress=20 gateway to ingress gateway.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 11]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o We are discussing what to standardise about the gateway's=20 behaviour.=20 Other than these things, the arrangement uses existing IETF protocols=20 throughout, although not in their usual architecture.=20 1.6. Structure of rest of the document=20 Section 2 describes some key aspects of the deployment model: our=20 goals and assumptions. Section 3 describes the deployment model,=20 whilst Section 4 summarises the required changes to the various=20 routers in the CL-region. Section 5 outlines some limitations of PCN=20 that we've identified in this deployment model; it also discusses=20 some potential solutions, and other possible extensions. Section 6=20 provides some comparison with existing QoS mechanisms. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 12]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 2. Key aspects of the deployment model=20 EDITOR'S NOTE: The material in Section 2 will eventually disappear,=20 as it will be covered by the problem statement of the PCN Working=20 Group (if formed).=20 In this section we discuss the key aspects of the deployment model:=20 o At a high level, our key goals, i.e. the functionality that we=20 want to achieve=20 o The assumptions that we're prepared to make =20 2.1. Key goals=20 The deployment model achieves an end-to-end controlled load (CL)=20 service where a segment of the end-to-end path is an edge-to-edge=20 Pre-Congestion Notification region. CL is a quality of service (QoS)=20 closely approximating the QoS that the same flow would receive from a=20 lightly loaded network element [RFC2211]. It is useful for inelastic=20 flows such as those for real-time media. =20 o The CL service should be achieved despite varying load levels of=20 other sorts of traffic, which may or may not be rate adaptive=20 (i.e. responsive to packet drops or ECN marks).=20 o The CL service should be supported for a variety of possible CL=20 sources: Constant Bit Rate (CBR), Variable Bit Rate (VBR) and=20 voice with silence suppression. VBR is the most challenging to=20 support.=20 o After a localised failure in the interior of the CL-region causing=20 heavy congestion, the CL service should recover gracefully by pre- empting (dropping) some of the admitted CL microflows, whilst=20 preserving as many of them as possible with their full CL QoS. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 13]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o It needs to be possible to complete flow pre-emption within 1-2=20 seconds. Operators will have varying requirements but, at least=20 for voice, it has been estimated that after a few seconds then=20 many affected users will start to hang up, making the flow pre- emption mechanism redundant and possibly even counter-productive.=20 Until flow pre-emption kicks in, other applications using CL (e.g.=20 video) and lower priority traffic (e.g. Assured Forwarding (AF))=20 could be receiving reduced service. Therefore an even faster flow=20 pre-emption mechanism would be desirable (even if, in practice,=20 operators have to add a deliberate pause to ride out a transient=20 while the natural rate of call tear down or lower layer protection=20 mechanisms kick in).=20 o The CL service should support emergency services ([EMERG-RQTS],=20 [EMERG-TEL]) as well as the Assured Service which is the IP=20 implementation of the existing ITU-T/NATO/DoD telephone system=20 architecture known as Multi-Level Pre-emption and Precedence=20 [ITU.MLPP.1990] [ANSI.MLPP.Spec][ANSI.MLPP.Supplement], or MLPP.=20 In particular, this involves admitting new flows that are part of=20 high priority sessions even when admission control would reject=20 new routine flows. Similarly, when having to choose which flows to=20 pre-empt, this involves taking into account the priorities and=20 properties of the sessions that flows are part of.=20 =20 2.2. Key assumptions=20 The framework does not try to deliver the above functionality in all=20 scenarios. We make the following assumptions about the type of=20 scenario to be solved. =20 o Edge-to-edge: all the routers in the CL-region are upgraded with=20 Pre-Congestion Notification, and all the ingress and egress=20 gateways are upgraded to perform the measurement-based admission=20 control and flow pre-emption. Note that although the upgrades=20 required are edge-to-edge, the CL service is provided end-to-end.=20 o Additional load: we assume that any additional load offered within=20 the reaction time of the admission control mechanism doesn't move=20 the CL-region directly from no congestion to overload. So it=20 assumes there will always be an intermediate stage where some CL=20 packets are Admission Marked, but they are still delivered without=20 significant QoS degradation. We believe this is valid for core and=20 backbone networks with typical call arrival patterns (given the=20 reaction time is little more than one round trip time across the=20 CL-region), but is unlikely to be valid in access networks where=20 the granularity of an individual call becomes significant.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 14]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Aggregation: we assume that in normal operations, there are many=20 CL microflows within the CL-region, typically at least hundreds=20 between any pair of ingress and egress gateways. The implication=20 is that the solution is targeted at core and backbone networks and=20 possibly parts of large access networks. =20 o Trust: we assume that there is trust between all the routers in=20 the CL-region. For example, this trust model is satisfied if one=20 operator runs the whole of the CL-region. But we make no such=20 assumptions about the end hosts, i.e. depending on the scenario=20 they may be trusted or untrusted by the CL-region. =20 o Signalling: we assume that the end-to-end signalling protocol is=20 RSVP. Section 3 describes how the CL-region fits into such an end- to-end QoS scenario, whilst [RSVP-PCN] describes the extensions to=20 RSVP that are required. =20 o Separation: we assume that all routers within the CL-region are=20 upgraded with the CL mechanism, so the requirements of [Floyd] are=20 met because the CL-region is an enclosed environment. Also, an=20 operator separates CL-traffic in the CL-region from outside=20 traffic by administrative configuration of the ring of gateways=20 around the region. Within the CL-region we assume that the CL- traffic is separated from non-CL traffic. =20 o Routing: we assume that all packets between a pair of ingress and=20 egress gateways follow the same path, or that they follow=20 different paths but that the load balancing scheme is tuned in the=20 CL-region to distribute load such that the different paths always=20 receive comparable relative load. This ensures that the=20 Congestion-Level-Estimate used in the admission control procedure=20 (and which is computed taking into account packets travelling on=20 all the paths) approximately reflects the status of the actual=20 path that will be followed by the new microflow's packets. =20 =20 We are investigating ways of loosening the restrictions set by some=20 of these assumptions, for instance:=20 o Trust: to allow the CL-region to span multiple, non-trusting=20 operators, using the technique of [Re-PCN] as mentioned in Section=20 5.7.2.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 15]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Signalling: we believe that the solution could operate with=20 another signalling protocol, such as the one produced by the NSIS=20 working group. It could also work with application level=20 signalling as suggested in [RT-ECN].=20 o Additional load: we believe that the assumption is valid for core=20 and backbone networks, with an appropriate margin between the=20 configured-admission-rate and the capacity for CL traffic.=20 However, in principle a burst of admission requests can occur in a=20 short time. We expect this to be a rare event under normal=20 conditions, but it could happen e.g. due to a 'flash crowd'. If it=20 does, then more flows may be admitted than should be, triggering=20 the pre-emption mechanism. There are various ways an operator=20 might try to alleviate this issue, which are discussed in the=20 'Flash crowds' section 5.5 later. =20 o Separation: the assumption that CL traffic is separated from non- CL traffic implies that the CL traffic has its own PHB, not shared=20 with other traffic. We are looking at whether it could share=20 Expedited Forwarding's PHB, but supplemented with Pre-Congestion=20 Notification. If this is possible, other PHBs (like Assured=20 Forwarding) could be supplemented with the same new behaviours.=20 This is similar to how RFC3168 ECN was defined to supplement any=20 PHB.=20 o Routing: we are looking in greater detail at the solution in the=20 presence of Equal Cost Multi-Path routing and at suitable=20 enhancements. See also the 'ECMP' section 5.1 later. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 16]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 3. Deployment model=20 3.1. Admission control =20 In this section we describe the admission control mechanism. We=20 discuss the three pieces of the solution and then give an example of=20 how they fit together in a use case:=20 o the new Pre-Congestion Notification for Admission Marking used by=20 all routers in the CL-region=20 o how the measurements made support our admission control mechanism =20 o how the edge to edge mechanism fits into the end to end RSVP=20 signalling=20 =20 3.1.1. Pre-Congestion Notification for Admission Marking=20 This is discussed in [PCN]. Here we only give a brief outline. =20 To support our admission control mechanism, each router in the CL- region runs an algorithm to determine whether to Admission Mark the=20 packet. The algorithm measures the aggregate CL traffic on the link=20 and ensures that packets are admission marked before the actual queue=20 builds up, but when it is in danger of doing so soon; the probability=20 of admission marking increases with the danger. The algorithm's main=20 parameter is the configured-admission-rate, which is set lower than=20 the link speed, perhaps considerably so. Admission marked packets=20 indicate that the CL traffic rate is reaching the configured- admission-rate and so act as an "early warning" that the engineered=20 capacity is nearly reached. Therefore they indicate that requests to=20 admit prospective new CL flows may need to be refused.=20 =20 3.1.2. Measurements to support admission control=20 To support our admission control mechanism the egress measures the=20 Congestion-Level-Estimate for traffic from each remote ingress=20 gateway, i.e. per CL-region-aggregate. The Congestion-Level-Estimate=20 is the number of bits in CL packets that are admission marked or pre- emption marked, divided by the number of bits in all CL packets. It=20 is calculated as an exponentially weighted moving average. It is=20 calculated by an egress gateway separately for the CL packets from=20 each particular ingress gateway. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 17]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Why are pre-emption marked packets included in the Congestion-Level- Estimate? Pre-emption marking over-writes admission marking, i.e. a=20 packet cannot be both admission and pre-emption marked. So if pre- emption marked packets weren't counted we would have the anomaly that=20 as the traffic rate grew above the configured-pre-emption-rate, the=20 Congestion-Level-Estimate would fall. If a particular encoding scheme=20 is chosen where a packet can be both admission and pre-emption marked=20 (such as Alternative 4 in Appendix C of [PCN]), then this is not=20 necessary.=20 This Congestion-Level-Estimate provides an estimate of how near the=20 links on the path inside the CL-region are getting to the configured- admission-rate. Note that the metering is done separately per ingress=20 gateway, because there may be sufficient capacity on all the routers=20 on the path between one ingress gateway and a particular egress, but=20 not from a second ingress to that same egress gateway.=20 3.1.3. How edge-to-edge admission control supports end-to-end QoS=20 signalling=20 Consider a scenario that consists of two end hosts, each connected to=20 their own access networks, which are linked by the CL-region. A=20 source tries to set up a new CL microflow by sending an RSVP PATH=20 message, and the receiving end host replies with an RSVP RESV=20 message. Outside the CL-region some other method, for instance=20 IntServ, is used to provide QoS. From the perspective of RSVP the CL- region is a single hop, so the RSVP PATH and RESV messages are=20 processed by the ingress and egress gateways but are carried=20 transparently across all the interior routers; hence, the ingress and=20 egress gateways hold per microflow state, whilst no per microflow=20 state is kept by the interior routers. So far this is as in IntServ=20 over DiffServ [RFC2998]. However, in order to support our admission=20 control mechanism, the egress gateway adds to the RESV message an=20 opaque object which states the current Congestion-Level-Estimate for=20 the relevant CL-region-aggregate. Details of the corresponding RSVP=20 extensions are described in [RSVP-PCN].=20 3.1.4. Use case=20 To see how the three pieces of the solution fit together, we imagine=20 a scenario where some microflows are already in place between a given=20 pair of ingress and egress gateways, but the traffic load is such=20 that no packets from these flows are admission marked as they travel=20 across the CL-region. A source wanting to start a new CL microflow=20 sends an RSVP PATH message. The egress gateway adds an object to the=20 RESV message with the Congestion-Level-Estimate, which is zero. The=20 ingress gateway sees this and consequently admits the new flow. It=20 =20 =20 Briscoe Expires April 25, 2007 [Page 18]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 then forwards the RSVP RESV message upstream towards the source end=20 host. Hence, assuming there's sufficient capacity in the access=20 networks, the new microflow is admitted end-to-end. =20 The source now sends CL packets, which arrive at the ingress gateway.=20 The ingress uses a five-tuple filter to identify that the packets are=20 part of a previously admitted CL microflow, and it also polices the=20 microflow to ensure it remains within its traffic profile. (The=20 ingress has learnt the required information from the RSVP messages.)=20 When forwarding a packet belonging to an admitted microflow, the=20 ingress sets the packet's DSCP and ECN fields to the appropriate=20 values configured for the CL region. The CL packet now travels across=20 the CL-region, getting admission marked if necessary. =20 Next, we imagine the same scenario but at a later time when load is=20 higher at one (or more) of the interior routers, which start to=20 Admission Mark CL packets, because their load on the outgoing link is=20 nearing the configured-admission-rate. The next time a source tries=20 to set up a CL microflow, the ingress gateway learns (from the=20 egress) the relevant Congestion-Level-Estimate. If it is greater than=20 some CLE-threshold value then the ingress refuses the request,=20 otherwise it is accepted. The ingress gateway could also take into=20 account attributes of the RSVP reservation (such as for example the=20 RSVP pre-emption priority of [RSVP-PREEMPTION] or the RSVP admission=20 priority of [RSVP-EMERGENCY]) as well as information provided by a=20 policy decision point in order to make a more sophisticated admission=20 decision. This way, flow admission can help emergency/military calls=20 by taking into account the corresponding priorities (as conveyed in=20 RSVP policy elements) when deciding to admit or reject a new=20 reservation. Use of RSVP for the support of emergency/military=20 applications is discussed in further detail in [RFC4542] and [RSVP- EMERGENCY].=20 It is also possible for an egress gateway to get a RSVP RESV message=20 and not know what the Congestion-Level-Estimate is. For example, if=20 there are no CL microflows at present between the relevant ingress=20 and egress gateways. In this case the egress requests the ingress to=20 send probe packets, from which it can initialise its meter. RSVP=20 Extensions for such a request to send probe data can be found in=20 [RSVP-PCN].=20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 19]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 3.2. Flow pre-emption=20 In this section we describe the flow pre-emption mechanism. We=20 discuss the two parts of the solution and then give an example of how=20 they fit together in a use case:=20 o How an ingress gateway is triggered to test whether flow pre- emption may be needed=20 o How an ingress gateway determines the right amount of CL traffic=20 to drop=20 The mechanism is defined in [PCN] and [RSVP-PCN].=20 Two subsequent steps could be:=20 o Choose which flows to shed, influenced by their priority and other=20 policy information=20 o Tear down the reservations for the chosen flows=20 We provide some hints about these latter two steps in Section 3.2.3,=20 but don't try to provide full guidance as it greatly depends on the=20 particular detailed operational situation.=20 An essential QoS issue in core and backbone networks is being able to=20 cope with failures of routers and links. The consequent re-routing=20 can cause severe congestion on some links and hence degrade the QoS=20 experienced by on-going microflows and other, lower priority traffic.=20 Even when the network is engineered to sustain a single link failure,=20 multiple link failures (e.g. due to a fibre cut, router failure or a=20 natural disaster) can cause violation of capacity constraints and=20 resulting QoS failures. Our solution uses rate-based flow pre- emption, so that sufficient of the previously admitted CL microflows=20 are dropped to ensure that the remaining ones again receive QoS=20 commensurate with the CL service and at least some QoS is quickly=20 restored to other traffic classes. =20 3.2.1. Alerting an ingress gateway that flow pre-emption may be needed=20 Alerting an ingress gateway that flow pre-emption may be needed is a=20 two stage process: a router in the CL-region alerts an egress gateway=20 that flow pre-emption may be needed; in turn the egress gateway=20 alerts the relevant ingress gateway. Every router in the CL-region=20 has the ability to alert egress gateways, which may be done either=20 explicitly or implicitly: =20 =20 =20 Briscoe Expires April 25, 2007 [Page 20]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Explicit - the router per-hop behaviour is supplemented with a new=20 Pre-emption Marking behaviour, which is outlined below. Reception=20 of such a packet by the egress gateway alerts it that pre-emption=20 may be needed.=20 o Implicit - the router behaviour is unchanged from the Admission=20 Marking behaviour described earlier. The egress gateway treats a=20 Congestion-Level-Estimate of (almost) 100% as an implicit alert=20 that pre-emption may be required. ('Almost' because the=20 Congestion-Level-Estimate is a moving average, so can never reach=20 exactly 100%.)=20 To support explicit pre-emption alerting, each router in the CL- region runs an algorithm to determine whether to Pre-emption Mark the=20 packet. The algorithm measures the aggregate CL traffic and ensures=20 that packets are pre-emption marked before the actual queue builds=20 up. The algorithm's main parameter is the configured-pre-emption- rate, which is set lower than the link speed (but higher than the=20 configured-admission-rate). Thus pre-emption marked packets indicate=20 that the CL traffic rate is reaching the configured-pre-emption-rate=20 and so act as an "early warning" that the engineered capacity is=20 nearly reached. Therefore they indicate that it may be advisable to=20 pre-empt some of the existing CL flows in order to preserve the QoS=20 of the others.=20 Note that the pre-emption marking algorithm doesn't measure the=20 packets that are already Pre-emption Marked. This ensures that in a=20 scenario with several links that are above their configured-pre- emption-rate, then at the egress gateway the rate of packets=20 excluding Pre-emption Marked ones truly does represent the=20 Sustainable-Aggregate-Rate(see below for explanation).=20 Note that the explicit mechanism only makes sense if all the routers=20 in the CL-region have the functionality so that the egress gateways=20 can rely on the explicit mechanism. Otherwise there is the danger=20 that the traffic happens to focus on a router without it, and egress=20 gateways then have also to watch for implicit pre-emption alerts.=20 When one or more packets in a CL-region-aggregate alert the egress=20 gateway of the need for flow pre-emption, whether explicitly or=20 implicitly, the egress puts that CL-region-aggregate into the Pre- emption Alert state. For each CL-region-aggregate in alert state it=20 measures the rate of traffic at the egress gateway (i.e. the traffic=20 rate of the appropriate CL-region-aggregate) and reports this to the=20 relevant ingress gateway. The steps are:=20 =20 =20 Briscoe Expires April 25, 2007 [Page 21]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Determine the relevant ingress gateway - for the explicit case the=20 egress gateway examines the pre-emption marked packet and uses the=20 state installed at the time of admission to determine which=20 ingress gateway the packet came from. For the implicit case the=20 egress gateway has already determined this information, because=20 the Congestion-Level-Estimate is calculated per ingress gateway.=20 o Measure the traffic rate of CL packets - as soon as the egress=20 gateway is alerted (whether explicitly or implicitly) it measures=20 the rate of CL traffic from this ingress gateway (i.e. for this=20 CL-region-aggregate). Note that pre-emption marked packets are=20 excluded from that measurement. It should make its measurement=20 quickly and accurately, but exactly how is up to the=20 implementation. =20 o Alert the ingress gateway - the egress gateway then immediately=20 alerts the relevant ingress gateway about the fact that flow pre- emption may be required. This Alert message also includes the=20 measured Sustainable-Aggregate-Rate, i.e. the rate of CL-traffic=20 received from this ingress gateway. The Alert message is sent=20 using reliable delivery. Procedures for the support of such an=20 Alert using RSVP are defined in [RSVP-PCN].=20 -------------- _ _ ----------------- = =20 CL packet |Update | / Is it a \ Y | Measure CL rate |=20 arrives --->|Congestion- |--->/pre-emption\-----> | from ingress and|=20 |Level-Estimate| \ marked / | alert ingress |=20 -------------- \ packet? / -----------------=20 \_ _/=20 =20 Figure 2: Egress gateway action for explicit Pre-emption Alert =20 _ _ =20 -------------- / \ ----------------- = =20 CL packet |Update | / Is \ Y | Measure CL rate |=20 arrives --->|Congestion- |--->/ C.L.E. \-----> | from ingress and|=20 |Level-Estimate| \ (nearly) / | alert ingress |=20 -------------- \ 100%? / -----------------=20 \_ _/ =20 =20 Figure 3: Egress gateway action for implicit Pre-emption Alert =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 22]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 3.2.2. Determining the right amount of CL traffic to drop=20 The method relies on the insight that the amount of CL traffic that=20 can be supported between a particular pair of ingress and egress=20 gateways, is the amount of CL traffic that is actually getting across=20 the CL-region to the egress gateway without being Pre-emption Marked.=20 Hence we term it the Sustainable-Aggregate-Rate.=20 So when the ingress gateway gets the Alert message from an egress=20 gateway, it compares:=20 o The traffic rate that it is sending to this particular egress=20 gateway (which we term Ingress-Aggregate-Rate)=20 o The traffic rate that the egress gateway reports (in the Alert=20 message) that it is receiving from this ingress gateway (which is=20 the Sustainable-Aggregate-Rate)=20 If the difference is significant, then the ingress gateway pre-empts=20 some microflows. It only pre-empts if:=20 Ingress-Aggregate-Rate > Sustainable-Aggregate-Rate + error=20 The "error" term is partly to allow for inaccuracies in the=20 measurements of the rates. It is also needed because the Ingress- Aggregate-Rate is measured at a slightly later moment than the=20 Sustainable-Aggregate-Rate, and it is quite possible that the=20 Ingress-Aggregate-Rate has increased in the interim due to natural=20 variation of the bit rate of the CL sources. So the "error" term=20 allows for some variation in the ingress rate without triggering pre- emption. =20 The ingress gateway should pre-empt enough microflows to ensure that:=20 New Ingress-Aggregate-Rate < Sustainable-Aggregate-Rate - error=20 The "error" term here is used for similar reasons but in the other=20 direction, to ensure slightly more load is shed than seems necessary,=20 in case the two measurements were taken during a short-term fall in=20 load. =20 When the routers in the CL-region are using explicit pre-emption=20 alerting, the ingress gateway would normally pre-empt microflows=20 whenever it gets an alert (it always would if it were possible to set=20 "error" equal to zero). For the implicit case however this is not so.=20 It receives an Alert message when the Congestion-Level-Estimate=20 reaches (almost) 100%, which is roughly when traffic exceeds the=20 =20 =20 Briscoe Expires April 25, 2007 [Page 23]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 configured-admission-rate. However, it is only when packets are=20 indeed dropped en route that the Sustainable-Aggregate-Rate becomes=20 less than the Ingress-Aggregate-Rate so only then will pre-emption=20 actually occur on the ingress gateway. =20 Hence with the implicit scheme, pre-emption can only be triggered=20 once the system starts dropping packets and thus the QoS of flows=20 starts being significantly degraded. This is in contrast with the=20 explicit scheme which allows flow pre-emption to be triggered before=20 any packet drop, simply when the traffic reaches the configured-pre- emption-rate. Therefore we believe that the explicit mechanism is=20 superior. However it does require new functionality on all the=20 routers (although this is little more than a bulk token bucket - see=20 [PCN] for details). =20 =20 3.2.3. Use case for flow pre-emption =20 To see how the pieces of the solution fit together in a use case, we=20 imagine a scenario where many microflows have already been admitted.=20 We confine our description to the explicit pre-emption mechanism. Now=20 an interior router in the CL-region fails. The network layer routing=20 protocol re-routes round the problem, but as a consequence traffic on=20 other links increases. In fact let's assume the traffic on one link=20 now exceeds its configured-pre-emption-rate and so the router pre- emption marks CL packets. When the egress sees the first one of the=20 pre-emption marked packets it immediately determines which microflow=20 this packet is part of (by using a five-tuple filter and comparing it=20 with state installed at admission) and hence which ingress gateway=20 the packet came from. It sets up a meter to measure the traffic rate=20 from this ingress gateway, and as soon as possible sends a message to=20 the ingress gateway. This message alerts the ingress gateway that=20 pre-emption may be needed and contains the traffic rate measured by=20 the egress gateway. Then the ingress gateway determines the traffic=20 rate that it is sending towards this egress gateway and hence it can=20 calculate the amount of traffic that needs to be pre-empted. =20 The solution operates within a little over one round trip time - the=20 time required for microflow packets that have experienced Pre-emption=20 Marking to travel downstream through the CL-region and arrive at the=20 egress gateway, plus some additional time for the egress gateway to=20 measure the rate seen after it has been alerted that pre-emption may=20 be needed, and the time for the egress gateway to report this=20 information to the ingress gateway. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 24]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 The ingress gateway could now just shed random microflows, but it is=20 better if the least important ones are dropped. The ingress gateway=20 could use information stored locally in each reservation's state=20 (such as for example the RSVP pre-emption priority of [RSVP- PREEMPTION] or the RSVP admission priority of [RSVP-EMERGENCY]) as=20 well as information provided by a policy decision point in order to=20 decide which of the flows to shed (or perhaps which ones not to=20 shed). This way, flow pre-emption can also helps emergency/military=20 calls by taking into account the corresponding priorities (as=20 conveyed in RSVP policy elements) when selecting calls to be pre- empted, which is likely to be particularly important in a disaster=20 scenario. Use of RSVP for support of emergency/military applications=20 is discussed in further details in [RFC4542] and [RSVP-EMERGENCY].=20 The ingress gateway then initiates RSVP signalling to instruct the=20 relevant destinations that their reservation has been terminated, and=20 to tell (RSVP) nodes along the path to tear down associated RSVP=20 state. To guard against recalcitrant sources, normal IntServ policing=20 may be used to block any future traffic from the dropped flows from=20 entering the CL-region. Note that - with the explicit Pre-emption=20 Alert mechanism - since the configured-pre-emption-rate may be=20 significantly less than the physical line capacity, flow pre-emption=20 may be triggered before any congestion has actually occurred and=20 before any packet is dropped.=20 We extend the scenario further by imagining that (due to a disaster=20 of some kind) further routers in the CL-region fail during the time=20 taken by the pre-emption process described above. This is handled=20 naturally, as packets will continue to be pre-emption marked and so=20 the pre-emption process will happen for a second time. =20 =20 3.3. Both admission control and pre-emption=20 This document describes both the admission control and pre-emption=20 mechanisms, and we suggest that an operator uses both. However, we do=20 not require this and some operators may want to implement only one. =20 For example, an operator could use just admission control, solving=20 heavy congestion (caused by re-routing) by 'just waiting' - as=20 sessions end, existing microflows naturally depart from the system=20 over time, and the admission control mechanism will prevent admission=20 of new microflows that use the affected links. So the CL-region will=20 naturally return to normal controlled load service, but with reduced=20 capacity. The drawback of this approach would be that until flows=20 naturally depart to relieve the congestion, all flows and lower=20 =20 =20 Briscoe Expires April 25, 2007 [Page 25]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 priority services will be adversely affected. As another example, an=20 operator could use just admission control, avoiding heavy congestion=20 (caused by re-routing) by 'capacity planning' - by configuring=20 admission control thresholds to lower levels than the network could=20 accept in normal situations such that the load after failure is=20 expected to stay below acceptable levels even with reduced network=20 resources.=20 On the other hand, an operator could just rely for admission control=20 on the traffic conditioning agreements of the DiffServ architecture=20 [RFC2475]. The pre-emption mechanism described in this document would=20 be used to counteract the problem described at the end of Section=20 1.1.1.=20 =20 =20 =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 26]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 4. Summary of Functionality=20 This section is intended to provide a systematic summary of the new=20 functionality required by the routers in the CL-region.=20 A network operator upgrades normal IP routers by:=20 o Adding functionality related to admission control and flow pre- emption to all its ingress and egress gateways=20 o Adding Pre-Congestion Notification for Admission Marking and Pre- emption Marking to all the routers in the CL-region.=20 We consider the detailed actions required for each of the types of=20 router in turn. =20 4.1. Ingress gateways=20 Ingress gateways perform the following tasks:=20 o Classify incoming packets - decide whether they are CL or non-CL=20 packets. This is done using an IntServ filter spec (source and=20 destination addresses and port numbers), whose details have been=20 gathered from the RSVP messaging.=20 o Police - check that the microflow conforms with what has been=20 agreed (i.e. it keeps to its agreed data rate). If necessary,=20 packets which do not correspond to any reservations, packets which=20 are in excess of the rate agreed for their reservation, and=20 packets for a reservation that has earlier been pre-empted may be=20 policed. Policing may be achieved via dropping or via re-marking=20 of the packet's DSCP to a value different from the CL behaviour=20 aggregate.=20 o ECN colouring packets - for CL microflows, set the ECN field of=20 packets appropriately (see [PCN] for some discussion of encoding).=20 o Perform 'interior router' functions (see next sub-section).=20 o Admission Control - on new session establishment, consider the=20 Congestion-Level-Estimate received from the corresponding egress=20 gateway and most likely based on a simple configured CLE-threshold=20 decide if a new call is to be admitted or rejected (taking into=20 account local policy information as well as optionally information=20 provided by a policy decision point).=20 =20 =20 Briscoe Expires April 25, 2007 [Page 27]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Probe - if requested by the egress gateway to do so, the ingress=20 gateway generates probe traffic so that the egress gateway can=20 compute the Congestion-Level-Estimate from this ingress gateway.=20 Probe packets may be simple data addressed to the egress gateway=20 and require no protocol standardisation, although there will be=20 best practice for their number, size and rate.=20 o Measure - when it receives a Pre-emption Alert message from an=20 egress gateway, it determines the rate at which it is sending=20 packets to that egress gateway=20 o Pre-empt - calculate how much CL traffic needs to be pre-empted;=20 decide which microflows should be dropped, perhaps in consultation=20 with a Policy Decision Point; and do the necessary signalling to=20 drop them.=20 4.2. Interior routers=20 Interior routers do the following tasks:=20 o Classify packets - examine the DSCP and ECN field to see if it's a=20 CL packet=20 o Non-CL packets are handled as usual, with respect to dropping them=20 or setting their CE codepoint. =20 o Pre-Congestion Notification - CL packets are Admission Marked and=20 Pre-emption Marked according to the algorithm detailed in [PCN]=20 and outlined in Section 3.=20 =20 4.3. Egress gateways=20 Egress gateways do the following tasks:=20 o Classify packets - determine which ingress gateway a CL packet has=20 come from. This is the previous RSVP hop, hence the necessary=20 details are obtained just as with IntServ from the state=20 associated with the packet five-tuple, which has been built using=20 information from the RSVP messages.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 28]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o Meter - for CL packets, calculate the fraction of the total number=20 of bits which are in Admission marked packets or in Pre-emption=20 Marked packets. The calculation is done as an exponentially=20 weighted moving average (see Appendix C). A separate calculation=20 is made for CL packets from each ingress gateway. The meter works=20 on an aggregate basis and not per microflow.=20 o Signal the Congestion-Level-Estimate - this is piggy-backed on the=20 reservation reply. An egress gateway's interface is configured to=20 know it is an egress gateway, so it always appends this to the=20 RESV message. If the Congestion-Level-Estimate is unknown or is=20 too stale, then the egress gateway can request the ingress gateway=20 to send probes. =20 o Packet colouring - for CL packets, set the DSCP and the ECN field=20 to whatever has been agreed as appropriate for the next domain. By=20 default the ECN field is set to the Not-ECT codepoint. See also=20 the discussion in the Tunnelling section later. =20 o Measure the rate - measure the rate of CL traffic from a=20 particular ingress gateway, excluding packets that are Pre-emption=20 Marked (i.e. the Sustainable-Aggregate-Rate for the CL-region- aggregate), when alerted (either explicitly or implicitly) that=20 pre-emption may be required. The measured rate is reported back to=20 the appropriate ingress gateway [RSVP-PCN]. =20 4.4. Failures =20 If an interior router fails, then the regular IP routing protocol=20 will re-route round it. If the new route can carry all the admitted=20 traffic, flows will gracefully continue. If instead this causes early=20 warning of pre-congestion on the new route, then admission control=20 based on pre-congestion notification will ensure new flows will not=20 be admitted until enough existing flows have departed. Finally re- routing may result in heavy congestion, when the flow pre-emption=20 mechanism will kick in. =20 If a gateway fails then we would like regular RSVP procedures=20 [RFC2205] to take care of things. With the local repair mechanism of=20 [RFC2205], when a route changes the next RSVP PATH refresh message=20 will establish path state along the new route, and thus attempt to=20 re-establish reservations through the new ingress gateway.=20 Essentially the same procedure is used as described earlier in this=20 document, with the re-routed session treated as a new session=20 request.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 29]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 In more detail, consider what happens if an ingress gateway of the=20 CL-region fails. Then RSVP routers upstream of it do IP re-routing to=20 a new ingress gateway. The next time the upstream RSVP router sends a=20 PATH refresh message it reaches the new ingress gateway which=20 therefore installs the associated RSVP state. The next RSVP RESV=20 refresh will pick up the Congestion-Level-Estimate from the egress=20 gateway, and the ingress compares this with its threshold to decide=20 whether to admit the new session. This could result in some of the=20 flows being rejected, but those accepted will receive the full QoS.=20 An issue with this is that we have to wait until a PATH and RESV=20 refresh messages are sent - which may not be very often - the default=20 value is 30 seconds. [RFC2205] discusses how to speed up the local=20 repair mechanism. First, the RSVP module is notified by the local=20 routing protocol module of a route change to particular destinations,=20 which triggers it to rapidly send out PATH refresh messages. Further,=20 when a PATH refresh arrives with a previous hop address different=20 from the one stored, then RESV refreshes are immediately sent to that=20 previous hop. Where RSVP is operating hop-by-hop, i.e. on every=20 router, then triggering the PATH refresh is easy as the router can=20 simply monitor its local link. Thus, this fast local repair mechanism=20 can be used to deal with failures upstream of the ingress gateway,=20 with failures of the ingress gateway and with failures downstream of=20 the egress gateway.=20 But where RSVP is not operating hop-by-hop (as is the case within the=20 CL-region), it is not so easy to trigger the PATH refresh.=20 Unfortunately, this problem applies if an egress gateway fails, since=20 it's very likely that an egress gateway is several IP hops from the=20 ingress gateway. (If the ingress is several IP hops from its previous=20 RSVP node, then there is the same issue.) The options appear to be:=20 o the ingress gateway has a link state database for the CL-region,=20 so it can detect that an egress gateway has failed or became=20 unreachable=20 o there is an inter-gateway protocol, so the ingress can=20 continuously check that the egress gateways are still alive=20 o (default) do nothing and wait for the regular PATH/RESV refreshes=20 (and, if needed, the pre-emption mechanism) to sort things out.=20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 30]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 5. Limitations and some potential solutions=20 In this section we describe various limitations of the deployment=20 model, and some suggestions about potential ways of alleviating them.=20 The limitations fall into three broad categories:=20 o ECMP (Section 5.1): the assumption about routing (Section 2.2) is=20 that all packets between a pair of ingress and egress gateways=20 follow the same path; ECMP breaks this assumption. A study=20 regarding the accuracy of load balancing schemes can be found in=20 [LoadBalancing-a] and [LoadBalancing-b].=20 o The lack of global coordination (Sections 5.2, 5.3 and 5.4): a=20 decision about admission control or flow pre-emption is made for=20 one aggregate independently of other aggregates=20 o Timing and accuracy of measurements (Sections 5.5 and 5.6): the=20 assumption (Section 2.2) that additional load, offered within the=20 reaction time of the measurement-based admission control=20 mechanism, doesn't move the system directly from no congestion to=20 overload (dropping packets). A 'flash crowd' may break this=20 assumption (Section 5.5). There are a variety of more general=20 issues associated with marking measurements, which may mean it's a=20 good idea to do pre-emption 'slower' (Section 5.6).=20 Each section describes a limitation and some possible solutions to=20 alleviate the limitation. These are intended as options for an=20 operator to consider, based on their particular requirements. =20 We would welcome feedback, for example suggestions as to which=20 potential solutions are worth working out in more detail, and ideas=20 on new potential solutions. =20 Finally Section 5.7 considers some other potential extensions.=20 =20 5.1. ECMP=20 If the CL-region uses Equal Cost Multipath Routing (ECMP), then=20 traffic between a particular pair of ingress and egress gateways may=20 follow several different paths.=20 Why? An ECMP-enabled router runs an algorithm to choose between=20 potential outgoing links, based on a hash of fields such as the=20 packet's source and destination addresses - exactly what depends on=20 the proprietary algorithm. Packets are addressed to the CL flow's=20 =20 =20 Briscoe Expires April 25, 2007 [Page 31]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 end-point, and therefore different flows may follow different paths=20 through the CL-region. (All packets of an individual flow follow the=20 same ECMP path.)=20 The problem is that if one of the paths is congested such that=20 packets are being admission marked, then the Congestion-Level- Estimate measured by the egress gateway will be diluted by unmarked=20 packets from other non-congested paths. Similarly, the measurement of=20 the Sustainable-Aggregate-Rate will also be diluted. =20 Possible solution approaches are:=20 o tunnel: traffic is tunnelled across the CL-region. Then the=20 destination address (and so on) seen by the ECMP algorithm is that=20 of the egress gateway, so all flows follow the same path.=20 Effectively ECMP is turned off. As a compromise, to try to retain=20 some of the benefits of ECMP, there could be several tunnels, each=20 following a different ECMP path, with flows randomly assigned to=20 different tunnels. =20 o assume worst case: the operator sets the configured-admission-rate=20 (and configured-pre-emption-rate) to below the optimum level to=20 compensate for the fact that the effect on the Congestion-Level- Estimate (and Sustainable-Aggregate-Rate) of the congestion=20 experienced over one of the paths may be diluted by traffic=20 received over non-congested paths. Hence lower thresholds need to=20 be used to ensure early admission control rejection and pre- emption over the congested path. This approach will waste capacity=20 (e.g. flows following a non-congested ECMP path are not admitted=20 or are pre-empted), and there is still the danger that for some=20 traffic mixes the operator hasn't been cautious enough.=20 o for admission control, probe to obtain a flow-specific congestion- level-estimate. Earlier this document suggests continuously=20 monitoring the congestion-level-estimate. Instead, probe packets=20 could be sent for each prospective new flow. The probe packets=20 have the same IP address etc as the data packets would have, and=20 hence follow the same ECMP path. However, probing is an extra=20 overhead, depending on how many probe packets need to be sent to=20 get a sufficiently accurate congestion-level-estimate. Probes also=20 cause a processing overhead, either for the machine at the=20 destination address or for the egress gateway to identify and=20 remove the probe packets.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 32]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o for flow pre-emption, only select flows for pre-emption from=20 amongst those that have actually received a Pre-emption Marked=20 packet. Because these flows must have followed an ECMP path that=20 goes through an overloaded router. However, it needs some extra=20 work by the egress gateway, to record this information and report=20 it to the ingress gateway. =20 o for flow pre-emption, a variant of this idea involves introducing=20 a new marking behaviour, 'Router Marking'. A router that is pre- emption marking packets on an outgoing link, also 'Router Marks'=20 all other packets. When selecting flows for pre-emption, the=20 selection is made from amongst those that have actually received a=20 Router Marked or Pre-emption Marked packet. Hence compared with=20 the previous bullet, it may extend the range of flows from which=20 the pre-emption selection is made (i.e. it includes those which,=20 by chance, haven't had any pre-emption marked packets). However,=20 it also requires that the 'Router Marking' state is somehow=20 encoded into a packet, i.e. it makes harder the encoding challenge=20 discussed in Appendix C of [PCN]. The extra work required by the=20 egress gateway would also be somewhat higher than for the previous=20 bullet. =20 =20 5.2. Beat down effect=20 This limitation concerns the pre-emption mechanism in the case where=20 more than one router is pre-emption marking packets. The result=20 (explained in the next paragraph) is that the measurement of=20 sustainable-aggregate-rate is lower than its true value, so more=20 traffic is pre-empted than necessary.=20 Imagine the scenario:=20 +-------+ +-------+ +-------+=20 IAR-b=3D3 >@@@@@| CPR=3D2 |@@@@@| CPR>2 |@@@@@| CPR=3D1 |@@> SAR-b=3D1= =20 IAR-a=3D1 >#####| R1 |#####| R2 | | R3 | =20 +-------+ +-------+ +-------+=20 #=20 #=20 #=20 v SAR-a=3D0.5=20 =20 Figure 4: Scenario to illustrate 'beat down effect' limitation=20 =20 Aggregate-a (ingress-aggregate-rate, IAR, 1 unit) takes a 'short'=20 route through two routers, one of which (R1) is above its configured- =20 =20 Briscoe Expires April 25, 2007 [Page 33]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 pre-emption-rate (CPR, 2 units). Aggregate-b takes a 'long' route,=20 going through a second congested router (R3, with a CPR of 1 unit). =20 R1's input traffic is 4 units, twice its configured-pre-emption-rate,=20 so 50% of packets are pre-emption marked. Hence the measured=20 sustainable-aggregate-rate (SAR) for aggregate-a is 0.5, and half of=20 its traffic will be pre-empted. =20 R3's input of non-pre-emption-marked traffic is 1.5 units, and=20 therefore it has to do further marking. =20 But this means that aggregate-a has taken a bigger hit than it needed=20 to; the router R1 could have let through all of aggregate-a's traffic=20 unmarked if it had known that the second router R2 was going to "beat=20 down" aggregate-b's traffic further. =20 Generalising, the result is that in a scenario where more than one=20 router is pre-emption marking packets, only the final router is sure=20 to be fully loaded after flow pre-emption. The fundamental reason is=20 that a router makes a local decision about which packets to pre- emption mark, i.e. independently of how other routers are pre-emption=20 marking. A very similar effect has been noted in XCP [Low].=20 Potential solutions:=20 o a full solution would involve routers learning about other routers=20 that are pre-emption marking, and being able to differentially=20 mark flows (e.g. in the example above, aggregate-a's packets=20 wouldn't be marked by R1). This seems hard and complex.=20 o do nothing about this limitation. It causes over-pre-emption,=20 which is safe. At the moment this is our suggested option. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 34]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o do pre-emption 'slowly'. The description earlier in this document=20 assumes that after the measurements of ingress-aggregate-rate and=20 sustainable-aggregate-rate, then sufficient flows are pre-empted=20 in 'one shot' to eliminate the excess traffic. An alternative is=20 to spread pre-emption over several rounds: initially, only pre- empt enough to eliminate some of the excess traffic, then re- measure the sustainable-aggregate-rate, and then pre-empt some=20 more, etc. In the scenario above, the re-measurement would be=20 lower than expected, due to the beat down effect, and hence in the=20 second round of pre-emption less of aggregate-a's traffic would be=20 pre-empted (perhaps none). Overall, therefore the impact of the=20 'beat down' effect would be lessened, i.e. there would be a=20 smaller degree of over pre-emption. The downside is that the=20 overall pre-emption is slower, and therefore routers will be=20 congested longer. =20 =20 =20 5.3. Bi-directional sessions=20 The document earlier describes how to decide whether or not to admit=20 (or pre-empt) a particular flow. However, from a user/application=20 perspective, the session is the relevant unit of granularity. A=20 session can consist of several flows which may not all be part of the=20 same aggregate. The most obvious example is a bi-directional session,=20 where the two flows should ideally be admitted or pre-empted as a=20 pair - for instance a voice call only makes sense if A can send to B=20 as well as B to A! But the admission and pre-emption mechanisms=20 described earlier in this document operate on a per-aggregate basis,=20 independently of what's happening with other aggregates. For=20 admission control the problem isn't serious: e.g. the SIP server for=20 the voice call can easily detect that the A-to-B flow has been=20 admitted but the B-to-A flow blocked, and inform the user perhaps via=20 a busy tone. For flow pre-emption, the problem is similar but more=20 serious. If both the aggregate-1-to-2 (i.e. from gateway 1 to gateway=20 2) and the aggregate-2-to-1 have to pre-empt flows, then it would be=20 good if either all of the flows of a particular session were pre- empted or none of them. Therefore if the two aggregates pre-empt=20 flows independently of each other, more sessions will end up being=20 torn down than is really necessary. For instance, pre-empting one=20 direction of a voice call will result in the SIP server tearing down=20 the other direction anyway. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 35]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 Potential solutions:=20 o if it's known that all session are bi-directional, simply pre- empting roughly half as many flows as suggested by the=20 measurements of {ingress-aggregate-rate - sustainable-aggregate- rate}. But this makes a big assumption about the nature of=20 sessions, and also that the aggregate-1-to-2 and aggregate-2-to-1=20 are equally overloaded. =20 o ignore the limitation. The penalty will be quite small if most=20 sessions consist of one flow or of flows part of the same=20 aggregate. =20 o introduce a gateway controller. It would receive reports for all=20 aggregates where the ingress-aggregate-rate exceeds the=20 sustainable-aggregate-rate. It then would make a global decision=20 about which flows to pre-empt. However it requires quite some=20 complexity, for example the controller needs to understand which=20 flows map to which sessions. This may be an option in some=20 scenarios, for example where gateways aren't handling too many=20 flows (but note that this breaks the aggregation assumption of=20 Section 2.2). A variant of this idea would be to introduce a=20 gateway controller per pair of gateways, in order to handle bi- directional sessions but not try to deal with more complex=20 sessions that include flows from an arbitrary number of=20 aggregates. =20 o do pre-emption 'slowly'. As in the "beat down" solution 4, this=20 would reduce the impact of this limitation. The downside is that=20 the overall pre-emption is slower, and therefore router(s) will be=20 congested longer. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 36]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o each ingress gateway 'loosely coordinates' with other gateways its=20 decision about which specific flows to pre-empt. Each gateway=20 numbers flows in the order they arrive (note that this number has=20 no meaning outside the gateway), and when pre-empting flows, the=20 most recent (or most recent low priority flow) is selected for=20 pre-emption; the gateway then works backwards selecting as many=20 flows as needed. Gateways will therefore tend to pre-empt flows=20 that are part of the same session (as they were admitted at the=20 same time). Of course this isn't guaranteed for several reasons,=20 for instance gateway A's most recent bi-directional sessions may=20 be with gateway C, whereas gateway B's are with gateway A (so=20 gateway A will pre-empt A-to-C flows and gateway B will pre-empt=20 B-to-A flows). Rather than pre-empting the most recent (low=20 priority) flow, an alternative algorithm (for further study) may=20 be to select flows based on a hash of particular fields in the=20 packet, such that both gateways produce the same hash for flows of=20 the same bi-directional session. We believe that this approach=20 should be investigated further.=20 =20 =20 =20 5.4. Global fairness=20 The limitation here is that 'high priority' traffic may be pre-empted=20 (or not admitted) when a global decision would instead pre-empt (or=20 not admit) 'lower priority' traffic on a different aggregate.=20 Imagine the following scenario (extreme to illustrate the point=20 clearly). Aggregate_a is all Assured Services (MLPP) traffic, whilst=20 aggregate_b is all ordinary traffic (i.e. comparatively low=20 priority). Together the two aggregates cause a router to be at twice=20 its configured-pre-emption-rate. Ideally we'd like all of aggregate_b=20 to be pre-empted, as then all of aggregate_a could be carried.=20 However, the approach described earlier in this document leads to=20 half of each aggregate being pre-empted.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 37]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 IAR_b=3D1=20 v=20 v=20 +-------+ =20 IAR_a=3D1 ---->-----| CPR=3D1 |-----> SAR_a=3D0.5=20 | |=20 +-------+ =20 v=20 v=20 SAR_a=3D0.5=20 =20 Figure 5: Scenario to illustrate 'global fairness' limitation=20 =20 Similarly, for admission control - Section 4.1 describes how if the=20 Congestion-Level-Estimate is greater than the CLE-threshold all new=20 sessions are refused. But it is unsatisfactory to block emergency=20 calls, for instance. =20 =20 Potential solutions:=20 o in the admission control case, it is recommended that an=20 'emergency / Assured Services' call is admitted immediately even=20 if the CLE-threshold is exceeded. Usually the network can actually=20 handle the additional microflow, because there is a safety margin=20 between the configured-admission-rate and the configured-pre- emption-rate. Normal call termination behaviour will soon bring=20 the traffic level down below the configured-admission-rate.=20 However, in exceptional circumstances the 'emergency / higher=20 precedence' call may cause the traffic level to exceed the=20 configured-pre-emption-rate; then the usual pre-emption mechanism=20 will pre-empt enough (non 'emergency / higher precedence')=20 microflows to bring the total traffic back under the configured- pre-emption-rate.=20 o all egress gateways report to a global coordinator that makes=20 decisions about what flows to pre-empt. However this solution adds=20 complexity and probably isn't scalable, but it may be an option in=20 some scenarios, for example where gateways aren't handling too=20 many flows (but note that this breaks the aggregation assumption=20 of Section 2.2). =20 =20 =20 Briscoe Expires April 25, 2007 [Page 38]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o introduce a heuristic rule: before pre-empting a 'high priority'=20 flow the egress gateway should wait to see if sufficient (lower=20 priority) traffic is pre-empted on other aggregates. This is a=20 reasonable option.=20 o enhance the functionality of all the interior routers, so they can=20 detect the priority of a packet, and then differentially mark=20 them. As well as adding complexity, in general this would be an=20 unacceptable security risk for MLPP traffic, since only controlled=20 nodes (like gateways) should know which packets are high priority,=20 as this information can be abused by an attacker. =20 o do nothing, i.e. accept the limitation. Whilst it's unlikely that=20 high priority calls will be quite so unbalanced as in the scenario=20 above, just accepting this limitation may be risky. The sorts of=20 situations that cause routers to start pre-emption marking are=20 also likely to cause a surge of emergency / MLPP calls. =20 =20 =20 5.5. Flash crowds=20 This limitation concerns admission control and arises because there=20 is a time lag between the admission control decision (which depends=20 on the Congestion-Level-Estimate during RSVP signalling during call=20 set-up) and when the data is actually sent (after the called party=20 has answered). In PSTN terms this is the time the phone rings.=20 Normally the time lag doesn't matter much because (1) in the CL- region there are many flows and they terminate and are answered at=20 roughly the same rate, and (2) the network can still operate safely=20 when the traffic level is some margin above the configured-admission- rate.=20 A 'flash crowd' occurs when something causes many calls to be=20 initiated in a short period of time - for instance a 'tele-vote'. So=20 there is a danger that a 'flash' of calls is accepted, but when the=20 calls are answered and data flows the traffic overloads the network.=20 Therefore potentially the 'additional load' assumption of Section 2.2=20 doesn't hold. =20 Potential solutions:=20 =20 =20 Briscoe Expires April 25, 2007 [Page 39]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 o The simplest option is to do nothing; an operator relies on the=20 pre-emption mechanism if there is a problem. This doesn't seem a=20 good choice, as 'flash crowds' are reasonably common on the PSTN,=20 unless the operator can ensure that nearly all 'flash crowd'=20 events are blocked in the access network and so do not impact on=20 the CL-region.=20 o A second option is to send 'dummy data' as soon as the call is=20 admitted, thus effectively reserving the bandwidth whilst waiting=20 for the called party to answer. Reserving bandwidth in advance=20 means that the network cannot admit as many calls. For example,=20 suppose sessions last 100 seconds and ringing for 10 seconds, the=20 cost is a 10% loss of capacity. It may be possible to offset this=20 somewhat by increasing the configured-admission-rate in the=20 routers, but it would need further investigation. A concern with=20 this 'dummy data' option is that it may allow an attacker to=20 initiate many calls that are never answered (by a cooperating=20 attacker), so eventually the network would only be carrying 'dummy=20 data'. The attack exploits that charging only starts when the call=20 is answered and not when it is dialled. It may be possible to=20 alleviate the attack at the session layer - for example, when the=20 ingress gateway gets an RSVP PATH message it checks that the=20 source has been well-behaved recently; and limiting the maximum=20 time that ringing can last. We believe that if this attack can be=20 dealt with then this is a good option. =20 o A third option is that the egress gateway limits the rate at which=20 it sends out the Congestion-Level-Estimate, or limits the rate at=20 which calls are accepted by replying with a Congestion-Level- Estimate of 100% (this is the equivalent of 'call gapping' in the=20 PSTN). There is a trade-off, which would need to be investigated=20 further, between the degree of protection and possible adverse=20 side-effects like slowing down call set-up.=20 o A final option is to re-perform admission control before the call=20 is answered. The ingress gateway monitors Congestion-Level- Estimate updates received from each egress. If it notices that a=20 Congestion-Level-Estimate has risen above the CLE-threshold, then=20 it terminates all unanswered calls through that egress (e.g. by=20 instructing the session protocol to stop the 'ringing tone'). For=20 extra safety the Congestion-Level-Estimate could be re-checked=20 when the call is answered. A potential drawback for an operator=20 that wants to emulate the PSTN is that the PSTN network never=20 drops a 'ringing' PSTN call. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 40]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 5.6. Pre-empting too fast=20 As a general idea it seems good to pre-empt excess flows rapidly, so=20 that the full QoS is restored to the remaining CL users as soon as=20 possible, and partial service is restored to lower priority traffic=20 classes on shared links. Therefore the pre-emption mechanism=20 described earlier in this document works in 'one shot', i.e. one=20 measurement is made of the sustainable-aggregate-rate and the=20 ingress-aggregate-rate, and the excess is pre-empted immediately.=20 However, there are some reasons why an operator may potentially want=20 to pre-empt 'more slowly':=20 o To allow time to modify the ingress gateway's policer, as the=20 ingress wants to be able to drop any packets that arrive from a=20 pre-empted flow. There will be a limit on how many new filters an=20 ingress gateway can install in a certain time period. Otherwise=20 the source may cheat and ignore the instruction to drop its flow. =20 o The operator may decide to slow down pre-emption in order to=20 ameliorate the 'beat down' and/or 'bi-directional sessions'=20 limitations (see above)=20 o To help combat inaccuracies in measurements of the sustainable- aggregate-rate and ingress-aggregate-rate. For a CL-region where=20 it's assumed there are many flows in an aggregate these=20 measurements can be obtained in a short period of time, but where=20 there are fewer flows it will take longer.=20 o To help combat over pre-emption because, during the time it takes=20 to pre-empt flows, others may be ending anyway (either the call=20 has naturally ended, or the user hangs up due to poor QoS).=20 Slowing pre-emption may seem counter-intuitive here, as it makes=20 it more likely that calls will terminate anyway - however it also=20 gives time to adjust the amount pre-empted to take account of=20 this.=20 o Earlier in this document we said that an egress starts measuring=20 the sustainable-aggregate-rate immediately it sees a single pre- emption marked packet. However, when a link or router fails the=20 network's underlying recovery mechanism will kick in (e.g.=20 switching to a back up path), which may result in the network=20 again being able to support all the traffic.=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 41]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 Potential solutions=20 o To combat the final issue, the egress could measure the=20 sustainable-aggregate-rate over a longer time period than the=20 network recovery time (say 100ms vs. 50ms). If it detects no pre- emption marked packets towards the end of its measurement period=20 (say in the last 30 ms) then it doesn't send a pre-emption alert=20 message to the ingress.=20 o We suggest that optionally (the choice of the operator) pre- emption is slowed by pre-empting traffic in several rounds rather=20 than in one shot. One possible algorithm is to pre-empt most of=20 the traffic in the first round and the rest in the second round;=20 the amount pre-empted in the second round is influenced by both=20 the first and second round measurements: * Round 1: pre-empt h=20 * S_1 where 0.5 <=3D h <=3D 1 = =20 where S_1 is the amount the normal mechanism calculates that it=20 should shed, i.e. {ingress-aggregate-rate - sustainable-aggregate- rate} * Round 2: pre-empt Predicted-S_2 - h * (Predicted- S_2 - Measured-S_2) =20 where Predicted-S_2 =3D (1-h)*S_1 Note= =20 that the second measurement should be made when sufficient time=20 has elapsed for the first round of pre-emption to have happened.=20 One idea to achieve this is for the egress gateway to continuously=20 measure and report its sustainable-aggregate-rate, in (say) 100ms=20 windows. Therefore the ingress gateway knows when the egress=20 gateway made its measurement (assuming the round trip time is=20 known). Therefore the ingress gateway knows when measurements=20 should reflect that it has pre-empted flows. =20 =20 =20 5.7. Other potential extensions=20 In this section we discuss some other potential extensions not=20 already covered above.=20 5.7.1. Tunnelling=20 It is possible to tunnel all CL packets across the CL-region.=20 Although there is a cost of tunnelling (additional header on each=20 packet, additional processing at tunnel ingress and egress), there=20 are three reasons it may be interesting.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 42]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 ECMP: =20 Tunnelling is one of the possible solutions given earlier in Section=20 5.1 on Equal Cost Multipath Routing (ECMP).=20 Ingress gateway determination:=20 If packets are tunnelled from ingress gateway to egress gateway, the=20 egress gateway can very easily determine in the data path which=20 ingress gateway a packet comes from (by simply looking at the source=20 address of the tunnel header). This can facilitate operations such as=20 computing the Congestion-Level-Estimate on a per ingress gateway=20 basis.=20 End-to-end ECN:=20 The ECN field is used for PCN marking (see [PCN] for details), and so=20 it needs to be re-set by the egress gateway to whatever has been=20 agreed as appropriate for the next domain. Therefore if a packet=20 arrives at the ingress gateway with its ECN field already set (i.e.=20 not '00'), it may leave the egress gateway with a different value.=20 Hence the end-to-end meaning of the ECN field is lost. =20 It is open to debate whether end-to-end congestion control is ever=20 necessary within an end-to-end reservation. But if a genuine need is=20 identified for end-to-end ECN semantics within a reservation, then=20 one solution is to tunnel CL packets across the CL-region. When the=20 egress gateway decapsulates them the original ECN field is recovered. = =20 =20 5.7.2. Multi-domain and multi-operator usage=20 This potential extension would eliminate the trust assumption=20 (Section 2.2), so that the CL-region could consist of multiple=20 domains run by different operators that did not trust each other.=20 Then only the ingress and egress gateways of the CL-region would take=20 part in the admission control procedure, i.e. at the ingress to the=20 first domain and the egress from the final domain. The border routers=20 between operators within the CL-region would only have to do bulk=20 accounting - they wouldn't do per microflow metering and policing,=20 and they wouldn't take part in signal processing or hold per flow=20 state [Briscoe]. [Re-feedback] explains how a downstream domain can=20 police that its upstream domain does not 'cheat' by admitting traffic=20 when the downstream path is congested. [Re-PCN] proposes how to=20 achieve this with the help of another recently proposed extension to=20 ECN, involving re-echoing ECN feedback [Re-ECN]. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 43]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 5.7.3. Preferential dropping of pre-emption marked packets=20 When the rate of real-time traffic in the specified class exceeds the=20 maximum configured rate, then a router has to drop some packet(s)=20 instead of forwarding them on the out-going link. Now when the egress=20 gateway measures the Sustainable-Aggregate-Rate, neither dropped=20 packets nor pre-emption marked packets contribute to it. Dropping=20 non-pre-emption-marked packets therefore reduces the measured=20 Sustainable-Aggregate-Rate below its true value. Thus a router should=20 preferentially drop pre-emption marked packets. =20 Note that it is important that the operator doesn't set the=20 configured-pre-emption-rate equal to the rate at which packets start=20 being dropped (for the specified real-time service class). Otherwise=20 the egress gateway may never see a pre-emption marked packet and so=20 won't be triggered into the Pre-emption Alert state. =20 This optimisation is optional. When considering whether to use it an=20 operator will consider issues such as whether the over-pre-emption is=20 serious, and whether the particular routers can easily do this sort=20 of selective drop.=20 =20 5.7.4. Adaptive bandwidth for the Controlled Load service=20 The admission control mechanism described in this document assumes=20 that each router has a fixed bandwidth allocated to CL flows. A=20 possible extension is that the bandwidth is flexible, depending on=20 the level of non-CL traffic. If a large share of the current load on=20 a path is CL, then more CL traffic can be admitted. And if the=20 greater share of the load is non-CL, then the admission threshold can=20 be proportionately lower. The approach re-arranges sharing between=20 classes to aim for economic efficiency, whatever the traffic load=20 matrix. It also deals with unforeseen changes to capacity during=20 failures better than configuring fixed engineered rates. Adaptive=20 bandwidth allocation can be achieved by changing the admission=20 marking behaviour, so that the probability of admission marking a=20 packet would now depend on the number of queued non-CL packets as=20 well as the size of the virtual queue. The adaptive bandwidth=20 approach would be supplemented by placing limits on the adaptation to=20 prevent starvation of the CL by other traffic classes and of other=20 classes by CL traffic. [Songhurst] has more details of the adaptive=20 bandwidth approach.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 44]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 5.7.5. Controlled Load service with end-to-end Pre-Congestion=20 Notification=20 It may be possible to extend the framework to parts of the network=20 where there are only a low number of CL microflows, i.e. the=20 aggregation assumption (Section 2.2) doesn't hold. In the extreme it=20 may be possible to operate the framework end-to-end, i.e. between end=20 hosts. One potential method is to send probe packets to test whether=20 the network can support a prospective new CL microflow. The probe=20 packets would be sent at the same traffic rate as expected for the=20 actual microflow, but in order not to disturb existing CL traffic a=20 router would always schedule probe packets behind CL ones (compare=20 [Breslau00]); this implies they have a new DSCP. Otherwise the=20 routers would treat probe packets identically to CL packets. In order=20 to perform admission control quickly, in parts of the network where=20 there are only a few CL microflows, the algorithm for Admission=20 Marking described in [PCN] would need to "switch on" very rapidly, ie=20 go from marking no packets to marking them all for only a minimal=20 increase in the size of the virtual queue.=20 5.7.6. MPLS-TE=20 [ECN-MPLS] discusses how to extend the deployment model to MPLS, i.e.=20 for admission control of microflows into a set of MPLS-TE aggregates=20 (Multi-protocol label switching traffic engineering). It would=20 require that the MPLS header could include the ECN field, which is=20 not precluded by RFC3270. See [ECN-MPLS].=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 45]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 6. Relationship to other QoS mechanisms=20 6.1. IntServ Controlled Load=20 The CL mechanism delivers QoS similar to Integrated Services=20 controlled load, but rather better. The reason the QoS is better is=20 that the CL mechanism keeps the real queues empty, by driving=20 admission control from a bulk virtual queue on each interface. The=20 virtual queue [AVQ, vq] can detect a rise in load before the real=20 queue builds. It is also more robust to route changes. =20 6.2. Integrated services operation over DiffServ=20 Our approach to end-to-end QoS is similar to that described in=20 [RFC2998] for Integrated services operation over DiffServ networks.=20 Like [RFC2998], an IntServ class (CL in our case) is achieved end-to- end, with a CL-region viewed as a single reservation hop in the total=20 end-to-end path. Interior routers of the CL-region do not process=20 flow signalling nor do they hold per flow state. Unlike [RFC2998] we=20 do not require the end-to-end signalling mechanism to be RSVP,=20 although it can be. =20 Bearing in mind these differences, we can describe our architecture=20 in the terms of the options in [RFC2998]. The DiffServ network region=20 is RSVP-aware, but awareness is confined to (what [RFC2998] calls)=20 the "border routers" of the DiffServ region. We use explicit=20 admission control into this region, with static provisioning within=20 it. The ingress "border router" does per microflow policing and sets=20 the DSCP and ECN fields to indicate the packets are CL ones (i.e. we=20 use router marking rather than host marking).=20 6.3. Differentiated Services=20 The DiffServ architecture does not specify any way for devices=20 outside the domain to dynamically reserve resources or receive=20 indications of network resource availability. In practice, service=20 providers rely on subscription-time Service Level Agreements (SLAs)=20 that statically define the parameters of the traffic that will be=20 accepted from a customer. The CL mechanism allows dynamic reservation=20 of resources through the DiffServ domain and, with the potential=20 extension mentioned in Section 5.7.2, it can span multiple domains=20 without active policing mechanisms at the borders (unlike DiffServ).=20 Therefore we do not use the traffic conditioning agreements (TCAs) of=20 the (informational) DiffServ architecture [RFC2475]. =20 An important benefit arises from the fact that the load is controlled=20 dynamically rather than with traffic conditioning agreements (TCAs).=20 =20 =20 Briscoe Expires April 25, 2007 [Page 46]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 TCAs were originally introduced in the (informational) DiffServ=20 architecture [RFC2475] as an alternative to reservation processing in=20 the interior region in order to reduce the burden on interior=20 routers. With TCAs, in practice service providers rely on=20 subscription-time Service Level Agreements that statically define the=20 parameters of the traffic that will be accepted from a customer. The=20 problem arises because the TCA at the ingress must allow any=20 destination address, if it is to remain scalable. But for longer=20 topologies, the chances increase that traffic will focus on an=20 interior resource, even though it is within contract at the ingress=20 [Reid], e.g. all flows converge on the same egress gateway. Even=20 though networks can be engineered to make such failures rare, when=20 they occur all inelastic flows through the congested resource fail=20 catastrophically. =20 [Johnson] compares admission control with a 'generously dimensioned'=20 DiffServ network as ways to achieve QoS. The former is recommended. =20 6.4. ECN=20 The marking behaviour described in this document complies with the=20 ECN aspects of the IP wire protocol RFC3168, but provides its own=20 edge-to-edge feedback instead of the TCP aspects of RFC3168. All=20 routers within the CL-region are upgraded with the admission marking=20 and pre-emption marking of Pre-Congestion Notification, so the=20 requirements of [Floyd] are met because the CL-region is an enclosed=20 environment. The operator prevents traffic arriving at a router that=20 doesn't understand CL by administrative configuration of the ring of=20 gateways around the CL-region. =20 6.5. RTECN=20 Real-time ECN (RTECN) [RTECN, RTECN-usage] has a similar aim to this=20 document (to achieve a low delay, jitter and loss service suitable=20 for RT traffic) and a similar approach (per microflow admission=20 control combined with an "early warning" of potential congestion=20 through setting the CE codepoint). But it explores a different=20 architecture without the aggregation assumption: host-to-host rather=20 than edge-to-edge. We plan to document such a host-to-host framework=20 in a parallel draft to this one, and to describe if and how [PCN] can=20 work in this framework. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 47]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 6.6. RMD=20 Resource Management in DiffServ (RMD) [RMD] is similar to this work,=20 in that it pushes complex classification, traffic conditioning and=20 admission control functions to the edge of a DiffServ domain and=20 simplifies the operation of the interior routers. One of the RMD=20 modes ("Congestion notification function based on probing") uses=20 measurement-based admission control in a similar way to this=20 document. The main difference is that in RMD probing plays a=20 significant role in the admission control process. Other differences=20 are that the admission control decision is taken on the egress=20 gateway (rather than the ingress); 'admission marking' is encoded in=20 a packet as a new DSCP (rather than in the ECN field), and that the=20 NSIS protocols are used for signalling (rather than RSVP).=20 RMD also includes the concept of Severe Congestion handling. The pre- emption mechanism described in the CL architecture has similar=20 objectives but relies on different mechanisms. The main difference is=20 that the interior routers measure the data rate that causes an=20 overload and mark packets according to this rate. =20 6.7. RSVP Aggregation over MPLS-TE=20 Multi-protocol label switching traffic engineering (MPLS-TE) allows=20 scalable reservation of resources in the core for an aggregate of=20 many microflows. To achieve end-to-end reservations, admission=20 control and policing of microflows into the aggregate can be achieved=20 using techniques such as RSVP Aggregation over MPLS TE Tunnels as per=20 [AGGRE-TE]. However, in the case of inter-provider environments,=20 these techniques require that admission control and policing be=20 repeated at each trust boundary or that MPLS TE tunnels span multiple=20 domains. =20 6.8. Other Network Admission Control Approaches=20 Link admission control (LAC) describes how admission control (AC) can=20 be done on a single link and comprises, e.g., the calculation of=20 effective bandwidths which may be the base for a parameter-based AC.=20 In contrast, network AC (NAC) describes how AC can be done for a=20 network and focuses on the locations from which data is gathered for=20 the admission decision. Most approaches implement a link budget based=20 NAC (LB NAC) where each link has a certain AC-budget. RSVP works=20 according to that principle, but also the new concept admits=20 additional flows as long as each link on the new flow's path still=20 has resources available. The border-to-border budget based NAC (BBB=20 NAC) pre-configures an AC budget for all border-to-border=20 relationships (=3D CL-region-aggregates) and if this capacity budget i= s=20 =20 =20 Briscoe Expires April 25, 2007 [Page 48]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 exhausted, new flows are rejected. The TCA-based admission control=20 which is associated with the DiffServ architecture implements an=20 ingress budget based NAC (IB NAC). These basically different concepts=20 have different flexibility and efficiency with regard to the use of=20 link bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing=20 the budgets in such a way that the network will not be congested=20 after rerouting due to a failure. The efficiency of the approaches is=20 different with and without such resilient requirements.=20 =20 7. Security Considerations=20 To protect against denial of service attacks, the ingress gateway of=20 the CL-region needs to police all CL packets and drop packets in=20 excess of the reservation. This is similar to operations with=20 existing IntServ behaviour.=20 For pre-emption, it is considered acceptable from a security=20 perspective that the ingress gateway can treat "emergency/military"=20 CL flows preferentially compared with "ordinary" CL flows. However,=20 in the rest of the CL-region they are not distinguished (nonetheless,=20 our proposed technique does not preclude the use of different DSCPs=20 at the packet level as well as different priorities at the flow=20 level.). Keeping emergency traffic indistinguishable at the packet=20 level minimises the opportunity for new security attacks. For=20 example, if instead a mechanism used different DSCPs for=20 "emergency/military" and "ordinary" packets, then an attacker could=20 specifically target the former in the data plane (perhaps for DoS or=20 for eavesdropping).=20 Further security aspects to be considered later. =20 =20 8. Acknowledgements=20 The admission control mechanism evolved from the work led by Martin=20 Karsten on the Guaranteed Stream Provider developed in the M3I=20 project [GSPa, GSP-TR], which in turn was based on the theoretical=20 work of Gibbens and Kelly [DCAC]. Kennedy Cheng, Gabriele Corliano,=20 Carla Di Cairano-Gilfedder, Kashaf Khan, Peter Hovell, Arnaud Jacquet=20 and June Tay (BT) helped develop and evaluate this approach.=20 Many thanks to those who have commented on this work at Transport=20 Area Working Group meetings and on the mailing list, including: Ken=20 =20 =20 Briscoe Expires April 25, 2007 [Page 49]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Carlberg, Ruediger Geib, Lars Westberg, David Black, Robert Hancock,=20 Cornelia Kappler, Michael Menth.=20 9. Comments solicited=20 Comments and questions are encouraged and very welcome. They can be=20 sent to the Transport Area Working Group's mailing list,=20 tsvwg@ietf.org, and/or to the authors.=20 =20 10. Changes from earlier versions of the draft=20 The main changes are:=20 From -00 to -01 =20 The whole of the Pre-emption mechanism is added.=20 There are several modifications to the admission control mechanism.=20 =20 From -01 to -02=20 The pre-congestion notification algorithms for admission marking and=20 pre-emption marking are now described in [PCN].=20 There are new sub-sections in Section 4 on Failures, Admission of=20 'emergency / higher precedence' session, and Tunnelling; and a new=20 sub-section in Section 5 on Mechanisms to deal with 'Flash crowds'.=20 =20 From -02 to -03=20 Section 5 has been updated and expanded. It is now about the=20 'limitations' of the PCN mechanism, as described in the earlier=20 sections, plus discussion of 'possible solutions' to those=20 limitations. =20 The measurement of the Congestion-Level-Estimate now includes pre- emption marked packets as well as admission marked ones. Section=20 3.1.2 explains. =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 50]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 From -03 to -04=20 Detailed review by Michael Menth. In response, Abstract, Summary and=20 Key benefits sections re-written. Numerous detailed comments on=20 Sections 5 and following sections. =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 51]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 =20 11. Appendices=20 11.1. Appendix A: Explicit Congestion Notification=20 This Appendix provides a brief summary of Explicit Congestion=20 Notification (ECN).=20 [RFC3168] specifies the incorporation of ECN to TCP and IP, including=20 ECN's use of two bits in the IP header. It specifies a method for=20 indicating incipient congestion to end-hosts (e.g. as in RED, Random=20 Early Detection), where the notification is through ECN marking=20 packets rather than dropping them. =20 ECN uses two bits in the IP header of both IPv4 and IPv6 packets:=20 0 1 2 3 4 5 6 7=20 +-----+-----+-----+-----+-----+-----+-----+-----+=20 | DS FIELD, DSCP | ECN FIELD |=20 +-----+-----+-----+-----+-----+-----+-----+-----+=20 =20 DSCP: differentiated services codepoint=20 ECN: Explicit Congestion Notification=20 =20 Figure A.1: The Differentiated Services and ECN Fields in IP.=20 The two bits of the ECN field have four ECN codepoints, '00' to '11':=20 +-----+-----+=20 | ECN FIELD |=20 +-----+-----+=20 ECT CE =20 0 0 Not-ECT=20 0 1 ECT(1)=20 1 0 ECT(0)=20 1 1 CE=20 =20 Figure A.2: The ECN Field in IP.=20 The not-ECT codepoint '00' indicates a packet that is not using ECN.=20 The CE codepoint '11' is set by a router to indicate congestion to=20 the end hosts. The term 'CE packet' denotes a packet that has the CE=20 codepoint set. =20 The ECN-Capable Transport (ECT) codepoints '10' and '01' (ECT(0) and=20 ECT(1) respectively) are set by the data sender to indicate that the=20 =20 =20 Briscoe Expires April 25, 2007 [Page 52]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 end-points of the transport protocol are ECN-capable. Routers treat=20 the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to=20 use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a=20 packet-by-packet basis. The motivation for having two codepoints (the=20 'ECN nonce') is the desire to check two things: for the data sender=20 to verify that network elements are not erasing the CE codepoint; and=20 for the data sender to verify that data receivers are properly=20 reporting to the sender the receipt of packets with the CE codepoint=20 set.=20 ECN requires support from the transport protocol, in addition to the=20 functionality given by the ECN field in the IP packet header.=20 [RFC3168] addresses the addition of ECN Capability to TCP, specifying=20 three new pieces of functionality: negotiation between the endpoints=20 during connection setup to determine if they are both ECN-capable; an=20 ECN-Echo (ECE) flag in the TCP header so that the data receiver can=20 inform the data sender when a CE packet has been received; and a=20 Congestion Window Reduced (CWR) flag in the TCP header so that the=20 data sender can inform the data receiver that the congestion window=20 has been reduced.=20 The transport layer (e.g.. TCP) must respond, in terms of congestion=20 control, to a *single* CE packet as it would to a packet drop. =20 The advantage of setting the CE codepoint as an indication of=20 congestion, instead of relying on packet drops, is that it allows the=20 receiver(s) to receive the packet, thus avoiding the potential for=20 excessive delays due to retransmissions after packet losses. =20 =20 11.2. Appendix B: What is distributed measurement-based admission=20 control? =20 This Appendix briefly explains what distributed measurement-based=20 admission control is [Breslau99]. =20 Traditional admission control algorithms for 'hard' real-time=20 services (those providing a firm delay bound for example) guarantee=20 QoS by using 'worst case analysis'. Each time a flow is admitted its=20 traffic parameters are examined and the network re-calculates the=20 remaining resources. When the network gets a new request it therefore=20 knows for certain whether the prospective flow, with its particular=20 parameters, should be admitted. However, parameter-based admission=20 control algorithms result in under-utilisation when the traffic is=20 bursty. Therefore 'soft' real time services - like Controlled Load -=20 can use a more relaxed admission control algorithm. =20 =20 =20 Briscoe Expires April 25, 2007 [Page 53]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 This insight suggests measurement-based admission control (MBAC). The=20 aim of MBAC is to provide a statistical service guarantee. The=20 classic scenario for MBAC is where each router participates in hop- by-hop admission control, characterising existing traffic locally=20 through measurements (instead of keeping an accurate track of traffic=20 as it is admitted), in order to determine the current value of some=20 parameter e.g. load. Note that for scalability the measurement is of=20 the aggregate of the flows in the local system. The measured=20 parameter(s) is then compared to the requirements of the prospective=20 flow to see whether it should be admitted. =20 MBAC may also be performed centrally for a network, it which case it=20 uses centralised measurements by a bandwidth broker. =20 We use distributed MBAC. "Distributed" means that the measurement is=20 accumulated for the 'whole-path' using in-band signalling. In our=20 case, this means that the measurement of existing traffic is for the=20 same pair of ingress and egress gateways as the prospective=20 microflow. =20 In fact our mechanism can be said to be distributed in three ways:=20 all routers on the ingress-egress path affect the Congestion-Level- Estimate; the admission control decision is made just once on behalf=20 of all the routers on the path across the CL-region; and the ingress=20 and egress gateways cooperate to perform MBAC. =20 =20 11.3. Appendix C: Calculating the Exponentially weighted moving average=20 (EWMA)=20 At the egress gateway, for every CL packet arrival:=20 [EWMA-total-bits]n+1 =3D (w * bits-in-packet) + ((1-w) * [EWMA-=20 total-bits]n )=20 [EWMA-M-bits]n+1 =3D (B * w * bits-in-packet) + ((1-w) * [EWMA-M- bits]n )=20 Then, per new flow arrival:=20 [Congestion-Level-Estimate]n+1 =3D [EWMA-M-bits]n+1 / [EWMA-total- bits]n+1 =20 =20 where=20 =20 =20 Briscoe Expires April 25, 2007 [Page 54]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 EWMA-total-bits is the total number of bits in CL packets, calculated=20 as an exponentially weighted moving average (EWMA)=20 EWMA-M-bits is the total number of bits in CL packets that are=20 Admission Marked or Pre-emption Marked, again calculated as an EWMA. =20 B is either 0 or 1:=20 B =3D 0 if the CL packet is not admission marked =20 B =3D 1 if the CL packet is admission marked=20 w is the exponential weighting factor. =20 =20 Varying the value of the weight trades off between the smoothness and=20 responsiveness of the Congestion-Level-Estimate. However, in general=20 both can be achieved, given our original assumption of many CL=20 microflows and remembering that the EWMA is calculated on the basis=20 of aggregate traffic between the ingress and egress gateways. =20 There will be a threshold inter-arrival time between packets of the=20 same aggregate below which the egress will consider the estimate of=20 the Congestion-Level-Estimate as too stale, and it will then trigger=20 generation of probes by the ingress. =20 =20 The first two per-packet algorithms can be simplified, if their only=20 use will be where the result of one is divided by the result of the=20 other in the third, per-flow algorithm.=20 =20 [EWMA-total-bits]'n+1 =3D bits-in-packet + (w' * [EWMA- total- bits]n )=20 [EWMA-AM-bits]'n+1 =3D (B * bits-in-packet) + (w' * [EWMA-AM-bits]= n=20 )=20 where w' =3D (1-w)/w.=20 If w' is arranged to be a power of 2, these per packet algorithms can=20 be implemented solely with a shift and an add.=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 55]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 There are alternative possibilities for smoothing out the congestion- level-estimate. For example [TEWMA] deals better with the issue of=20 stale information when the traffic rate for =20 =20 =20 12. References=20 A later version will distinguish normative and informative=20 references.=20 [AGGRE-TE] Francois Le Faucheur, Michael Dibiasio, Bruce Davie,=20 Michael Davenport, Chris Christou, Jerry Ash, Bur=20 Goode, 'Aggregation of RSVP Reservations over MPLS=20 TE/DS-TE Tunnels', draft-ietf-tsvwg-rsvp-dste-03 (work=20 in progress), June 2006 =20 [ANSI.MLPP.Spec] American National Standards Institute,=20 "Telecommunications- Integrated Services Digital=20 Network (ISDN) - Multi-Level Precedence and Pre- emption (MLPP) Service Capability", ANSI T1.619-1992=20 (R1999), 1992.=20 [ANSI.MLPP.Supplement] American National Standards Institute, "MLPP=20 Service Domain Cause Value Changes", ANSI ANSI=20 T1.619a-1994 (R1999), 1990.=20 [AVQ] S. Kunniyur and R. Srikant "Analysis and Design of an=20 Adaptive Virtual Queue (AVQ) Algorithm for Active=20 Queue Management", In: Proc. ACM SIGCOMM'01, Computer=20 Communication Review 31 (4) (October, 2001).=20 [Breslau99] L. Breslau, S. Jamin, S. Shenker "Measurement-based=20 admission control: what is the research agenda?", In:=20 Proc. Int'l Workshop on Quality of Service 1999.=20 [Breslau00] L. Breslau, E. Knightly, S. Shenker, I. Stoica, H.=20 Zhang "Endpoint Admission Control: Architectural=20 Issues and Performance", In: ACM SIGCOMM 2000 =20 [Briscoe] Bob Briscoe and Steve Rudkin, "Commercial Models for=20 IP Quality of Service Interconnect", BT Technology=20 Journal, Vol 23 No 2, April 2005.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 56]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 [DCAC] Richard J. Gibbens and Frank P. Kelly "Distributed=20 connection acceptance control for a connectionless=20 network", In: Proc. International Teletraffic Congress=20 (ITC16), Edinburgh, pp. 941=97952 (1999).=20 [ECN-MPLS] Bruce Davie, Bob Briscoe, June Tay, "Explicit=20 Congestion Marking in MPLS", draft- davie-ecn-mpls-00.txt (work in progress), June 2006=20 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements=20 for Emergency Telecommunication Service (ETS)", RFC=20 3689, February 2004.=20 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony=20 Requirements for Emergency Telecommunication Service=20 (ETS)", RFC 3690, February 2004.=20 [Floyd] S. Floyd, 'Specifying Alternate Semantics for the=20 Explicit Congestion Notification (ECN) Field', draft- floyd-ecn-alternates-02.txt (work in progress), August=20 2005 =20 [GSPa] Karsten (Ed.), Martin "GSP/ECN Technology &=20 Experiments", Deliverable: 15.3 PtIII, M3I Eu Vth=20 Framework Project IST-1999-11429, URL:=20 http://www.m3i.org/ (February, 2002) (superseded by=20 [GSP-TR])=20 [GSP-TR] Martin Karsten and Jens Schmitt, "Admission Control=20 Based on Packet Marking and Feedback Signalling =AD--=20 Mechanisms, Implementation and Experiments", TU- Darmstadt Technical Report TR-KOM-2002-03, URL:=20 http://www.kom.e-technik.tu- darmstadt.de/publications/abstracts/KS02-5.html (May,=20 2002) =20 [ITU.MLPP.1990] International Telecommunications Union, "Multilevel=20 Precedence and Pre-emption Service (MLPP)", ITU-T=20 Recommendation I.255.3, 1990. =20 [Johnson] DM Johnson, 'QoS control versus generous=20 dimensioning', BT Technology Journal, Vol 23 No 2,=20 April 2005=20 =20 =20 Briscoe Expires April 25, 2007 [Page 57]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 [LoadBalancing-a] Ruediger Martin, Michael Menth, and Michael=20 Hemmkeppler: "Accuracy and Dynamics of Hash-Based Load=20 Balancing Algorithms for Multipath Internet Routing",=20 IEEE Broadnets, San Jose, CA, USA, October 2006=20 http://www3.informatik.uni- wuerzburg.de/~menth/Publications/Menth06p.pdf=20 [LoadBalancing-b] Ruediger Martin, Michael Menth, and Michael=20 Hemmkeppler: "Accuracy and Dynamics of Multi-Stage=20 Load Balancing for Multipath Internet Routing",=20 currently under submission http://www3.informatik.uni- wuerzburg.de/~menth/Publications/Menth07-Sub-6.pdf =20 [Low] S. Low, L. Andrew, B. Wydrowski, 'Understanding XCP:=20 equilibrium and fairness', IEEE InfoCom 2005=20 [NAC-a] Michael Menth: "Efficient Admission Control and=20 Routing in Resilient Communication Networks", PhD=20 thesis, July 2004, http://opus.bibliothek.uni- wuerzburg.de/opus/volltexte/2004/994/pdf/Menth04.pdf=20 [NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and=20 Karl Schrodi: "Resilient Network Admission Control",=20 currently under submission.=20 http://www3.informatik.uni- wuerzburg.de/~menth/Publications/Menth07-Sub-3.pdf =20 [PCN] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur,=20 A. Charny, V. Liatsos, S. Dudley, J. Babiarz, K. Chan,=20 G. Karagiannis, A. Bader, L. Westberg. 'Pre-Congestion=20 Notification marking', draft-briscoe-tsvwg-cl-phb-02=20 (work in progress), June 2006.=20 [Re-ECN] Bob Briscoe, Arnaud Jacquet, Alessandro Salvatori,=20 'Re-ECN: Adding Accountability for Causing Congestion=20 to TCP/IP', draft-briscoe-tsvwg-re-ecn-tcp-01 (work in=20 progress), March 2006.=20 [Re-feedback] Bob Briscoe, Arnaud Jacquet, Carla Di Cairano- Gilfedder, Andrea Soppera, 'Re-feedback for Policing=20 Congestion Response in an Inter-network', ACM SIGCOMM=20 2005, August 2005.=20 [Re-PCN] B. Briscoe, 'Emulating Border Flow Policing using Re- ECN on Bulk Data', draft-briscoe-tsvwg-re-ecn-border- cheat-00 (work in progress), February 2006.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 58]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 [Reid] ABD Reid, 'Economics and scalability of QoS=20 solutions', BT Technology Journal, Vol 23 No 2, April=20 2005=20 [RFC2211] J. Wroclawski, Specification of the Controlled-Load=20 Network Element Service, September 1997=20 [RFC2309] Braden, B., et al., "Recommendations on Queue=20 Management and Congestion Avoidance in the Internet",=20 RFC 2309, April 1998.=20 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,=20 "Definition of the Differentiated Services Field (DS=20 Field) in the IPv4 and IPv6 Headers", RFC 2474,=20 December 1998=20 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,=20 Z. and W. Weiss, 'A framework for Differentiated=20 Services', RFC 2475, December 1998.=20 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski,=20 "Assured Forwarding PHB Group", RFC 2597, June 1999.=20 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang,=20 L., Speer, M., Braden, R., Davie, B., Wroclawski, J.=20 and E. Felstaine, "A Framework for Integrated Services=20 Operation Over DiffServ Networks", RFC 2998, November=20 2000.=20 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black "The Addition=20 of Explicit Congestion Notification (ECN) to IP", RFC=20 3168, September 2001.=20 [RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le=20 Boudec, W. Courtney, S. Davari, V. Firoiu, D.=20 Stiliadis, 'An Expedited Forwarding PHB (Per-Hop=20 Behavior)', RFC 3246, March 2002.=20 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,=20 Vaananen, P., Krishnan, R., Cheval, P., and J.=20 Heinanen, "Multi- Protocol Label Switching (MPLS)=20 Support of Differentiated Services", RFC 3270, May=20 2002.=20 [RFC4542] F. Baker & J. Polk, "Implementing an Emergency=20 Telecommunications Service for Real Time Services in=20 the Internet Protocol Suite", RFC 4542, May 2006.=20 =20 =20 Briscoe Expires April 25, 2007 [Page 59]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 [RMD] Attila Bader, Lars Westberg, Georgios Karagiannis,=20 Cornelia Kappler, Tom Phelan, 'RMD-QOSM - The Resource=20 Management in DiffServ QoS model', draft-ietf-nsis- rmd-03 Work in Progress, June 2005.=20 [RSVP-PCN] Francois Le Faucheur, Anna Charny, Bob Briscoe, Philip=20 Eardley, Joe Barbiaz, Kwok-Ho Chan, 'RSVP Extensions=20 for Admission Control over DiffServ using Pre- Congestion Notification (PCN)', draft-lefaucheur-rsvp- ecn-01 (work in progress), June 2006.=20 [RSVP-PREEMPTION] Herzog, S., "Signaled Preemption Priority Policy=20 Element", RFC 3181, October 2001. =20 [RSVP-EMERGENCY] Le Faucheur et al., RSVP Extensions for Emergency=20 Services, draft-lefaucheur-emergency-rsvp-02.txt=20 [RTECN] Babiarz, J., Chan, K. and V. Firoiu, 'Congestion=20 Notification Process for Real-Time Traffic', draft- babiarz-tsvwg-rtecn-04 Work in Progress, July 2005.=20 [RTECN-usage] Alexander, C., Ed., Babiarz, J. and J. Matthews,=20 'Admission Control Use Case for Real-time ECN', draft- alexander-rtecn-admission-control-use-case-00, Work in=20 Progress, February 2005.=20 [Songhurst] David J. Songhurst, Philip Eardley, Bob Briscoe, Carla=20 Di Cairano Gilfedder and June Tay, 'Guaranteed QoS=20 Synthesis for Admission Control with Shared Capacity',=20 BT Technical Report TR-CXR9-2006-001, Feb 2006,=20 http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/ipe2e qos/gqs/papers/GQS_shared_tr.pdf =20 [vq] Costas Courcoubetis and Richard Weber "Buffer Overflow=20 Asymptotics for a Switch Handling Many Traffic=20 Sources" In: Journal Applied Probability 33 pp. 886-- 903 (1996).=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 60]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Authors' Addresses=20 Bob Briscoe=20 BT Research=20 B54/77, Sirius House=20 Adastral Park=20 Martlesham Heath=20 Ipswich, Suffolk=20 IP5 3RE=20 United Kingdom=20 Email: bob.briscoe@bt.com=20 =20 Dave Songhurst=20 BT Research=20 B54/69, Sirius House=20 Adastral Park=20 Martlesham Heath=20 Ipswich, Suffolk=20 IP5 3RE=20 United Kingdom=20 Email: dsonghurst@jungle.bt.co.uk=20 =20 Philip Eardley=20 BT Research=20 B54/77, Sirius House=20 Adastral Park=20 Martlesham Heath=20 Ipswich, Suffolk=20 IP5 3RE=20 United Kingdom=20 Email: philip.eardley@bt.com=20 =20 Francois Le Faucheur =20 Cisco Systems, Inc. =20 Village d'Entreprise Green Side - Batiment T3 =20 400, Avenue de Roumanille =20 06410 Biot Sophia-Antipolis =20 France =20 Email: flefauch@cisco.com =20 =20 Anna Charny =20 Cisco Systems =20 300 Apollo Drive =20 Chelmsford, MA 01824 =20 USA =20 Email: acharny@cisco.com =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 61]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Kwok Ho Chan =20 Nortel Networks =20 600 Technology Park Drive =20 Billerica, MA 01821 =20 USA =20 Email: khchan@nortel.com =20 =20 Jozef Z. Babiarz =20 Nortel Networks =20 3500 Carling Avenue =20 Ottawa, Ont K2H 8E9 =20 Canada =20 Email: babiarz@nortel.com=20 =20 Stephen Dudley=20 Nortel Networks=20 4001 E. Chapel Hill Nelson Highway=20 P.O. Box 13010, ms 570-01-0V8=20 Research Triangle Park, NC 27709=20 USA=20 Email: smdudley@nortel.com=20 =20 Georgios Karagiannis=20 University of Twente=20 P.O. BOX 217=20 7500 AE Enschede, =20 The Netherlands=20 EMail: g.karagiannis@ewi.utwente.nl =20 =20 Attila B=E1der =20 attila.bader@ericsson.com=20 =20 Lars Westberg=20 Ericsson AB=20 SE-164 80 Stockholm=20 Sweden=20 EMail: Lars.Westberg@ericsson.com=20 =20 =20 =20 =20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 62]=20 =0C Internet-Draft Deployment Model using PCN October 2006=20 =20 Intellectual Property Statement=20 The IETF takes no position regarding the validity or scope of any=20 Intellectual Property Rights or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; nor does it represent that it has=20 made any independent effort to identify any such rights. Information=20 on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of=20 such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository at=20 http://www.ietf.org/ipr.=20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at=20 ietf-ipr@ietf.org=20 Disclaimer of Validity=20 This document and the information contained herein are provided on an=20 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=20 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 Copyright Statement=20 Copyright (C) The Internet Society (2006).=20 This document is subject to the rights, licenses and restrictions=20 contained in BCP 78, and except as set forth therein, the authors=20 retain all their rights.=20 =20 =20 =20 Briscoe Expires April 25, 2007 [Page 63]=20 =0C --------------020902000404080405070302 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn --------------020902000404080405070302-- From pcn-bounces@ietf.org Wed Oct 25 17:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqmf-000712-81; Wed, 25 Oct 2006 17:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqVI-00055J-Q9 for pcn@ietf.org; Wed, 25 Oct 2006 17:41:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcqQg-00021k-8S for pcn@ietf.org; Wed, 25 Oct 2006 17:36:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2006 14:36:54 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PLasjG017181; Wed, 25 Oct 2006 17:36:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9PLarDM015463; Wed, 25 Oct 2006 17:36:53 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 17:36:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Date: Wed, 25 Oct 2006 17:36:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Thread-Index: Acb4FQ+xm9DnKE1tTnq3btv9NO4WoQAZ68Wg From: "Anna Charny \(acharny\)" To: , "Kwok-Ho Chan" X-OriginalArrivalTime: 25 Oct 2006 21:36:53.0501 (UTC) FILETIME=[B00EFAD0:01C6F87D] DKIM-Signature: a=rsa-sha1; q=dns; l=5590; t=1161812214; x=1162676214; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Re=3A=20draft-chan-pcn-problem-statement-01.txt=20submis sion |To:, =20=22Kwok-Ho=20Chan=22=20; X=v=3Dcisco.com=3B=20h=3DXQLAuBTSPI5fQew8mYWUiOZ+v+I=3D; b=n+iERZkUU7StDWYMlz0v2u4/i+dooOpX6bcVAHIYExjROuH1wL66Spe1KVO4zorPjsAaj/k/ 83krMA/DtCAlV1a3IayZ8HK1Efm+pRVKJG1P/1m51NX7WWZIoIDsTQc1; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, I do agree with your observation that if smooth traffic consistently exceeds the admission threshold, then all traffic soon starts getting admission-marked, and hence further admission is prevented. Strictly speaking that does not contradict the statement that in that case PCN fails to prevent admission *prior* to reaching the admission threshold. But indeed, as admission control is expected to be substantially below the link speed (or real queue service rate), that is not in practice a serious problem, in my opinion. Perhaps the next version of the draft could elaborate on this a bit more.=20 Anna=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Wednesday, October 25, 2006 5:05 AM To: Kwok-Ho Chan Cc: pcn@ietf.org Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Hi all, I browsed through the drafts and have some comments on Section 5 "Aggregate Traffic Characteristics" which says: "However, too little [traffic] variation can also be a problem [for the PCN marking]. For example, if all the sources are constant bit rate and are synchronised, then the total traffic level at a router's interface could be (almost) at its capacity and all packets could still be serviced instantly. However, admitting one more flow could tip the router over its capacity, so its queue grew indefinitely until it had to drop packets. "Some" traffic variation means that as the traffic level nears the capacity limit, some packets are PCN-marked but there's still enough capacity to cope with the traffic fluctuations. Hence new flows can be blocked and packets are never dropped." With PCN, all packets are "stop admission marked" if the currently observed rate exceeds the configured "admissible interface rate". The configured "admissible interface rate" is usually substantially smaller than the physical link bandwidth. In the context of RED marking, only those packets are marked that exceed a certain threshold of the physical queue which is served at link rate.=20 If the traffic exceeds the link rate preliminarily on a small time scale, a queue builds up and some of the queued packets are marked. This can also happen if the aggregate rate is low, but if bursts arrive. In contrast, if the rate of the aggregate reaches almost the link bandwidth, but if it is sufficiently smooth, no queue builds up. Thus, the problem with RED-like marking is that it can give EARLY warning only if the current traffic rate is below the link rate but exceeds it due to short term variations. From my perspective, PCN marking does not have this problem because it reacts if the sent rate exceeds the configured rate and that can be well observed on a larger time scale than packet level, short term variations are not required to this end. Therefore, PCN marking leads to more stable results than RED marking and it does not need to give a warning if the configured "admissible interface rate" is not achieved on a medium time scale (~1s). Therefore, early warning can be perfectly done also for extremely smooth CBR traffic. Best wishes, Michael Kwok-Ho Chan wrote: > Hi: > Please notice I have submitted an update to the Problem-Statement draft. > Please see the link to the draft at: > =20 > http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.tx > t > > There were couple of minor cleanups. > I have also added a new section just to set up the discussion of=20 > trust, with the trust assumptions and security still in the=20 > assumptions and security sections (as they were in -00). > Thanks! > -- Kwok -- > > > At 03:04 AM 10/23/2006, you wrote: >> This is the submission of an update (version 01) to an individual draft. >> >> Title: Pre-Congestion Notification Problem Statement >> >> Filename: draft-chan-pcn-problem-statement-01.txt >> >> Abstract: >> DiffServ mechanisms have been developed to support Quality of Service >> (QoS). However, the level of assurance that can be provided with >> DiffServ without substantial over-provisioning is limited. Pre- >> Congestion Notification (PCN) investigates the use of per-flow >> admission control to provide the required service guarantees for the >> admitted traffic. While admission control will protect the QoS under >> normal operating conditions, an additional flow pre-emption mechanism >> is necessary in the times of heavy congestion (e.g. caused by route >> changes due to link or node failure). >> >> This document provides a problem statement on the addition of flow >> admission control and flow pre-emption functionality to a DiffServ >> network, in particular for the support of real time services such as >> voice and video. >> >> >> If there is any question or problem related to this submission,=20 >> please contact: >> Kwok Ho Chan >> E-Mail: khchan@nortel.com >> Phone: 978-288-8175 >> >> The text version of the draft is attached. >> >> Thank You! >> -- Kwok -- >> >> >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn -- 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 From pcn-bounces@ietf.org Thu Oct 26 09:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5jX-0002CY-Ej; Thu, 26 Oct 2006 09:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5jW-0002CT-8K for pcn@ietf.org; Thu, 26 Oct 2006 09:57:22 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5jT-0007eE-Q1 for pcn@ietf.org; Thu, 26 Oct 2006 09:57:22 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9QDvG721013; Thu, 26 Oct 2006 09:57:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Date: Thu, 26 Oct 2006 09:57:01 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB64650CD496A5@zcarhxm1.corp.nortel.com> In-Reply-To: <453F28B5.2090109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Thread-Index: Acb4FROSi0v7fJejQC+aU8dT1iNMOAA7MHkA From: "Jozef Babiarz" To: , "Kwok-Ho Chan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, good observations. Not sure if I understand your last point " Therefore, PCN marking leads to more=20 stable results than RED marking and it does not need to give a warning=20 if the configured "admissible interface rate" is not achieved on a=20 medium time scale (~1s). Therefore, early warning can be perfectly done=20 also for extremely smooth CBR traffic." But at least in my view stop admission marking needs to respond frailly quickly to increased traffic load to provide protection against flash calling events (may users making call at the same time). In my view, reaction to stop admission marking should be proportional to traffic that is in excess of "admissible interface rate", that is if traffic is above by a small amount, it is OK for stop admissible marking to take medium time scale. However, if traffic exceeds the admissible rate by large amount then stop marking needs to be quick. =20 Regards, Joe QoS & Network Architecture Telephone: 613-763-6098 (ESN 393-6098) Email: babiarz@nortel.com -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Wednesday, October 25, 2006 5:05 AM To: Chan, Kwok-Ho (BL60:470) Cc: pcn@ietf.org Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Hi all, I browsed through the drafts and have some comments on Section 5=20 "Aggregate Traffic Characteristics" which says: "However, too little [traffic] variation can also be a problem [for the=20 PCN marking]. For example, if all the sources are constant bit rate and=20 are synchronised, then the total traffic level at a router's interface=20 could be (almost) at its capacity and all packets could still be=20 serviced instantly. However, admitting one more flow could tip the=20 router over its capacity, so its queue grew indefinitely until it had to drop packets. "Some" traffic variation means that as the traffic level=20 nears the capacity limit, some packets are PCN-marked but there's still=20 enough capacity to cope with the traffic fluctuations. Hence new flows=20 can be blocked and packets are never dropped." With PCN, all packets are "stop admission marked" if the currently=20 observed rate exceeds the configured "admissible interface rate". The=20 configured "admissible interface rate" is usually substantially smaller=20 than the physical link bandwidth. In the context of RED marking, only those packets are marked that exceed a certain threshold of the physical queue which is served at link rate.=20 If the traffic exceeds the link rate preliminarily on a small time=20 scale, a queue builds up and some of the queued packets are marked. This can also happen if the aggregate rate is low, but if bursts arrive. In=20 contrast, if the rate of the aggregate reaches almost the link=20 bandwidth, but if it is sufficiently smooth, no queue builds up. Thus,=20 the problem with RED-like marking is that it can give EARLY warning only if the current traffic rate is below the link rate but exceeds it due to short term variations. From my perspective, PCN marking does not have this problem because it=20 reacts if the sent rate exceeds the configured rate and that can be well observed on a larger time scale than packet level, short term variations are not required to this end. Therefore, PCN marking leads to more=20 stable results than RED marking and it does not need to give a warning=20 if the configured "admissible interface rate" is not achieved on a=20 medium time scale (~1s). Therefore, early warning can be perfectly done=20 also for extremely smooth CBR traffic. Best wishes, Michael Kwok-Ho Chan wrote: > Hi: > Please notice I have submitted an update to the Problem-Statement draft. > Please see the link to the draft at: > http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.txt > > There were couple of minor cleanups. > I have also added a new section just to set up the discussion of trust, > with the trust assumptions and security still in the assumptions and > security sections (as they were in -00). > Thanks! > -- Kwok -- > > > At 03:04 AM 10/23/2006, you wrote: >> This is the submission of an update (version 01) to an individual draft. >> >> Title: Pre-Congestion Notification Problem Statement >> >> Filename: draft-chan-pcn-problem-statement-01.txt >> >> Abstract: >> DiffServ mechanisms have been developed to support Quality of Service >> (QoS). However, the level of assurance that can be provided with >> DiffServ without substantial over-provisioning is limited. Pre- >> Congestion Notification (PCN) investigates the use of per-flow >> admission control to provide the required service guarantees for the >> admitted traffic. While admission control will protect the QoS under >> normal operating conditions, an additional flow pre-emption mechanism >> is necessary in the times of heavy congestion (e.g. caused by route >> changes due to link or node failure). >> >> This document provides a problem statement on the addition of flow >> admission control and flow pre-emption functionality to a DiffServ >> network, in particular for the support of real time services such as >> voice and video. >> >> >> If there is any question or problem related to this submission, >> please contact: >> Kwok Ho Chan >> E-Mail: khchan@nortel.com >> Phone: 978-288-8175 >> >> The text version of the draft is attached. >> >> Thank You! >> -- Kwok -- >> >> >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn --=20 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 From pcn-bounces@ietf.org Fri Oct 27 06:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdOWU-0006CR-Hf; Fri, 27 Oct 2006 06:01:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdOWS-0006CL-7w for pcn@ietf.org; Fri, 27 Oct 2006 06:01:08 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdOWK-00079G-Hr for pcn@ietf.org; Fri, 27 Oct 2006 06:01:08 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:00:59 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 11:00:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Date: Fri, 27 Oct 2006 11:00:55 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CDC7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Thread-Index: Acb4FQ+xm9DnKE1tTnq3btv9NO4WoQAZ68WgAEx5/0A= From: To: , , X-OriginalArrivalTime: 27 Oct 2006 10:00:57.0419 (UTC) FILETIME=[CC5201B0:01C6F9AE] X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Agree with your comments. With very smooth traffic, indeed adding 'one more flow' can move the router from marking no packets to marking all of them.=20 With bursty traffic, we see an increasing % of pkts being marked (on average) as the traffic level is increased.=20 Hence with bursty traffic you start to get pkt marks (warnings of potential congestion) at lower average traffic level. This behaviour is good, as bursty traffic has a greater danger of causing some pkt delay/drop in the real queue.=20 If traffic was always smooth, rather than use a virtual queue the router could just measure the traffic rate (on some kind of moving average). It would work just as well. However, if the traffic is bursty, using a virtual queue is better. Because it gives a better measure (than average rate) of what might happen on the real queue 'soon' (ie if the traffic increased further).=20 Effectively the virtual queue gives you another parameter to play with - as well as the average rate, the virtual queue threshold (ie length at which go from no marking to marking). This allows you to control how sensitive you are to bursty traffic.=20 Thanks Phil Eardley=20 Ben Strulo -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: 25 October 2006 22:37 To: menth@informatik.uni-wuerzburg.de; Kwok-Ho Chan Cc: pcn@ietf.org Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Hi Michael, I do agree with your observation that if smooth traffic consistently exceeds the admission threshold, then all traffic soon starts getting admission-marked, and hence further admission is prevented. Strictly speaking that does not contradict the statement that in that case PCN fails to prevent admission *prior* to reaching the admission threshold. But indeed, as admission control is expected to be substantially below the link speed (or real queue service rate), that is not in practice a serious problem, in my opinion. Perhaps the next version of the draft could elaborate on this a bit more.=20 Anna=20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Wednesday, October 25, 2006 5:05 AM To: Kwok-Ho Chan Cc: pcn@ietf.org Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission Hi all, I browsed through the drafts and have some comments on Section 5 "Aggregate Traffic Characteristics" which says: "However, too little [traffic] variation can also be a problem [for the PCN marking]. For example, if all the sources are constant bit rate and are synchronised, then the total traffic level at a router's interface could be (almost) at its capacity and all packets could still be serviced instantly. However, admitting one more flow could tip the router over its capacity, so its queue grew indefinitely until it had to drop packets. "Some" traffic variation means that as the traffic level nears the capacity limit, some packets are PCN-marked but there's still enough capacity to cope with the traffic fluctuations. Hence new flows can be blocked and packets are never dropped." With PCN, all packets are "stop admission marked" if the currently observed rate exceeds the configured "admissible interface rate". The configured "admissible interface rate" is usually substantially smaller than the physical link bandwidth. In the context of RED marking, only those packets are marked that exceed a certain threshold of the physical queue which is served at link rate.=20 If the traffic exceeds the link rate preliminarily on a small time scale, a queue builds up and some of the queued packets are marked. This can also happen if the aggregate rate is low, but if bursts arrive. In contrast, if the rate of the aggregate reaches almost the link bandwidth, but if it is sufficiently smooth, no queue builds up. Thus, the problem with RED-like marking is that it can give EARLY warning only if the current traffic rate is below the link rate but exceeds it due to short term variations. From my perspective, PCN marking does not have this problem because it reacts if the sent rate exceeds the configured rate and that can be well observed on a larger time scale than packet level, short term variations are not required to this end. Therefore, PCN marking leads to more stable results than RED marking and it does not need to give a warning if the configured "admissible interface rate" is not achieved on a medium time scale (~1s). Therefore, early warning can be perfectly done also for extremely smooth CBR traffic. Best wishes, Michael Kwok-Ho Chan wrote: > Hi: > Please notice I have submitted an update to the Problem-Statement draft. > Please see the link to the draft at: > =20 > http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.tx > t > > There were couple of minor cleanups. > I have also added a new section just to set up the discussion of=20 > trust, with the trust assumptions and security still in the=20 > assumptions and security sections (as they were in -00). > Thanks! > -- Kwok -- > > > At 03:04 AM 10/23/2006, you wrote: >> This is the submission of an update (version 01) to an individual draft. >> >> Title: Pre-Congestion Notification Problem Statement >> >> Filename: draft-chan-pcn-problem-statement-01.txt >> >> Abstract: >> DiffServ mechanisms have been developed to support Quality of Service >> (QoS). However, the level of assurance that can be provided with >> DiffServ without substantial over-provisioning is limited. Pre- >> Congestion Notification (PCN) investigates the use of per-flow >> admission control to provide the required service guarantees for the >> admitted traffic. While admission control will protect the QoS under >> normal operating conditions, an additional flow pre-emption mechanism >> is necessary in the times of heavy congestion (e.g. caused by route >> changes due to link or node failure). >> >> This document provides a problem statement on the addition of flow >> admission control and flow pre-emption functionality to a DiffServ >> network, in particular for the support of real time services such as >> voice and video. >> >> >> If there is any question or problem related to this submission,=20 >> please contact: >> Kwok Ho Chan >> E-Mail: khchan@nortel.com >> Phone: 978-288-8175 >> >> The text version of the draft is attached. >> >> Thank You! >> -- Kwok -- >> >> >> > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn -- 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 27 17:16:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZ4K-0002R4-8u; Fri, 27 Oct 2006 17:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZ4J-0002Qt-Ix for pcn@ietf.org; Fri, 27 Oct 2006 17:16:47 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZ4I-0005FE-63 for pcn@ietf.org; Fri, 27 Oct 2006 17:16:47 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k9RLGhM03248 for ; Fri, 27 Oct 2006 17:16:44 -0400 (EDT) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:16:43 -0400 Message-Id: <6.2.5.6.0.20061027165226.0330fb68@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Oct 2006 17:16:42 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 27 Oct 2006 21:16:43.0205 (UTC) FILETIME=[337DF750:01C6FA0D] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [PCN] Latest PCN Bof Info at http://standards.nortel.com/pcn/ X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi: I have updated http://standards.nortel.com/pcn/ with the latest documents to be discussed during our PCN BoF @ 67th IETF in San Diego, on Monday November 6, 2006, 9 - 11:30 AM in Grande Ballroom C: BoF Agenda (ver 00): http://standards.nortel.com/pcn/PCN_BoF_Agenda_00.txt Proposed PCN Charter (ver 01): http://standards.nortel.com/pcn/PCN_draft_charter_v01.txt PCN Problem Statement (ver 01): http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.txt PCN Marking (ver 03): http://standards.nortel.com/pcn/draft-briscoe-tsvwg-cl-phb-03.txt CL Architecture (ver 04): http://standards.nortel.com/pcn/draft-briscoe-tsvwg-cl-architecture-04.txt SIP Controlled Admission and Preemption (ver 00): http://standards.nortel.com/pcn/draft-babiarz-pcn-sip-cap-00.txt Single Marking for Admission and Preemption (ver 00): http://standards.nortel.com/pcn/draft-charny-pcn-single-marking-00.txt PCN Simulation (ver 00): http://standards.nortel.com/pcn/draft-zhang-pcn-performance-evaluation-00.txt Please note that this is a follow up to Anna's EMail on Tues Oct 24, 2006, just putting all the relevant information at your finger tip for easy access. If you are attending the 67th IETF @ San Diego, please come to the BoF and give us your support. Indication of your support via EMail also welcomed. Thanks! -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 30 13:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geba8-0000Oz-2G; Mon, 30 Oct 2006 13:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geba6-0000Ou-FP for pcn@ietf.org; Mon, 30 Oct 2006 13:09:54 -0500 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 1GebZy-0002qJ-KV for pcn@ietf.org; Mon, 30 Oct 2006 13:09:54 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8AEF81780; Mon, 30 Oct 2006 19:09:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 77F9A1A90; Mon, 30 Oct 2006 19:09:39 +0100 (CET) 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 928011780; Mon, 30 Oct 2006 19:09:38 +0100 (CET) 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 k9UI9cs22101; Mon, 30 Oct 2006 19:09:38 +0100 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 780266F58E; Mon, 30 Oct 2006 19:07:52 +0100 (CET) Message-ID: <45463F60.2030101@informatik.uni-wuerzburg.de> Date: Mon, 30 Oct 2006 19:07:28 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission References: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CDC7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CDC7@E03MVZ1-UKDY.domain1.systemhost.net> 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: a3f7094ccc62748c06b21fcf44c073ee 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Phil, philip.eardley@bt.com wrote: > Agree with your comments. > > With very smooth traffic, indeed adding 'one more flow' can move the > router from marking no packets to marking all of them. > With bursty traffic, we see an increasing % of pkts being marked (on > average) as the traffic level is increased. > Hence with bursty traffic you start to get pkt marks (warnings of > potential congestion) at lower average traffic level. This behaviour is > good, as bursty traffic has a greater danger of causing some pkt > delay/drop in the real queue. > > If traffic was always smooth, rather than use a virtual queue the router > could just measure the traffic rate (on some kind of moving average). It > would work just as well. However, if the traffic is bursty, using a > virtual queue is better. Because it gives a better measure (than average > rate) of what might happen on the real queue 'soon' (ie if the traffic > increased further). > > Effectively the virtual queue gives you another parameter to play with - > as well as the average rate, the virtual queue threshold (ie length at > which go from no marking to marking). This allows you to control how > sensitive you are to bursty traffic. > I definitely support the virtual queue for excess-traffic marking. However, for the stop-admission marking I am still undecided what is best since we want to have a clear and stable answer whether more traffic can be admitted. I think this might an issue for further research. Best wishes, Michael > Thanks > Phil Eardley > Ben Strulo > > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: 25 October 2006 22:37 > To: menth@informatik.uni-wuerzburg.de; Kwok-Ho Chan > Cc: pcn@ietf.org > Subject: RE: [PCN] Re: draft-chan-pcn-problem-statement-01.txt > submission > > Hi Michael, > > I do agree with your observation that if smooth traffic consistently > exceeds the admission threshold, then all traffic soon starts getting > admission-marked, and hence further admission is prevented. Strictly > speaking that does not contradict the statement that in that case PCN > fails to prevent admission *prior* to reaching the admission threshold. > But indeed, as admission control is expected to be substantially below > the link speed (or real queue service rate), that is not in practice a > serious problem, in my opinion. Perhaps the next version of the draft > could elaborate on this a bit more. > > Anna > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Wednesday, October 25, 2006 5:05 AM > To: Kwok-Ho Chan > Cc: pcn@ietf.org > Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt > submission > > Hi all, > > I browsed through the drafts and have some comments on Section 5 > "Aggregate Traffic Characteristics" which says: > > "However, too little [traffic] variation can also be a problem [for the > PCN marking]. For example, if all the sources are constant bit rate and > are synchronised, then the total traffic level at a router's interface > could be (almost) at its capacity and all packets could still be > serviced instantly. However, admitting one more flow could tip the > router over its capacity, so its queue grew indefinitely until it had to > drop packets. "Some" traffic variation means that as the traffic level > nears the capacity limit, some packets are PCN-marked but there's still > enough capacity to cope with the traffic fluctuations. Hence new flows > can be blocked and packets are never dropped." > > With PCN, all packets are "stop admission marked" if the currently > observed rate exceeds the configured "admissible interface rate". The > configured "admissible interface rate" is usually substantially smaller > than the physical link bandwidth. > > In the context of RED marking, only those packets are marked that exceed > a certain threshold of the physical queue which is served at link rate. > If the traffic exceeds the link rate preliminarily on a small time > scale, a queue builds up and some of the queued packets are marked. This > can also happen if the aggregate rate is low, but if bursts arrive. In > contrast, if the rate of the aggregate reaches almost the link > bandwidth, but if it is sufficiently smooth, no queue builds up. Thus, > the problem with RED-like marking is that it can give EARLY warning only > if the current traffic rate is below the link rate but exceeds it due to > short term variations. > > From my perspective, PCN marking does not have this problem because it > reacts if the sent rate exceeds the configured rate and that can be well > observed on a larger time scale than packet level, short term variations > are not required to this end. Therefore, PCN marking leads to more > stable results than RED marking and it does not need to give a warning > if the configured "admissible interface rate" is not achieved on a > medium time scale (~1s). Therefore, early warning can be perfectly done > also for extremely smooth CBR traffic. > > Best wishes, > > Michael > > Kwok-Ho Chan wrote: > >> Hi: >> Please notice I have submitted an update to the Problem-Statement >> > draft. > >> Please see the link to the draft at: >> >> http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.tx >> t >> >> There were couple of minor cleanups. >> I have also added a new section just to set up the discussion of >> trust, with the trust assumptions and security still in the >> assumptions and security sections (as they were in -00). >> Thanks! >> -- Kwok -- >> >> >> At 03:04 AM 10/23/2006, you wrote: >> >>> This is the submission of an update (version 01) to an individual >>> > draft. > >>> Title: Pre-Congestion Notification Problem Statement >>> >>> Filename: draft-chan-pcn-problem-statement-01.txt >>> >>> Abstract: >>> DiffServ mechanisms have been developed to support Quality of >>> > Service > >>> (QoS). However, the level of assurance that can be provided with >>> DiffServ without substantial over-provisioning is limited. Pre- >>> Congestion Notification (PCN) investigates the use of per-flow >>> admission control to provide the required service guarantees for >>> > the > >>> admitted traffic. While admission control will protect the QoS >>> > under > >>> normal operating conditions, an additional flow pre-emption >>> > mechanism > >>> is necessary in the times of heavy congestion (e.g. caused by >>> > route > >>> changes due to link or node failure). >>> >>> This document provides a problem statement on the addition of flow >>> admission control and flow pre-emption functionality to a DiffServ >>> network, in particular for the support of real time services such >>> > as > >>> voice and video. >>> >>> >>> If there is any question or problem related to this submission, >>> please contact: >>> Kwok Ho Chan >>> E-Mail: khchan@nortel.com >>> Phone: 978-288-8175 >>> >>> The text version of the draft is attached. >>> >>> Thank You! >>> -- Kwok -- >>> >>> >>> >>> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> > > -- > 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 > -- 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 From pcn-bounces@ietf.org Mon Oct 30 13:14:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebed-0004hP-0K; Mon, 30 Oct 2006 13:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebeb-0004hK-Tv for pcn@ietf.org; Mon, 30 Oct 2006 13:14:33 -0500 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 1GebeT-0003dd-JX for pcn@ietf.org; Mon, 30 Oct 2006 13:14:33 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 278F65F01; Mon, 30 Oct 2006 19:14:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1B6625EFF; Mon, 30 Oct 2006 19:14:25 +0100 (CET) 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 F019B52FF; Mon, 30 Oct 2006 19:14:24 +0100 (CET) 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 k9UIEOs22136; Mon, 30 Oct 2006 19:14:24 +0100 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 4433F6F58E; Mon, 30 Oct 2006 19:12:39 +0100 (CET) Message-ID: <4546407E.3080102@informatik.uni-wuerzburg.de> Date: Mon, 30 Oct 2006 19:12:14 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt submission References: <9671A92C3C8B5744BC97F855F7CB64650CD496A5@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64650CD496A5@zcarhxm1.corp.nortel.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: f2984bf50fb52a9e56055f779793d783 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Joe, Jozef Babiarz wrote: > Michael, good observations. > > Not sure if I understand your last point > " Therefore, PCN marking leads to more > stable results than RED marking and it does not need to give a warning > if the configured "admissible interface rate" is not achieved on a > medium time scale (~1s). Therefore, early warning can be perfectly done > also for extremely smooth CBR traffic." > > But at least in my view stop admission marking needs to respond frailly > quickly to increased traffic load to provide protection against flash > calling events (may users making call at the same time). In my view, > reaction to stop admission marking should be proportional to traffic > that is in excess of "admissible interface rate", that is if traffic is > above by a small amount, it is OK for stop admissible marking to take > medium time scale. However, if traffic exceeds the admissible rate by > large amount then stop marking needs to be quick. > Strong traffic increases also increase moving averages of measured rates fairly quickly. In addition, the speed can be controlled by the memory of the moving average parameter. I think these are some research questions that need to be better understood. Best wishes, Michael > Regards, Joe > QoS & Network Architecture > Telephone: 613-763-6098 (ESN 393-6098) > Email: babiarz@nortel.com > > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Wednesday, October 25, 2006 5:05 AM > To: Chan, Kwok-Ho (BL60:470) > Cc: pcn@ietf.org > Subject: Re: [PCN] Re: draft-chan-pcn-problem-statement-01.txt > submission > > Hi all, > > I browsed through the drafts and have some comments on Section 5 > "Aggregate Traffic Characteristics" which says: > > "However, too little [traffic] variation can also be a problem [for the > PCN marking]. For example, if all the sources are constant bit rate and > are synchronised, then the total traffic level at a router's interface > could be (almost) at its capacity and all packets could still be > serviced instantly. However, admitting one more flow could tip the > router over its capacity, so its queue grew indefinitely until it had to > > drop packets. "Some" traffic variation means that as the traffic level > nears the capacity limit, some packets are PCN-marked but there's still > enough capacity to cope with the traffic fluctuations. Hence new flows > can be blocked and packets are never dropped." > > With PCN, all packets are "stop admission marked" if the currently > observed rate exceeds the configured "admissible interface rate". The > configured "admissible interface rate" is usually substantially smaller > than the physical link bandwidth. > > In the context of RED marking, only those packets are marked that exceed > > a certain threshold of the physical queue which is served at link rate. > If the traffic exceeds the link rate preliminarily on a small time > scale, a queue builds up and some of the queued packets are marked. This > > can also happen if the aggregate rate is low, but if bursts arrive. In > contrast, if the rate of the aggregate reaches almost the link > bandwidth, but if it is sufficiently smooth, no queue builds up. Thus, > the problem with RED-like marking is that it can give EARLY warning only > > if the current traffic rate is below the link rate but exceeds it due to > > short term variations. > > From my perspective, PCN marking does not have this problem because it > reacts if the sent rate exceeds the configured rate and that can be well > > observed on a larger time scale than packet level, short term variations > > are not required to this end. Therefore, PCN marking leads to more > stable results than RED marking and it does not need to give a warning > if the configured "admissible interface rate" is not achieved on a > medium time scale (~1s). Therefore, early warning can be perfectly done > also for extremely smooth CBR traffic. > > Best wishes, > > Michael > > Kwok-Ho Chan wrote: > >> Hi: >> Please notice I have submitted an update to the Problem-Statement >> > draft. > >> Please see the link to the draft at: >> >> > http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-01.txt > >> There were couple of minor cleanups. >> I have also added a new section just to set up the discussion of >> > trust, > >> with the trust assumptions and security still in the assumptions and >> security sections (as they were in -00). >> Thanks! >> -- Kwok -- >> >> >> At 03:04 AM 10/23/2006, you wrote: >> >>> This is the submission of an update (version 01) to an individual >>> > draft. > >>> Title: Pre-Congestion Notification Problem Statement >>> >>> Filename: draft-chan-pcn-problem-statement-01.txt >>> >>> Abstract: >>> DiffServ mechanisms have been developed to support Quality of >>> > Service > >>> (QoS). However, the level of assurance that can be provided with >>> DiffServ without substantial over-provisioning is limited. Pre- >>> Congestion Notification (PCN) investigates the use of per-flow >>> admission control to provide the required service guarantees for >>> > the > >>> admitted traffic. While admission control will protect the QoS >>> > under > >>> normal operating conditions, an additional flow pre-emption >>> > mechanism > >>> is necessary in the times of heavy congestion (e.g. caused by >>> > route > >>> changes due to link or node failure). >>> >>> This document provides a problem statement on the addition of flow >>> admission control and flow pre-emption functionality to a DiffServ >>> network, in particular for the support of real time services such >>> > as > >>> voice and video. >>> >>> >>> If there is any question or problem related to this submission, >>> please contact: >>> Kwok Ho Chan >>> E-Mail: khchan@nortel.com >>> Phone: 978-288-8175 >>> >>> The text version of the draft is attached. >>> >>> Thank You! >>> -- Kwok -- >>> >>> >>> >>> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >> > > -- 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 From pcn-bounces@ietf.org Tue Oct 31 03:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geof9-0008ER-BQ; Tue, 31 Oct 2006 03:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geof8-0008EK-Gf for pcn@ietf.org; Tue, 31 Oct 2006 03:07:58 -0500 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 1Geof6-0001xH-0U for pcn@ietf.org; Tue, 31 Oct 2006 03:07:58 -0500 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3D5253068 for ; Tue, 31 Oct 2006 09:07:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 314C1433D for ; Tue, 31 Oct 2006 09:07:53 +0100 (CET) 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 1F6304326 for ; Tue, 31 Oct 2006 09:07:52 +0100 (CET) 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 k9V87qs28565 for ; Tue, 31 Oct 2006 09:07:52 +0100 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 9A3336F58E for ; Tue, 31 Oct 2006 09:06:06 +0100 (CET) Message-ID: <454703DE.9070409@informatik.uni-wuerzburg.de> Date: Tue, 31 Oct 2006 09:05:50 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pcn@ietf.org 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [PCN] Comments on draft-charny-pcn-single-marking 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear Anna, I read your draft http://standards.nortel.com/pcn/draft-charny-pcn-single-marking-00.txt Here are my comments. The draft heavily bases on the assumption that the preemption threshold is a fixed multiple of the admission threshold for all links in the network and Section 3.2.1 states that this restriction is not too severe. I see this point a bit differently. Traffic engineering should try to avoid congestion in the failure-free case and if likely failures occur. Thus, links need some backup capacity. If the preemption threshold is a fixed multiple of the admission threshold, we get additional constraints for routing optimization because the backup capacity is exactly the same percentage on the links. This side condition makes routing optimization (or the layout of explicit primary and backup paths) more difficult and less efficient. Despite my criticism I find the approach interesting since it saves a bit. However, I rather view it as a workaround for special networks where only one bit can be used for PCN marking. In the end, network efficiency is traded for a single bit. 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 From pcn-bounces@ietf.org Tue Oct 31 14:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gezab-0003Em-3c; Tue, 31 Oct 2006 14:48:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezaU-0003Ed-Gl for pcn@ietf.org; Tue, 31 Oct 2006 14:47:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezaR-0005Fl-3I for pcn@ietf.org; Tue, 31 Oct 2006 14:47:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 11:47:51 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VJlovv021554; Tue, 31 Oct 2006 14:47:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VJlmDO026619; Tue, 31 Oct 2006 14:47:50 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 14:47:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Comments on draft-charny-pcn-single-marking Date: Tue, 31 Oct 2006 14:47:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Comments on draft-charny-pcn-single-marking Thread-Index: Acb8w7qpse6mdHHmTbqL9caDDGExqgAYXEKw From: "Anna Charny \(acharny\)" To: , X-OriginalArrivalTime: 31 Oct 2006 19:47:48.0761 (UTC) FILETIME=[71916890:01C6FD25] DKIM-Signature: a=rsa-sha1; q=dns; l=2002; t=1162324070; x=1163188070; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=22Anna=20Charny=20\(acharny\)=22=20 |Subject:RE=3A=20[PCN]=20Comments=20on=20draft-charny-pcn-single-marking |To:,=20; X=v=3Dcisco.com=3B=20h=3DyLxMliQBd14Mhuw1I0mLeRekYOI=3D; b=HbkGbFnocoJX0MZtZ5l0gf1f8f9MN001vd3b0fVmP7QH0Hu/iMYsHwihyml7tXM1l9xyYvov orvRs8muAvXm1Ww6/UzrMXSNrzl15lG6mma4yg/MTVnD1OU3LyGSMp7r; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pre-Congestion Notification Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael, Indeed you are right that if routing optimisation is done, then having an additional constraint on it is yet another tradeoff that needs to be considered. =20 Anna =20 -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 Sent: Tuesday, October 31, 2006 3:06 AM To: pcn@ietf.org Subject: [PCN] Comments on draft-charny-pcn-single-marking Dear Anna, I read your draft http://standards.nortel.com/pcn/draft-charny-pcn-single-marking-00.txt Here are my comments. The draft heavily bases on the assumption that the preemption threshold is a fixed multiple of the admission threshold for all links in the network and Section 3.2.1 states that this restriction is not too severe. I see this point a bit differently. Traffic engineering should try to avoid congestion in the failure-free case and if likely failures occur.=20 Thus, links need some backup capacity. If the preemption threshold is a fixed multiple of the admission threshold, we get additional constraints for routing optimization because the backup capacity is exactly the same percentage on the links. This side condition makes routing optimization (or the layout of explicit primary and backup paths) more difficult and less efficient. Despite my criticism I find the approach interesting since it saves a bit. However, I rather view it as a workaround for special networks where only one bit can be used for PCN marking. In the end, network efficiency is traded for a single bit. 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn