From nobody Wed Aug 26 11:41:47 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159001B3097 for ; Wed, 26 Aug 2015 11:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX2ASDrL9V0F for ; Wed, 26 Aug 2015 11:41:45 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 6F2861B3095 for ; Wed, 26 Aug 2015 11:41:45 -0700 (PDT) Received: (qmail 3473 invoked by uid 0); 26 Aug 2015 18:41:39 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 26 Aug 2015 18:41:39 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 9WhZ1r00B2SSUrH01WhcYA; Wed, 26 Aug 2015 12:41:39 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=6PzwTDcoQqoA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=AKlOdi4I4VG8cOzP-54A:9 a=97cV0KQGBoxF_Sjn:21 a=CUxV89y5gfv-d7qF:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=OcfTO7int7NkWKpwEeg5844KJ2tef+S0rv+JhcmtbFU=; b=ZPSdQ75e4CqP1Lls5jNZ+GLvcUXHm22MP1n7msXh4w4CC9I01rrSS58MhFVL+hKM2MVJRdzkwCZjh8Cjxajrf7Opf/hP0KxoehXOFrhHHvphGmPk5DFOck+UvjZPLM9y; Received: from box313.bluehost.com ([69.89.31.113]:51079 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUfdd-0000bu-25; Wed, 26 Aug 2015 12:41:33 -0600 To: DetNet From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55DE0857.8010503@labn.net> Date: Wed, 26 Aug 2015 14:41:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Pat Thaler , Jouni Korhonen , "Pascal Thubert \(pthubert\)" Subject: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 18:41:47 -0000 So a few of us have been having an offline discussion to get the ball rolling on a draft WG charter discussion. Here's what we have so far. I think we all recognize it isn't perfect, but it's a starting point for the discussion. Please comment / provide specific proposals for modification... Proposed DetNet Charter The Deterministic Networking Working Group (DetNet) will focus on deterministic data paths that operate over Layer-2 Bridged and Layer-3 routed segments, where such paths can provide bounded latency, loss and jitter. The Working Group will address Layer 3 aspects in support of deterministic applications. The group will collaborate with IEEE802.1TSN, which is responsible for Layer-2 operations, to define a common architecture to support IEEE802.1TSN applications. For the common architecture, a number of elements such as the IEEE802.1TSN host operation should be agnostic to the choice of network used for the connectivity. The Working Group will specify an overall architecture that encompasses the data plane, OAM, management, control, and security aspects that are required to enable a multi-hop path, and forwarding along that path, with the deterministic properties of controlled latency, low packet loss, low jitter, and high reliability. The work will apply to flows that can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no more required. The work will cover the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes; it will not include end-to-end considerations such as transport protocols, modification of OAM, L3 forwarding and encapsulations, or control plane protocols. Candidate Layer 3 data plane technologies that may be used, without modification, include: IPv4, IPv6, MPLS. As part of the overall architecture work, the working group will document which deployment environments and types of topologies that are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane and is independent from any path setup protocol or mechanism. The data plane will be compatible with the work done in IEEE801.1TSN. DetNet is chartered to work in the following areas: o Overall architecture: This work encompasses the data plane, OAM, management, control, and security aspects. o Data plane: This work will document a data plane method of flow identification and packet forwarding over Layer 3. o Data flow information model: This work will identify the information needed for flow establishment and control and be used by a reservation protocol or by YANG data models. The work will be independent from the protocol(s) used to control the flows (e.g. YANG, PCEP or GMPLS). o Identification of additional YANG augmentations: This work will document device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) for use in device configuration and status reporting. Such information may also be used when advertising the deterministic network elements to a control plane. The work will be independent from the protocol(s) that may be used to advertise this information (e.g. ISIS or GMPLS extensions). Any YANG work will be coordinated with the working groups that define the base models. o As needed, problem statement: This effort will establish the deployment environment and deterministic network requirements which is supported. o As needed, vertical requirements: This effort will detail the requirements for deterministic networks in various industries, for example, professional audio, electrical utilities, building automation systems, wireless for industrial applications. The WG will coordinate with other relevant IETF Working Groups, including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work progresses, requirements may be provided to the responsible Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the consistency of the overall architecture. The WG will liaise with appropriate groups in IEEE and other Standards Development Organizations (SDOs). From nobody Thu Aug 27 05:10:13 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F761B338A for ; Thu, 27 Aug 2015 05:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkQ6g438K6PH for ; Thu, 27 Aug 2015 05:10:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500921A1B03 for ; Thu, 27 Aug 2015 05:10:06 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-30-55defe1cab3d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.CD.17026.C1EFED55; Thu, 27 Aug 2015 14:10:04 +0200 (CEST) Received: from [159.107.143.210] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Thu, 27 Aug 2015 14:10:03 +0200 Message-ID: <55DEFE1B.3000702@ericsson.com> Date: Thu, 27 Aug 2015 14:10:03 +0200 From: =?windows-1252?Q?J=E1nos_Farkas?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: References: <55DE0857.8010503@labn.net> In-Reply-To: <55DE0857.8010503@labn.net> Content-Type: multipart/alternative; boundary="------------030301060707060804020009" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvja7Mv3uhBrPmaFr8/jSbxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGWe7DzEVtK9mrvj2mKWBcdNbpi5GTg4JAROJXUuuQNliEhfu rWfrYuTiEBI4yihx+NxzRghnLaPE/w3X2EGqeAW0JTov/APrYBFQlWjo38oIYrMJOEs8utgL FhcViJI4uuQqVL2gxMmZT1hAbBEBUYkTUzrB4sICehJXHr5gA7GFBNQlvhzdyApicwpoSPye 2Q02k1kgTKLn8lcWiBo1iU9vH7JPYOSfhWTsLCRlsxg5gGx7iQdbyyDC8hLb385hhrD1Ja7f uc+KLL6AkW0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmDQHtzyW3cH4+rXjocYBTgYlXh4 FfLvhQqxJpYVV+YeYpTmYFES5z1zHSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcVmaR/u/ qwJWFu6fFJmvbolw4nAUnLfevTh1QnPDLY09DRn10eU3n17gSdjFkaZzMsHoY/G5WR3+r7SV 2DINDCfOP//pYmDKfAY/G4NYD3UGL6+o/cqXZx+Y3ZNTP/ORohX37RDRxXVeDBO1c0wPfLV+ PvXHo4W6G1YZmlndUnrnEz/l8/+9SizFGYmGWsxFxYkAEShV0jsCAAA= Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:10:11 -0000 --------------030301060707060804020009 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi, I think that the charter is pretty good. (noting is perfect) Please find some comments below on the charter text. 1st paragraph: - I think "Deterministic Networking (DetNet) Working Group" looks better than "Deterministic Networking Working Group (DetNet)". - "Layer-3" vs "Layer 3" are not used consequently (same for L2) - I'd use "packet delay variation" instead of "jitter" in all occurrences. - I think "The Working Group will address Layer 3 aspects in support of applications requiring deterministic networking." would be better than "The Working Group will address Layer 3 aspects in support of deterministic applications." (I'm not sure whether "deterministic application" is defined.) 2nd paragraph: - I think it is quite important that we are often going below milliseconds. I'd extend "controlled latency" with "controlled low latency (even sub-milliseconds)" or sg like that. - I'd extend the last sentence with "aspects": "This work focuses on the data plane aspects and ..." - typo: IEEE801.1TSN -> IEEE802.1TSN - (use of "IEEE 802.1 TSN" with the spaces could be considered) Data flow information model: - PCEP and GMPLS are protocols at the end in the parentheses. Instead of YANG, I'd add NetConf or sg similar here. Identification of additional YANG augmentations: - "IS-IS" looks better to me than "ISIS". problem statement: - I think "which is supported" is unnecessary at the end, I'd delete it. Last paragraph: - I think the IS-IS WG and the OSPF WG are missing from the list of WGs DetNet WG will coordinate with. The TE extensions of these protocols can be useful for DetNet. Best regards, Janos On 8/26/2015 8:41 PM, Lou Berger wrote: > So a few of us have been having an offline discussion to get the ball > rolling on a draft WG charter discussion. Here's what we have so far. > I think we all recognize it isn't perfect, but it's a starting point for > the discussion. > > Please comment / provide specific proposals for modification... > > Proposed DetNet Charter > > The Deterministic Networking Working Group (DetNet) will focus on > deterministic data paths that operate over Layer-2 Bridged and Layer-3 > routed segments, where such paths can provide bounded latency, loss and > jitter. The Working Group will address Layer 3 aspects in support of > deterministic applications. The group will collaborate with > IEEE802.1TSN, which is responsible for Layer-2 operations, to define a > common architecture to support IEEE802.1TSN applications. For the common > architecture, a number of elements such as the IEEE802.1TSN host > operation should be agnostic to the choice of network used for the > connectivity. > > The Working Group will specify an overall architecture that encompasses > the data plane, OAM, management, control, and security aspects that are > required to enable a multi-hop path, and forwarding along that path, > with the deterministic properties of controlled latency, low packet > loss, low jitter, and high reliability. The work will apply to flows > that can be characterized in a manner that allows the network to 1) > reserve the appropriate resources for the flows in advance, and 2) > release/reuse the resources when they are no more required. The work > will cover the characterization of flows, the encapsulation of frames, > the required forwarding behaviors, as well as the state that may need to > be established in intermediate nodes; it will not include end-to-end > considerations such as transport protocols, modification of OAM, L3 > forwarding and encapsulations, or control plane protocols. Candidate > Layer 3 data plane technologies that may be used, without modification, > include: IPv4, IPv6, MPLS. As part of the overall architecture work, the > working group will document which deployment environments and types of > topologies that are within (or outside) the scope of the DetNet > architecture. This work focuses on the data plane and is independent > from any path setup protocol or mechanism. The data plane will be > compatible with the work done in IEEE801.1TSN. > > DetNet is chartered to work in the following areas: > > o Overall architecture: This work encompasses the data plane, OAM, > management, control, and security aspects. > > o Data plane: This work will document a data plane method of flow > identification and packet forwarding over Layer 3. > > o Data flow information model: This work will identify the information > needed for flow establishment and control and be used by a > reservation protocol or by YANG data models. The work will be > independent from the protocol(s) used to control the flows > (e.g. YANG, PCEP or GMPLS). > > o Identification of additional YANG augmentations: This work will > document device and link capabilities (feature support) and resources > (e.g. buffers, bandwidth) for use in device configuration and status > reporting. Such information may also be used when advertising the > deterministic network elements to a control plane. The work will be > independent from the protocol(s) that may be used to advertise this > information (e.g. ISIS or GMPLS extensions). Any YANG work will be > coordinated with the working groups that define the base models. > > o As needed, problem statement: This effort will establish the > deployment environment and deterministic network requirements which > is supported. > > o As needed, vertical requirements: This effort will detail the > requirements for deterministic networks in various industries, for > example, professional audio, electrical utilities, building > automation systems, wireless for industrial applications. > > The WG will coordinate with other relevant IETF Working Groups, > including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work > progresses, requirements may be provided to the responsible Working > Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to > maintain the consistency of the overall architecture. The WG will liaise > with appropriate groups in IEEE and other Standards Development > Organizations (SDOs). > > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --------------030301060707060804020009 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit Hi,

I think that the charter is pretty good. (noting is perfect)
Please find some comments below on the charter text.

1st paragraph:
- I think "Deterministic Networking (DetNet) Working Group" looks better than "Deterministic Networking Working Group (DetNet)".
- "Layer-3" vs "Layer 3" are not used consequently (same for L2)
- I'd use "packet delay variation" instead of "jitter" in all occurrences.
- I think "The Working Group will address Layer 3 aspects in support of applications requiring deterministic networking." would be better than "The Working Group will address Layer 3 aspects in support of deterministic applications." (I'm not sure whether "deterministic application" is defined.)

2nd paragraph:
- I think it is quite important that we are often going below milliseconds. I'd extend "controlled latency" with "controlled low latency (even sub-milliseconds)" or sg like that.
- I'd extend the last sentence with "aspects": "This work focuses on the data plane aspects and ..."
- typo: IEEE801.1TSN -> IEEE802.1TSN
- (use of "IEEE 802.1 TSN" with the spaces could be considered)

Data flow information model:
- PCEP and GMPLS are protocols at the end in the parentheses. Instead of YANG, I'd add NetConf or sg similar here.

Identification of additional YANG augmentations:
- "IS-IS" looks better to me than "ISIS".

problem statement:
- I think "which is supported" is unnecessary at the end, I'd delete it.

Last paragraph:
- I think the IS-IS WG and the OSPF WG are missing from the list of WGs DetNet WG will coordinate with. The TE extensions of these protocols can be useful for DetNet.

Best regards,
Janos


On 8/26/2015 8:41 PM, Lou Berger wrote:
So a few of us have been having an offline discussion to get the ball
rolling on a draft WG charter discussion.  Here's what we have so far. 
I think we all recognize it isn't perfect, but it's a starting point for
the discussion.

Please comment / provide specific proposals for modification...

Proposed DetNet Charter

The Deterministic Networking Working Group (DetNet) will focus on
deterministic data paths that operate over Layer-2 Bridged and Layer-3
routed segments, where such paths can provide bounded latency, loss and
jitter. The Working Group will address Layer 3 aspects in support of
deterministic applications. The group will collaborate with
IEEE802.1TSN, which is responsible for Layer-2 operations, to define a
common architecture to support IEEE802.1TSN applications. For the common
architecture, a number of elements such as the IEEE802.1TSN host
operation should be agnostic to the choice of network used for the
connectivity.

The Working Group will specify an overall architecture that encompasses
the data plane, OAM, management, control, and security aspects that are
required to enable a multi-hop path, and forwarding along that path,
with the deterministic properties of controlled latency, low packet
loss, low jitter, and high reliability. The work will apply to flows
that can be characterized in a manner that allows the network to 1)
reserve the appropriate resources for the flows in advance, and 2)
release/reuse the resources when they are no more required.  The work
will cover the characterization of flows, the encapsulation of frames,
the required forwarding behaviors, as well as the state that may need to
be established in intermediate nodes; it will not include end-to-end
considerations such as transport protocols, modification of OAM, L3
forwarding and encapsulations, or control plane protocols. Candidate
Layer 3 data plane technologies that may be used, without modification,
include: IPv4, IPv6, MPLS. As part of the overall architecture work, the
working group will document which deployment environments and types of
topologies that are within (or outside) the scope of the DetNet
architecture.  This work focuses on the data plane and is independent
from any path setup protocol or mechanism.  The data plane will be
compatible with the work done in IEEE801.1TSN.

DetNet is chartered to work in the following areas:

 o Overall architecture: This work encompasses the data plane, OAM,
   management, control, and security aspects.

 o Data plane: This work will document a data plane method of flow
   identification and packet forwarding over Layer 3.

 o Data flow information model: This work will identify the information
   needed for flow establishment and control and be used by a
   reservation protocol or by YANG data models. The work will be
   independent from the protocol(s) used to control the flows
   (e.g. YANG, PCEP or GMPLS).

 o Identification of additional YANG augmentations: This work will
   document device and link capabilities (feature support) and resources
   (e.g. buffers, bandwidth) for use in device configuration and status
   reporting. Such information may also be used when advertising the
   deterministic network elements to a control plane. The work will be
   independent from the protocol(s) that may be used to advertise this
   information (e.g. ISIS or GMPLS extensions). Any YANG work will be
   coordinated with the working groups that define the base models.

 o As needed, problem statement: This effort will establish the
   deployment environment and deterministic network requirements which
   is supported.

 o As needed, vertical requirements: This effort will detail the
   requirements for deterministic networks in various industries, for
   example, professional audio, electrical utilities, building
   automation systems, wireless for industrial applications.

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work
progresses, requirements may be provided to the responsible Working
Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to
maintain the consistency of the overall architecture. The WG will liaise
with appropriate groups in IEEE and other Standards Development
Organizations (SDOs).





_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

--------------030301060707060804020009-- From nobody Thu Aug 27 15:22:39 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2061A8A4F for ; Thu, 27 Aug 2015 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7b2O4sSjlhg for ; Thu, 27 Aug 2015 15:22:37 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id C57E31A90ED for ; Thu, 27 Aug 2015 15:22:36 -0700 (PDT) Received: (qmail 23005 invoked by uid 0); 27 Aug 2015 22:22:36 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 27 Aug 2015 22:22:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 9yNU1r01K2SSUrH01yNXAE; Thu, 27 Aug 2015 16:22:35 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=S3hf13kxCXeRGSl7GnAA:9 a=A1cEuZJuB6ksVFUs:21 a=DVkFTWiM0eQrWNud:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=S65rsqUsotucdZ2uN8bKoyHBkkFUvk4HA0w1ffo/tbo=; b=0Csc8CB+p8zOQBuwb7YdpjaP6+MtVjxvWyHt8WWuRj9xG0m0P6QdUobeal6RkIlCBqC6gUlaU8Sf/qlrcHvbmEhwUrF3TKB1c3fVIiI/Is0NIKUWVkMZ3zRN297zuumw; Received: from box313.bluehost.com ([69.89.31.113]:55981 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZV5Yz-0003un-DR; Thu, 27 Aug 2015 16:22:29 -0600 To: detnet@ietf.org, =?UTF-8?Q?J=c3=a1nos_Farkas?= References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> From: Lou Berger Message-ID: <55DF8DA0.7050908@labn.net> Date: Thu, 27 Aug 2015 18:22:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DEFE1B.3000702@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 22:22:39 -0000 János, Really good comments. I've put the draft text on a Wiki: http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter It's available for editing -- but please discuss changes on list before making them. I'll update it per your comments, and send a message once done. Although, probably tomorrow... Lou On 8/27/2015 8:10 AM, János Farkas wrote: > Hi, > > I think that the charter is pretty good. (noting is perfect) > Please find some comments below on the charter text. > > 1st paragraph: > - I think "Deterministic Networking (DetNet) Working Group" looks > better than "Deterministic Networking Working Group (DetNet)". > - "Layer-3" vs "Layer 3" are not used consequently (same for L2) > - I'd use "packet delay variation" instead of "jitter" in all occurrences. > - I think "The Working Group will address Layer 3 aspects in support > of applications requiring deterministic networking." would be better > than "The Working Group will address Layer 3 aspects in support of > deterministic applications." (I'm not sure whether "deterministic > application" is defined.) > > 2nd paragraph: > - I think it is quite important that we are often going below > milliseconds. I'd extend "controlled latency" with "controlled low > latency (even sub-milliseconds)" or sg like that. > - I'd extend the last sentence with "aspects": "This work focuses on > the data plane aspects and ..." > - typo: IEEE801.1TSN -> IEEE802.1TSN > - (use of "IEEE 802.1 TSN" with the spaces could be considered) > > Data flow information model: > - PCEP and GMPLS are protocols at the end in the parentheses. Instead > of YANG, I'd add NetConf or sg similar here. > > Identification of additional YANG augmentations: > - "IS-IS" looks better to me than "ISIS". > > problem statement: > - I think "which is supported" is unnecessary at the end, I'd delete it. > > Last paragraph: > - I think the IS-IS WG and the OSPF WG are missing from the list of > WGs DetNet WG will coordinate with. The TE extensions of these > protocols can be useful for DetNet. > > Best regards, > Janos > > > On 8/26/2015 8:41 PM, Lou Berger wrote: >> So a few of us have been having an offline discussion to get the ball >> rolling on a draft WG charter discussion. Here's what we have so far. >> I think we all recognize it isn't perfect, but it's a starting point for >> the discussion. >> >> Please comment / provide specific proposals for modification... >> >> Proposed DetNet Charter >> >> The Deterministic Networking Working Group (DetNet) will focus on >> deterministic data paths that operate over Layer-2 Bridged and Layer-3 >> routed segments, where such paths can provide bounded latency, loss and >> jitter. The Working Group will address Layer 3 aspects in support of >> deterministic applications. The group will collaborate with >> IEEE802.1TSN, which is responsible for Layer-2 operations, to define a >> common architecture to support IEEE802.1TSN applications. For the common >> architecture, a number of elements such as the IEEE802.1TSN host >> operation should be agnostic to the choice of network used for the >> connectivity. >> >> The Working Group will specify an overall architecture that encompasses >> the data plane, OAM, management, control, and security aspects that are >> required to enable a multi-hop path, and forwarding along that path, >> with the deterministic properties of controlled latency, low packet >> loss, low jitter, and high reliability. The work will apply to flows >> that can be characterized in a manner that allows the network to 1) >> reserve the appropriate resources for the flows in advance, and 2) >> release/reuse the resources when they are no more required. The work >> will cover the characterization of flows, the encapsulation of frames, >> the required forwarding behaviors, as well as the state that may need to >> be established in intermediate nodes; it will not include end-to-end >> considerations such as transport protocols, modification of OAM, L3 >> forwarding and encapsulations, or control plane protocols. Candidate >> Layer 3 data plane technologies that may be used, without modification, >> include: IPv4, IPv6, MPLS. As part of the overall architecture work, the >> working group will document which deployment environments and types of >> topologies that are within (or outside) the scope of the DetNet >> architecture. This work focuses on the data plane and is independent >> from any path setup protocol or mechanism. The data plane will be >> compatible with the work done in IEEE801.1TSN. >> >> DetNet is chartered to work in the following areas: >> >> o Overall architecture: This work encompasses the data plane, OAM, >> management, control, and security aspects. >> >> o Data plane: This work will document a data plane method of flow >> identification and packet forwarding over Layer 3. >> >> o Data flow information model: This work will identify the information >> needed for flow establishment and control and be used by a >> reservation protocol or by YANG data models. The work will be >> independent from the protocol(s) used to control the flows >> (e.g. YANG, PCEP or GMPLS). >> >> o Identification of additional YANG augmentations: This work will >> document device and link capabilities (feature support) and resources >> (e.g. buffers, bandwidth) for use in device configuration and status >> reporting. Such information may also be used when advertising the >> deterministic network elements to a control plane. The work will be >> independent from the protocol(s) that may be used to advertise this >> information (e.g. ISIS or GMPLS extensions). Any YANG work will be >> coordinated with the working groups that define the base models. >> >> o As needed, problem statement: This effort will establish the >> deployment environment and deterministic network requirements which >> is supported. >> >> o As needed, vertical requirements: This effort will detail the >> requirements for deterministic networks in various industries, for >> example, professional audio, electrical utilities, building >> automation systems, wireless for industrial applications. >> >> The WG will coordinate with other relevant IETF Working Groups, >> including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work >> progresses, requirements may be provided to the responsible Working >> Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to >> maintain the consistency of the overall architecture. The WG will liaise >> with appropriate groups in IEEE and other Standards Development >> Organizations (SDOs). >> >> >> >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> >> > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Fri Aug 28 05:26:48 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74971B2F80 for ; Fri, 28 Aug 2015 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UznJEYxOzAJN for ; Fri, 28 Aug 2015 05:26:44 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 9D6721B2D24 for ; Fri, 28 Aug 2015 05:26:27 -0700 (PDT) Received: (qmail 15830 invoked by uid 0); 28 Aug 2015 12:26:19 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 28 Aug 2015 12:26:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ACSD1r00T2SSUrH01CSGeo; Fri, 28 Aug 2015 06:26:17 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=2u0yzHfZ4OQ1q5tp6qQA:9 a=9zcT9RCZWJ5TEXd9:21 a=NCEUbzXtNhqCcY9x:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=rwT94lCijKZ9kT/vtZapF/pEy6ndjZ7lVmFChgW604Y=; b=RbkuTXcivGZjFR2TnGmjsRxFcTIrUOyRXRi9GZiU1wO4Odn80Mb2Yb9HmJtx2jNjufArC733v0Ssvfn911B35sW4UkHhIUTowaHYe9zZSNRS0kN52k+QGJnhrOhTOS1Y; Received: from box313.bluehost.com ([69.89.31.113]:59131 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZVIjX-0007EW-3M; Fri, 28 Aug 2015 06:26:15 -0600 To: detnet@ietf.org, =?UTF-8?Q?J=c3=a1nos_Farkas?= References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> <55DF8DA0.7050908@labn.net> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55E05361.3030505@labn.net> Date: Fri, 28 Aug 2015 08:26:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DF8DA0.7050908@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:26:46 -0000 János, (All) I've updated the wiki based on your comments, take a look. See below for specific response/open points. On 8/27/2015 6:22 PM, Lou Berger wrote: > János, > > Really good comments. I've put the draft text on a Wiki: > http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter > > It's available for editing -- but please discuss changes on list before > making them. > > I'll update it per your comments, and send a message once done. > Although, probably tomorrow... > > Lou > > On 8/27/2015 8:10 AM, János Farkas wrote: >> Hi, >> >> I think that the charter is pretty good. (noting is perfect) >> Please find some comments below on the charter text. >> >> 1st paragraph: >> - I think "Deterministic Networking (DetNet) Working Group" looks >> better than "Deterministic Networking Working Group (DetNet)". >> - "Layer-3" vs "Layer 3" are not used consequently (same for L2) >> - I'd use "packet delay variation" instead of "jitter" in all occurrences. >> - I think "The Working Group will address Layer 3 aspects in support >> of applications requiring deterministic networking." would be better >> than "The Working Group will address Layer 3 aspects in support of >> deterministic applications." (I'm not sure whether "deterministic >> application" is defined.) All done. >> 2nd paragraph: >> - I think it is quite important that we are often going below >> milliseconds. I'd extend "controlled latency" with "controlled low >> latency (even sub-milliseconds)" or sg like that. While I don't disagree with the technical point, and I think it's particularly important WRT PDV/jitter, I'm not sure this level of detail really belongs in the charter. What do others think? >> - I'd extend the last sentence with "aspects": "This work focuses on >> the data plane aspects and ..." >> - typo: IEEE801.1TSN -> IEEE802.1TSN >> - (use of "IEEE 802.1 TSN" with the spaces could be considered) done. >> Data flow information model: >> - PCEP and GMPLS are protocols at the end in the parentheses. Instead >> of YANG, I'd add NetConf or sg similar here. fair enough. Changed to YANG+NETCONF/RESTCONF. >> Identification of additional YANG augmentations: >> - "IS-IS" looks better to me than "ISIS". >> >> problem statement: >> - I think "which is supported" is unnecessary at the end, I'd delete it. Done. >> Last paragraph: >> - I think the IS-IS WG and the OSPF WG are missing from the list of >> WGs DetNet WG will coordinate with. The TE extensions of these >> protocols can be useful for DetNet. 100% agree. Thanks again for the comments, Lou >> Best regards, >> Janos >> >> >> On 8/26/2015 8:41 PM, Lou Berger wrote: >>> So a few of us have been having an offline discussion to get the ball >>> rolling on a draft WG charter discussion. Here's what we have so far. >>> I think we all recognize it isn't perfect, but it's a starting point for >>> the discussion. >>> >>> Please comment / provide specific proposals for modification... >>> >>> Proposed DetNet Charter >>> >>> The Deterministic Networking Working Group (DetNet) will focus on >>> deterministic data paths that operate over Layer-2 Bridged and Layer-3 >>> routed segments, where such paths can provide bounded latency, loss and >>> jitter. The Working Group will address Layer 3 aspects in support of >>> deterministic applications. The group will collaborate with >>> IEEE802.1TSN, which is responsible for Layer-2 operations, to define a >>> common architecture to support IEEE802.1TSN applications. For the common >>> architecture, a number of elements such as the IEEE802.1TSN host >>> operation should be agnostic to the choice of network used for the >>> connectivity. >>> >>> The Working Group will specify an overall architecture that encompasses >>> the data plane, OAM, management, control, and security aspects that are >>> required to enable a multi-hop path, and forwarding along that path, >>> with the deterministic properties of controlled latency, low packet >>> loss, low jitter, and high reliability. The work will apply to flows >>> that can be characterized in a manner that allows the network to 1) >>> reserve the appropriate resources for the flows in advance, and 2) >>> release/reuse the resources when they are no more required. The work >>> will cover the characterization of flows, the encapsulation of frames, >>> the required forwarding behaviors, as well as the state that may need to >>> be established in intermediate nodes; it will not include end-to-end >>> considerations such as transport protocols, modification of OAM, L3 >>> forwarding and encapsulations, or control plane protocols. Candidate >>> Layer 3 data plane technologies that may be used, without modification, >>> include: IPv4, IPv6, MPLS. As part of the overall architecture work, the >>> working group will document which deployment environments and types of >>> topologies that are within (or outside) the scope of the DetNet >>> architecture. This work focuses on the data plane and is independent >>> from any path setup protocol or mechanism. The data plane will be >>> compatible with the work done in IEEE801.1TSN. >>> >>> DetNet is chartered to work in the following areas: >>> >>> o Overall architecture: This work encompasses the data plane, OAM, >>> management, control, and security aspects. >>> >>> o Data plane: This work will document a data plane method of flow >>> identification and packet forwarding over Layer 3. >>> >>> o Data flow information model: This work will identify the information >>> needed for flow establishment and control and be used by a >>> reservation protocol or by YANG data models. The work will be >>> independent from the protocol(s) used to control the flows >>> (e.g. YANG, PCEP or GMPLS). >>> >>> o Identification of additional YANG augmentations: This work will >>> document device and link capabilities (feature support) and resources >>> (e.g. buffers, bandwidth) for use in device configuration and status >>> reporting. Such information may also be used when advertising the >>> deterministic network elements to a control plane. The work will be >>> independent from the protocol(s) that may be used to advertise this >>> information (e.g. ISIS or GMPLS extensions). Any YANG work will be >>> coordinated with the working groups that define the base models. >>> >>> o As needed, problem statement: This effort will establish the >>> deployment environment and deterministic network requirements which >>> is supported. >>> >>> o As needed, vertical requirements: This effort will detail the >>> requirements for deterministic networks in various industries, for >>> example, professional audio, electrical utilities, building >>> automation systems, wireless for industrial applications. >>> >>> The WG will coordinate with other relevant IETF Working Groups, >>> including CCAMP, PCE, PALS, TEAS, TSVWG, and 6TisSCH. As the work >>> progresses, requirements may be provided to the responsible Working >>> Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to >>> maintain the consistency of the overall architecture. The WG will liaise >>> with appropriate groups in IEEE and other Standards Development >>> Organizations (SDOs). >>> >>> >>> >>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >>> >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet From nobody Fri Aug 28 15:15:50 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114601B3352 for ; Fri, 28 Aug 2015 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVH-KYeB5Z-h for ; Fri, 28 Aug 2015 15:15:47 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2884E1B332B for ; Fri, 28 Aug 2015 15:15:46 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t7SMDiin018751 for ; Fri, 28 Aug 2015 15:15:46 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0b-000fd501.pphosted.com with ESMTP id 1wjtjw0pbb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 28 Aug 2015 15:15:46 -0700 Received: from DLB-XCHPW02.dolby.net ([169.254.2.7]) by DLB-XMRPW01.dolby.net ([10.213.22.204]) with mapi id 14.03.0181.006; Fri, 28 Aug 2015 15:15:45 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: Draft DetNet Charter Thread-Index: AdDh2/0oQ4rd4u/SSNquI+3KOK24qQ== Date: Fri, 28 Aug 2015 22:15:44 +0000 Message-ID: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.76.1] Content-Type: multipart/alternative; boundary="_000_6CE1AE4935C63549B80243EE77A7246E0109CEBB1CDLBXCHPW02dol_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-28_11:2015-08-27,2015-08-28,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 22:15:49 -0000 --_000_6CE1AE4935C63549B80243EE77A7246E0109CEBB1CDLBXCHPW02dol_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Folks, I think the draft charter looks really good, and hits the right points. I h= ave a question about this phrase: "...and 2) release/reuse the resources when they are no more required..." One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in gene= ral) that I heard from our IT guys, in the context of a corporate network, = was that "once users reserved bandwidth for the streams they wanted, when t= hey were "done" they would never get around to tearing the streams down, an= d so that bandwidth would remain unusable by others on the network". My understanding is that reserved bandwidth with AVB/TSN is only used when = traffic is actually flowing on the stream, leaving the bandwidth available = for best effort traffic. It seems to me that to head off this objection, th= is point could be somehow communicated in this phrase, unless in DETNET tha= t is not the case; for example if the network reserves channels for TSN tra= ffic that are "permanently" allocated, and traffic from various streams is = directed over those channels, then the two reservations are "decoupled" and= the available reseerved bandwidth is limited only in the aggregate. But going back to the LAN case, I suppose such "stale" reserved bandwidth w= ould prevent others from reserving that bandwidth, so there might be some e= lement of validity in the stated concern? Do we have to deal with that issu= e, and if so can we somehow include our intent in the charter? Or maybe thi= s is too low a level of detail? Another note on the quote above: if we keep this phrase, then grammatically= it should read "...no longer required..." (not "no more required"). Best, Ethan. Ethan Grossman Dolby Laboratories --_000_6CE1AE4935C63549B80243EE77A7246E0109CEBB1CDLBXCHPW02dol_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Folks,
I think the dr= aft charter looks really good, and hits the right points. I have a question= about this phrase: 

"...an= d 2) release/reuse the resources when they are no more required..."

One of the concerns about AVB/TSN (and "reserve= d bandwidth" schemes in general) that I heard from our IT guys, in the= context of a corporate network, was that "once users reserved bandwidth for the streams they wanted, when they were "= ;done" they would never get around to tearing the streams down, and so= that bandwidth would remain unusable by others on the network". =

My understanding is that reserved bandwidth with AVB/= TSN is only used when traffic is actually flowing on the stream, leaving th= e bandwidth available for best effort traffic. It seems to me that to head = off this objection, = this point could be somehow communicated in this phrase, unless in DETNET that = is not the case; for example if the network reserves channels for TSN traff= ic that are "permanently" allocated, and traffic from various str= eams is directed over those channels, then the two reservations are "decoupled" and the available reseerved= bandwidth is limited only in the aggregate. 

But going back to the LAN case, I suppose such "= stale" reserved bandwidth would prevent others from reserving that ban= dwidth, so there might be some element of validity in the stated concern? Do we have to deal with that issue, and if so can w= e somehow include our intent in the charter? Or maybe this is too low a lev= el of detail? 

Another note on the quote above: if we keep this phr= ase, then grammatically it should read "...no longer required..."= (not "no more required"). 

Best,
Ethan.

Ethan Grossman
Dolby Laboratories

--_000_6CE1AE4935C63549B80243EE77A7246E0109CEBB1CDLBXCHPW02dol_-- From nobody Fri Aug 28 15:41:35 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB51E1B3003 for ; Fri, 28 Aug 2015 15:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIH1vTIhV97Y for ; Fri, 28 Aug 2015 15:41:32 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 06C041B2FCB for ; Fri, 28 Aug 2015 15:41:31 -0700 (PDT) Received: (qmail 24419 invoked by uid 0); 28 Aug 2015 22:41:24 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 28 Aug 2015 22:41:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ANhG1r0052SSUrH01NhKbq; Fri, 28 Aug 2015 16:41:22 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=lszNwCOoVosA:10 a=uRRa74qj2VoA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=jsLqV8V3AAAA:8 a=48vgC7mUAAAA:8 a=h2vMrvCAKgNdbfYwFyAA:9 a=CjuIK1q_8ugA:10 a=Knlx1YI1kxUwkLyFwdQA:9 a=7c9a93PGC-cO-ZVy:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=Urd+m/xddJRe+AvWpoYwG/1nAkQOvx60cwHu/XzLGsk=; b=BhQjdgF8MfqGBFrfClDOY7jVpFcWs6ilhOZGQl8QKdubgkavvC+Frp5liLOqAkiDsEYN1D68dYQPmj+90mWTCyJnRORuCiBqS1wmh6m++3nEi4X+wcMAY6CgRMdg/us5; Received: from [172.56.3.228] (port=20075 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZVSKj-0005K5-MA; Fri, 28 Aug 2015 16:41:18 -0600 From: Lou Berger To: "Grossman, Ethan A." , Date: Fri, 28 Aug 2015 18:41:15 -0400 Message-ID: <14f7678cb40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <14f766dbb38.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14f7678d9d01718281843e371e0" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.3.228 authed with lberger@labn.net} Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 22:41:34 -0000 This is a multi-part message in MIME format. ------------14f7678d9d01718281843e371e0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit Ethan, I put the correction into the wiki. I personally think the other points you raise are good ones for the WG to discuss... Thanks, Lou On August 28, 2015 6:16:16 PM "Grossman, Ethan A." wrote: > Hi Folks, > I think the draft charter looks really good, and hits the right points. I > have a question about this phrase: > > "...and 2) release/reuse the resources when they are no more required..." > > One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in > general) that I heard from our IT guys, in the context of a corporate > network, was that "once users reserved bandwidth for the streams they > wanted, when they were "done" they would never get around to tearing the > streams down, and so that bandwidth would remain unusable by others on the > network". > > My understanding is that reserved bandwidth with AVB/TSN is only used when > traffic is actually flowing on the stream, leaving the bandwidth available > for best effort traffic. It seems to me that to head off this objection, > this point could be somehow communicated in this phrase, unless in DETNET > that is not the case; for example if the network reserves channels for TSN > traffic that are "permanently" allocated, and traffic from various streams > is directed over those channels, then the two reservations are "decoupled" > and the available reseerved bandwidth is limited only in the aggregate. > > But going back to the LAN case, I suppose such "stale" reserved bandwidth > would prevent others from reserving that bandwidth, so there might be some > element of validity in the stated concern? Do we have to deal with that > issue, and if so can we somehow include our intent in the charter? Or maybe > this is too low a level of detail? > > Another note on the quote above: if we keep this phrase, then grammatically > it should read "...no longer required..." (not "no more required"). > > Best, > Ethan. > > Ethan Grossman > Dolby Laboratories > > > > > ---------- > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > ------------14f7678d9d01718281843e371e0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Ethan,

I put the correction into the wiki.

I personally  think the other points you raise are good ones for the WG to discuss...

Thanks,
Lou

On August 28, 2015 6:16:16 PM "Grossman, Ethan A." <eagros@dolby.com> wrote:

Hi Folks,
I think the draft charter looks really good, and hits the right points. I have a question about this phrase: 

"...and 2) release/reuse the resources when they are no more required..."

One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in general) that I heard from our IT guys, in the context of a corporate network, was that "once users reserved bandwidth for the streams they wanted, when they were "done" they would never get around to tearing the streams down, and so that bandwidth would remain unusable by others on the network". 

My understanding is that reserved bandwidth with AVB/TSN is only used when traffic is actually flowing on the stream, leaving the bandwidth available for best effort traffic. It seems to me that to head off this objection, this point could be somehow communicated in this phrase, unless in DETNET that is not the case; for example if the network reserves channels for TSN traffic that are "permanently" allocated, and traffic from various streams is directed over those channels, then the two reservations are "decoupled" and the available reseerved bandwidth is limited only in the aggregate. 

But going back to the LAN case, I suppose such "stale" reserved bandwidth would prevent others from reserving that bandwidth, so there might be some element of validity in the stated concern? Do we have to deal with that issue, and if so can we somehow include our intent in the charter? Or maybe this is too low a level of detail? 

Another note on the quote above: if we keep this phrase, then grammatically it should read "...no longer required..." (not "no more required"). 

Best,
Ethan.

Ethan Grossman
Dolby Laboratories

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

------------14f7678d9d01718281843e371e0-- From nobody Sat Aug 29 03:11:45 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925E11B30E6 for ; Sat, 29 Aug 2015 03:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORtpgCbXY2zR for ; Sat, 29 Aug 2015 03:11:41 -0700 (PDT) Received: from know-smtprelay-omc-3.server.virginmedia.net (know-smtprelay-omc-3.server.virginmedia.net [80.0.253.67]) by ietfa.amsl.com (Postfix) with ESMTP id DE3921B2FCB for ; Sat, 29 Aug 2015 03:11:40 -0700 (PDT) Received: from [192.168.4.64] ([86.6.153.109]) by know-smtprelay-3-imp with bizsmtp id AaBe1r00a2MsiYu01aBfQm; Sat, 29 Aug 2015 11:11:39 +0100 X-Originating-IP: [86.6.153.109] X-Spam: 0 X-Authority: v=2.1 cv=TYVrzkkh c=1 sm=1 tr=0 a=IG+6AR/xQ9OQVlDB0mQ8ww==:117 a=IG+6AR/xQ9OQVlDB0mQ8ww==:17 a=le6d79QuAAAA:8 a=mkP4Fkg8oMy4sdTd70QA:9 a=CjuIK1q_8ugA:10 a=uuHwHpsJuR5l_8D7M1EA:9 a=doLC9NaNcvsO0XzN:21 a=_W_S_7VecoQA:10 From: John Grant Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-72-826914289 Date: Sat, 29 Aug 2015 11:11:38 +0100 In-Reply-To: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net> To: detnet@ietf.org References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net> Message-Id: X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 10:11:43 -0000 --Apple-Mail-72-826914289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote: > Hi Folks, > I think the draft charter looks really good, and hits the right = points. I have a question about this phrase:=20 >=20 > "...and 2) release/reuse the resources when they are no more = required..." >=20 > One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in = general) that I heard from our IT guys, in the context of a corporate = network, was that "once users reserved bandwidth for the streams they = wanted, when they were "done" they would never get around to tearing the = streams down, and so that bandwidth would remain unusable by others on = the network".=20 [snip] > I suppose such "stale" reserved bandwidth would prevent others from = reserving that bandwidth, Exactly -- I think that's what they're referring to; you could finish up = with a link on which all the bandwidth is reserved but none is used, in = which case 100% of the link is available for best-effort traffic but no = new time-sensitive flows can use it. There's always a problem that folks may reserve resources they aren't = using, which could involve actual traffic as well as reservations, e.g. = sending video to a screen when no-one's watching it. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com --Apple-Mail-72-826914289 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Folks,
I think the draft charter looks really good, and hits the = right points. I have a question about this = phrase: 

"...and 2) release/reuse the = resources when they are no more required..."

One of the concerns about AVB/TSN (and "reserved = bandwidth" schemes in general) that I heard from our IT guys, in the = context of a corporate network, was that "once users reserved bandwidth = for the streams they wanted, when they were "done" they would never get = around to tearing the streams down, and so that bandwidth would remain = unusable by others on the = network". 
[snip]

I suppose such "stale" reserved bandwidth would = prevent others from reserving that = bandwidth,
<= br>
Exactly -- I think that's what they're referring to; you could = finish up with a link on which all the bandwidth is reserved but none is = used, in which case 100% of the link is available for best-effort = traffic but no new time-sensitive flows can use = it.

There's always a problem that folks may = reserve resources they aren't using, which could involve actual traffic = as well as reservations, e.g. sending video to a screen when no-one's = watching it.

John Grant
Nine Tiles, = Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

= --Apple-Mail-72-826914289-- From nobody Sat Aug 29 03:24:05 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BB11ACD0A for ; Sat, 29 Aug 2015 03:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh0Wwfr7bdHF for ; Sat, 29 Aug 2015 03:24:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8A21A8983 for ; Sat, 29 Aug 2015 03:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9811; q=dns/txt; s=iport; t=1440843841; x=1442053441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cv0mPCrUNsA+GQpVq26q9i3/XuC265ZbnHjWRR+rW6g=; b=DE15/bGDAjRvTj4GkfuAnMTIGAx1YS9mA1n0oIJAOJ1GP9lyEPLnj18y 7nmyARRq6NY4df7uOQ0hLYvIgBrOoZiRxAxDMJarhXIwuuPsLXI7xKSdX mU/iqk62wWeT/QfgGEyNDtwKzFYU9vZcvBB8wDZ7tuF8KseErlDr08gPz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqBQAViOFV/4sNJK1dgk5NVGm+EYFuAQmFMUoCgSk5EwEBAQEBAQGBCoQkAQEEAQEBUhkLEAIBCA4xBycLFBEBAQQOBYguDcQ3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Zwgg+CbIUHBAcJgw+BFAWNKIgZAYxymmomg39xgk0BAQE X-IronPort-AV: E=Sophos; i="5.17,429,1437436800"; d="scan'208,217"; a="24535633" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 29 Aug 2015 10:23:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7TANwfC027459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 29 Aug 2015 10:23:59 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 29 Aug 2015 05:23:58 -0500 Received: from xhc-aln-x08.cisco.com (173.36.12.82) by xch-rcd-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sat, 29 Aug 2015 05:23:58 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.191]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0248.002; Sat, 29 Aug 2015 05:23:57 -0500 From: "Pascal Thubert (pthubert)" To: John Grant Thread-Topic: [Detnet] Draft DetNet Charter Thread-Index: AdDh2/0oQ4rd4u/SSNquI+3KOK24qQAkQNAA//+vnrc= Date: Sat, 29 Aug 2015 10:23:56 +0000 Message-ID: <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_24DD07B7239B4A00B19D627447B656E1ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 10:24:03 -0000 --_000_24DD07B7239B4A00B19D627447B656E1ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, It is Kind of Easy to reuse bandwidth outgoing the switch if there was= no incoming packet; what's harder is to discover that the flow is terminat= ed. This will impact the flow description and or the protocols (e.g. Associatin= g a lifetime and a continuous renewal process to the registration) Point taken! I agree that this does not impact the charter, though. Cheers, Pascal Pascal Le 29 ao=FBt 2015 =E0 12:11, John Grant > a =E9crit : On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote: Hi Folks, I think the draft charter looks really good, and hits the right points. I h= ave a question about this phrase: "...and 2) release/reuse the resources when they are no more required..." One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in gene= ral) that I heard from our IT guys, in the context of a corporate network, = was that "once users reserved bandwidth for the streams they wanted, when t= hey were "done" they would never get around to tearing the streams down, an= d so that bandwidth would remain unusable by others on the network". [snip] I suppose such "stale" reserved bandwidth would prevent others from reservi= ng that bandwidth, Exactly -- I think that's what they're referring to; you could finish up wi= th a link on which all the bandwidth is reserved but none is used, in which= case 100% of the link is available for best-effort traffic but no new time= -sensitive flows can use it. There's always a problem that folks may reserve resources they aren't using= , which could involve actual traffic as well as reservations, e.g. sending = video to a screen when no-one's watching it. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_24DD07B7239B4A00B19D627447B656E1ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, It is Kind of Easy to reuse bandwidth outgoing the switch if ther= e was no incoming packet; what's harder is to discover that the flow is ter= minated.

This will impact the flow description and or the protocols (e.g. Assoc= iating a lifetime and a continuous renewal process to the registration)

Point taken! I agree that this does not impact the charter, though.

Cheers,

Pascal


Pascal

Le 29 ao=FBt 2015 =E0 12:11, John Grant <j@ninetiles.com> a =E9crit :


On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote:

Hi Folks,
I think the d= raft charter looks really good, and hits the right points. I have a questio= n about this phrase: 

"..= .and 2) release/reuse the resources when they are no more required..."=

One of the concerns about AVB/TSN (and "reserv= ed bandwidth" schemes in general) that I heard from our IT guys, in th= e context of a corporate network, was that "once users reserved bandwidth for the streams they wanted, when they were "= ;done" they would never get around to tearing the streams down, and so= that bandwidth would remain unusable by others on the network". =

[snip]

I suppose such "stale" reserved bandwidth = would prevent others from reserving that bandwidth,

Exactly -- I think that's what they're referring to; you could finish up wi= th a link on which all the bandwidth is reserved but none is used, in which= case 100% of the link is available for best-effort traffic but no new time= -sensitive flows can use it.

There's always a problem that folks may reserve resources they aren't = using, which could involve actual traffic as well as reservations, e.g. sen= ding video to a screen when no-one's watching it.

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.= ietf.org/mailman/listinfo/detnet
--_000_24DD07B7239B4A00B19D627447B656E1ciscocom_-- From nobody Mon Aug 31 05:26:04 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEAA1B44C9 for ; Mon, 31 Aug 2015 05:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esj8jgLQr5NC for ; Mon, 31 Aug 2015 05:26:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DBF1B44C5 for ; Mon, 31 Aug 2015 05:26:00 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-c2-55e447d66028 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.8D.27359.6D744E55; Mon, 31 Aug 2015 14:25:59 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.82]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 14:25:58 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "detnet@ietf.org" Thread-Topic: [Detnet] Draft charter discussion Thread-Index: AQHQ4RbZcGkqsh3E+0SwHwyIstnDX54hNbqAgATX01A= Date: Mon, 31 Aug 2015 12:25:57 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EDB97DF@ESESSMB103.ericsson.se> References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> <55DF8DA0.7050908@labn.net> <55E05361.3030505@labn.net> In-Reply-To: <55E05361.3030505@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje519yehBk1XeCx+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFkLjQu+slf0TJzK0sC4ga2LkZNDQsBEYs+0e+wQtpjEhXvr geJcHEICRxklPjS/YgZJCAksZpTY1qYHYrMJuEp87ngI1iwioC7R9uYaYxcjB4ewgJ5E30ZP iLC+xIWDK5khbCuJWS+usHYxsnOwCKhKXNEBifIK+EpM2PaNHWJTI9DwWRfAJnIKaEh8XH0D rJUR6Jzvp9YwgdjMAuISt57MZ4I4U0BiyZ7zzBC2qMTLx/9YIWxFiavTl0PV60ncmDqFDcLW lli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcVJuupGRXmpRZnJxcX6e Xl5qySZGYDQc3PLbYAfjy+eOhxgFOBiVeHgVtj4OFWJNLCuuzD3EKM3BoiTO28z0IFRIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDo0f+lZ0vPNY5BF++x/jV9in3NZZT74p3667ZG8gr1x6n 9+fN1aa6763Cpw7w9KiHSl6ZorrvhGNC7su9nqmHWNZXqBqa/zm5+g4Lj4HKrnM+nSbSRVez k1l4XGp3bzX6Ws28vEY0NDyfIfWMOIeSwlzzv6vcLRf7LNFZV3YkJ/usfLroC8NPSizFGYmG WsxFxYkAoL/l8GcCAAA= Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:26:02 -0000 Hi, =20 I would argue for explicitly highlighting sub-millisecond requirement as ma= ny current protocols do not deal with such a timescale. =20 Cheers Bala'zs -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, August 28, 2015 2:26 PM To: detnet@ietf.org; Janos Farkas Subject: Re: [Detnet] Draft charter discussion J=E1nos, (All) I've updated the wiki based on your comments, take a look. See below for s= pecific response/open points. On 8/27/2015 6:22 PM, Lou Berger wrote: > J=E1nos, > snips >> 2nd paragraph: >> - I think it is quite important that we are often going below=20 >> milliseconds. I'd extend "controlled latency" with "controlled low=20 >> latency (even sub-milliseconds)" or sg like that. While I don't disagree with the technical point, and I think it's particula= rly important WRT PDV/jitter, I'm not sure this level of detail really belo= ngs in the charter.=20 What do others think? From nobody Mon Aug 31 05:28:27 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6711B3902 for ; Mon, 31 Aug 2015 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1aC6XzA7YgJ for ; Mon, 31 Aug 2015 05:28:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D9F1B324B for ; Mon, 31 Aug 2015 05:28:22 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-4c-55e44864a069 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.3F.05274.46844E55; Mon, 31 Aug 2015 14:28:20 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 14:28:20 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "detnet@ietf.org" Thread-Topic: [Detnet] Draft DetNet Charter Thread-Index: AdDh2/0oQ4rd4u/SSNquI+3KOK24qQAVlbgAAABt+QAAbQrzgA== Date: Mon, 31 Aug 2015 12:28:19 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net>, <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> In-Reply-To: <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_3002A87EA61E0A4DB56546AC16A0D5171EDB9805ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvjW6Kx5NQg4kPrC1+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP375jEVbE6vWP1vHXMD48GoLkZODgkBE4k7ix8zQ9hiEhfu rWfrYuTiEBI4yihx9eICVghnMaPE9plLWECq2ARcJT53PGQDsUUE1CXa3lxjBLGFBbQktl06 xQwR15b4/msTE4TtJNG0ex5YL4uAqsSvha/A4rwCvhKT276CxYUEdjFKbH6UBWJzCthKLLj9 jx3EZgS66PupNWD1zALiEreezGeCuFRAYsme81BXi0q8fPyPFcJWlLg6fTlUfb7Ek+4tjBC7 BCVOznzCMoFRZBaSUbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2Vcxihan FiflphsZ66UWZSYXF+fn6eWllmxiBEbRwS2/VXcwXn7jeIhRgINRiYdXYevjUCHWxLLiytxD jNIcLErivM1MD0KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEp8YHnJsNd4hrWb3Q17D+0Z L3ZNeT2bXTZ2Up7GGeW7dtMFVnIqJTImhyalsAc9imXdfExH/DF/a8/cTzPa38UL27cEFFcw foo9X8P8s6TH4Za7/L+Du1uY1r5XkbjI/XDJBGHvOUcWdSU0ph6+L7FSanLJ4ZO6LK94J9xc sX2GyC+FOHe25UosxRmJhlrMRcWJAHuqEh2DAgAA Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:28:26 -0000 --_000_3002A87EA61E0A4DB56546AC16A0D5171EDB9805ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree, release of unused resources is an important task to be solved by t= he WG. The situation with some TSN tools can be even worst than what you have desc= ribed below. E.g. using "802.1Qbv Enhancements for Scheduled Traffic" in some cases no o= ther traffic (including best-effort) can use the reserved bandwidth. So if You have reserved all the bandwidth but all high priority flows are t= erminated no traffic can cross your link. Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Saturday, August 29, 2015 12:24 PM To: John Grant Cc: detnet@ietf.org Subject: Re: [Detnet] Draft DetNet Charter Yes, It is Kind of Easy to reuse bandwidth outgoing the switch if there was= no incoming packet; what's harder is to discover that the flow is terminat= ed. This will impact the flow description and or the protocols (e.g. Associatin= g a lifetime and a continuous renewal process to the registration) Point taken! I agree that this does not impact the charter, though. Cheers, Pascal Pascal Le 29 ao=FBt 2015 =E0 12:11, John Grant > a =E9crit : On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote: Hi Folks, I think the draft charter looks really good, and hits the right points. I h= ave a question about this phrase: "...and 2) release/reuse the resources when they are no more required..." One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in gene= ral) that I heard from our IT guys, in the context of a corporate network, = was that "once users reserved bandwidth for the streams they wanted, when t= hey were "done" they would never get around to tearing the streams down, an= d so that bandwidth would remain unusable by others on the network". [snip] I suppose such "stale" reserved bandwidth would prevent others from reservi= ng that bandwidth, Exactly -- I think that's what they're referring to; you could finish up wi= th a link on which all the bandwidth is reserved but none is used, in which= case 100% of the link is available for best-effort traffic but no new time= -sensitive flows can use it. There's always a problem that folks may reserve resources they aren't using= , which could involve actual traffic as well as reservations, e.g. sending = video to a screen when no-one's watching it. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_3002A87EA61E0A4DB56546AC16A0D5171EDB9805ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I agree, release of unuse= d resources is an important task to be solved by the WG.

 <= /p>

The situation with some T= SN tools can be even worst than what you have described below.

E.g. using “802.1Qb= v Enhancements for Scheduled Traffic” in some cases no other traffic = (including best-effort) can use the reserved bandwidth.

So if You have reserved a= ll the bandwidth but all high priority flows are terminated no traffic can = cross your link.

Cheers<= /p>

Bala’zs<= /span>

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Saturday, August 29, 2015 12:24 PM
To: John Grant
Cc: detnet@ietf.org
Subject: Re: [Detnet] Draft DetNet Charter

 

Yes, It is Kind of Easy to reuse bandwidth outgoing = the switch if there was no incoming packet; what's harder is to discover th= at the flow is terminated.

 

This will impact the flow description and or the pro= tocols (e.g. Associating a lifetime and a continuous renewal process to the= registration)

 

Point taken! I agree that this does not impact the c= harter, though.

 

Cheers,

 

Pascal



Pascal


Le 29 ao=FBt 2015 =E0 12:11, John Grant <j@ninetiles.com> a =E9crit :

 

On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote:<= o:p>



Hi Folks,

I think the draft charter looks really good, and hits the right p= oints. I have a question about this phrase: 

 

"...and 2) release/reuse the resources when they are no more= required..."

 

One of = the concerns about AVB/TSN (and "reserved bandwidth" schemes in g= eneral) that I heard from our IT guys, in the context of a corporate networ= k, was that "once users reserved bandwidth for the streams they wanted, when they were "done" they would never = get around to tearing the streams down, and so that bandwidth would remain = unusable by others on the network".  

[snip]



I suppo= se such "stale" reserved bandwidth would prevent others from rese= rving that bandwidth,

 

Exactly -- I think that's what they're referring to;= you could finish up with a link on which all the bandwidth is reserved but= none is used, in which case 100% of the link is available for best-effort = traffic but no new time-sensitive flows can use it.

 

There's always a problem that folks may reserve reso= urces they aren't using, which could involve actual traffic as well as rese= rvations, e.g. sending video to a screen when no-one's watching it.

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

 

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet

--_000_3002A87EA61E0A4DB56546AC16A0D5171EDB9805ESESSMB103erics_-- From nobody Mon Aug 31 06:53:54 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6851B3A0B for ; Mon, 31 Aug 2015 06:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.611 X-Spam-Level: X-Spam-Status: No, score=-13.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4raUO9Zqgoa0 for ; Mon, 31 Aug 2015 06:53:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC021B3AA0 for ; Mon, 31 Aug 2015 06:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2043; q=dns/txt; s=iport; t=1441029231; x=1442238831; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4M41ulWFwEMht89OF3lSYXm6RsueNgAOIXFyRm98D0k=; b=E/8BsLwJF4mdAxDNTC/1LyrML6vudiVUoEF25WX8lIZkeN38x1N/TAQ7 LfvKzBgIbCIpPWazLEZFuvrfdAGEctE4y/LVYTbZTp0yOU4SkxYQ+PMg+ BOYKVFMgoW5UWkM/ytseWVAAhsXIHZOr+D1yF6cR/GA7QLPLtxDw/0QQV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5AgClW+RV/5pdJa1egxtUaQa+IQEJgW0KhTFKAoEjOBQBAQEBAQEBgQqEIwEBAQQBAQFiCRcEAgEIEQQBAQEKHQcnCxQJCAIEARIIiCYNxG0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZwhHuEWjgGgxKBFAWNKIgZAYx0gUmVNINsJoN/cYFIgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,441,1437436800"; d="scan'208";a="183702225" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 31 Aug 2015 13:53:50 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7VDroQ2031973 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 13:53:50 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 31 Aug 2015 08:53:50 -0500 Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 31 Aug 2015 08:53:50 -0500 Received: from xmb-rcd-x01.cisco.com ([169.254.1.191]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 08:53:50 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , "detnet@ietf.org" Thread-Topic: [Detnet] Draft charter discussion Thread-Index: AQHQ4RbZcGkqsh3E+0SwHwyIstnDX54hNbqAgATX01CAABdw8A== Date: Mon, 31 Aug 2015 13:53:49 +0000 Deferred-Delivery: Mon, 31 Aug 2015 13:53:29 +0000 Message-ID: References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> <55DF8DA0.7050908@labn.net> <55E05361.3030505@labn.net> <3002A87EA61E0A4DB56546AC16A0D5171EDB97DF@ESESSMB103.ericsson.se> In-Reply-To: <3002A87EA61E0A4DB56546AC16A0D5171EDB97DF@ESESSMB103.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 13:53:53 -0000 Hello Bala'zs=20 ... But then, some do not need to, and for some others, the critically is a= time sync in usecs, a low jitter, or a guarantee of no more than 3 losses = in a row. I'm afraid that exhibiting one property may make it appear like m= ore important than another. I find the charter balanced, but then, maybe we= could use the word "extreme" or some equivalent to reflect that " paths ca= n provide bounded latency, loss and packet delay variation (jitter)" in way= s that are beyond the traditional expectations of IP protocols. What do you think? Pascal > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga= A > Sent: lundi 31 ao=FBt 2015 14:26 > To: detnet@ietf.org > Subject: Re: [Detnet] Draft charter discussion >=20 > Hi, >=20 > I would argue for explicitly highlighting sub-millisecond requirement as > many current protocols do not deal with such a timescale. >=20 > Cheers > Bala'zs >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, August 28, 2015 2:26 PM > To: detnet@ietf.org; Janos Farkas > Subject: Re: [Detnet] Draft charter discussion >=20 > J=E1nos, (All) >=20 > I've updated the wiki based on your comments, take a look. See below for > specific response/open points. >=20 > On 8/27/2015 6:22 PM, Lou Berger wrote: > > J=E1nos, >=20 > > snips >=20 > >> 2nd paragraph: > >> - I think it is quite important that we are often going below > >> milliseconds. I'd extend "controlled latency" with "controlled low > >> latency (even sub-milliseconds)" or sg like that. > While I don't disagree with the technical point, and I think it's particu= larly > important WRT PDV/jitter, I'm not sure this level of detail really belong= s in > the charter. >=20 > What do others think? >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Aug 31 07:42:23 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E51A90E6 for ; Mon, 31 Aug 2015 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSy4frsaWY2s for ; Mon, 31 Aug 2015 07:42:19 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7653B1A0024 for ; Mon, 31 Aug 2015 07:42:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,441,1437462000"; d="scan'208";a="73695502" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 31 Aug 2015 08:04:20 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Aug 2015 07:42:18 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 31 Aug 2015 07:42:18 -0700 From: Jouni Korhonen To: "Pascal Thubert (pthubert)" , =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , "detnet@ietf.org" Thread-Topic: [Detnet] Draft charter discussion Thread-Index: AQHQ4C7agx75FbJd70OikaJxijw5854gN5aAgACrFwCAAOu9gIAEtvCAgAAYjYD//5MLYA== Date: Mon, 31 Aug 2015 14:42:17 +0000 Message-ID: <72CC502C2C615C42B081A9E5FC057D05359029@SJEXCHMB09.corp.ad.broadcom.com> References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> <55DF8DA0.7050908@labn.net> <55E05361.3030505@labn.net> <3002A87EA61E0A4DB56546AC16A0D5171EDB97DF@ESESSMB103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 14:42:21 -0000 I tend to agree with Pascal. No issue from my side having "sub-milliseconds= " mentioned as an example in the text. On the other hand we could say: "..w= ith the deterministic properties of controlled low latency, low packet loss= , low packet delay variation, and high reliability that are likely to great= ly exceed the current expectations for IP protocols." - Jouni > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, August 31, 2015 6:54 AM > To: Bal=E1zs Varga A; detnet@ietf.org > Subject: Re: [Detnet] Draft charter discussion >=20 > Hello Bala'zs >=20 > ... But then, some do not need to, and for some others, the critically is= a time > sync in usecs, a low jitter, or a guarantee of no more than 3 losses in a= row. I'm > afraid that exhibiting one property may make it appear like more importan= t than > another. I find the charter balanced, but then, maybe we could use the wo= rd > "extreme" or some equivalent to reflect that " paths can provide bounded > latency, loss and packet delay variation (jitter)" in ways that are beyon= d the > traditional expectations of IP protocols. >=20 > What do you think? >=20 > Pascal >=20 > > -----Original Message----- > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Var= ga A > > Sent: lundi 31 ao=FBt 2015 14:26 > > To: detnet@ietf.org > > Subject: Re: [Detnet] Draft charter discussion > > > > Hi, > > > > I would argue for explicitly highlighting sub-millisecond requirement a= s > > many current protocols do not deal with such a timescale. > > > > Cheers > > Bala'zs > > > > -----Original Message----- > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: Friday, August 28, 2015 2:26 PM > > To: detnet@ietf.org; Janos Farkas > > Subject: Re: [Detnet] Draft charter discussion > > > > J=E1nos, (All) > > > > I've updated the wiki based on your comments, take a look. See below f= or > > specific response/open points. > > > > On 8/27/2015 6:22 PM, Lou Berger wrote: > > > J=E1nos, > > > > > snips > > > > >> 2nd paragraph: > > >> - I think it is quite important that we are often going below > > >> milliseconds. I'd extend "controlled latency" with "controlled low > > >> latency (even sub-milliseconds)" or sg like that. > > While I don't disagree with the technical point, and I think it's parti= cularly > > important WRT PDV/jitter, I'm not sure this level of detail really belo= ngs in > > the charter. > > > > What do others think? > > > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Aug 31 08:22:11 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B041B4C7A for ; Mon, 31 Aug 2015 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agcWxvo8EYAB for ; Mon, 31 Aug 2015 08:22:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4E01B3869 for ; Mon, 31 Aug 2015 08:22:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-42-55e4711cac79 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.E4.29154.C1174E55; Mon, 31 Aug 2015 17:22:05 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.82]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 17:22:04 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Pascal Thubert (pthubert)" , "detnet@ietf.org" Thread-Topic: [Detnet] Draft charter discussion Thread-Index: AQHQ4RbZcGkqsh3E+0SwHwyIstnDX54hNbqAgATX01CAABdw8IAAFp6g Date: Mon, 31 Aug 2015 15:22:03 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EDB99B9@ESESSMB103.ericsson.se> References: <55DE0857.8010503@labn.net> <55DEFE1B.3000702@ericsson.com> <55DF8DA0.7050908@labn.net> <55E05361.3030505@labn.net> <3002A87EA61E0A4DB56546AC16A0D5171EDB97DF@ESESSMB103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja5s4ZNQg7VLmSx+f5rNYjFjyjtG ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj4od5zAVrRCq6v/9lbGA8KNDFyMkhIWAi 0b7gFROELSZx4d56ti5GLg4hgaOMEptfXwFLCAksZpT41BAEYrMJuEp87njIBmKLCERLTFq3 hbWLkYNDWEBPom+jJ0RYX+LCwZXMELabxJSmTWwgJSwCqhKbGh1BwrwCvhLvJ99jh1jVwSTx qGMDWD0nUGJl+zmw8YxA93w/tQbsBGYBcYlbT+ZD3SkgsWTPeWYIW1Ti5eN/rBC2ksSi25+h 6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93I SC+1KDO5uDg/Ty8vtWQTIzBKDm75bbWD8eBzx0OMAhyMSjy8ilsfhwqxJpYVV+YeYpTmYFES 521mehAqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTF84Vqlu5eZXvdbLtJM9UntlLm3MyZj 033L2evUC+7aP9II+uJVIdH9v5Rb+aBvSvafqXdUFni+3N0hd8o/RHm7yHv5yb5rq1+fm7a8 fKrBwoZFhx1Sg6cuTb1V8N7r7Pculf9yIvGruGpUfXJU55v/mH29ufCekWXFxUNLEhoN/rd3 inO55CixFGckGmoxFxUnAgCs4ZL0cwIAAA== Archived-At: Subject: Re: [Detnet] Draft charter discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 15:22:09 -0000 Hi Pascal, The comment on delay was not against any other parameters, just to highligh= t that "low delay" can mean even micro-sec requirements. I like your formulation " beyond the traditional expectations of IP protoco= ls " (it is valid for other parameters as well like loss, jitter, etc.). Cheers=20 Bala'zs -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, August 31, 2015 3:54 PM To: Bal=E1zs Varga A; detnet@ietf.org Subject: RE: [Detnet] Draft charter discussion Hello Bala'zs=20 ... But then, some do not need to, and for some others, the critically is a= time sync in usecs, a low jitter, or a guarantee of no more than 3 losses = in a row. I'm afraid that exhibiting one property may make it appear like m= ore important than another. I find the charter balanced, but then, maybe we= could use the word "extreme" or some equivalent to reflect that " paths ca= n provide bounded latency, loss and packet delay variation (jitter)" in way= s that are beyond the traditional expectations of IP protocols. What do you think? Pascal > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs=20 > Varga A > Sent: lundi 31 ao=FBt 2015 14:26 > To: detnet@ietf.org > Subject: Re: [Detnet] Draft charter discussion >=20 > Hi, >=20 > I would argue for explicitly highlighting sub-millisecond requirement=20 > as many current protocols do not deal with such a timescale. >=20 > Cheers > Bala'zs >=20 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, August 28, 2015 2:26 PM > To: detnet@ietf.org; Janos Farkas > Subject: Re: [Detnet] Draft charter discussion >=20 > J=E1nos, (All) >=20 > I've updated the wiki based on your comments, take a look. See below=20 > for specific response/open points. >=20 > On 8/27/2015 6:22 PM, Lou Berger wrote: > > J=E1nos, >=20 > > snips >=20 > >> 2nd paragraph: > >> - I think it is quite important that we are often going below=20 > >> milliseconds. I'd extend "controlled latency" with "controlled low=20 > >> latency (even sub-milliseconds)" or sg like that. > While I don't disagree with the technical point, and I think it's=20 > particularly important WRT PDV/jitter, I'm not sure this level of=20 > detail really belongs in the charter. >=20 > What do others think? >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Aug 31 08:33:19 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2200F1B5170 for ; Mon, 31 Aug 2015 08:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MciIG53RyTC for ; Mon, 31 Aug 2015 08:33:11 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1591A1B4E3D for ; Mon, 31 Aug 2015 08:27:57 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t7VFRuK8016443 for ; Mon, 31 Aug 2015 10:27:56 -0500 In-Reply-To: <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net>, <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> To: "detnet@ietf.org" MIME-Version: 1.0 X-KeepSent: A586E3F4:CE063DC8-86257EB2:0053C6DB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Mon, 31 Aug 2015 10:27:55 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 08/31/2015 10:27:56 AM, Serialize complete at 08/31/2015 10:27:56 AM Content-Type: multipart/alternative; boundary="=_alternative 0054F45386257EB2_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-08-31_02:, , signatures=0 Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 15:33:15 -0000 This is a multipart message in MIME format. --=_alternative 0054F45386257EB2_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgYWRkcmVzcyBhcHBsaWNhdGlvbnMgdGhh dCBuZWVkIHNvZnQtc3RhdGUgKGkuZS4gDQphdXRvbWF0aWMgcmVsZWFzZSBvZiByZXNvdXJjZXMg d2hlbiBubyBsb25nZXIgdXNlZCksIGJ1dCBJIGRvIG5vdCB0aGluayANCnRoYXQgdGhlIERldE5l dCB3b3JrIHNob3VsZCBwcm9oaWJpdCBhcHBsaWNhdGlvbnMgZnJvbSB1c2luZyBoYXJkLXN0YXRl Lg0KDQpBcyBhIHNwZWNpZmljIGV4YW1wbGUsIGNvbnNpZGVyIGEgbmV0d29yayB3aXRoaW4gYSBj YXIgdGhhdCBpcyB1c2VkIGZvciANCmN5YmVyLXBoeXNpY2FsIGNvbnRyb2wgKGUuZy4gZW5naW5l LCB0cmFuc21pc3Npb24pLiBUaGUgZGV2aWNlcyBmb3IgdGhpcyANCmFwcGxpY2F0aW9uIG5ldmVy IGNoYW5nZSwgYW5kIHRoZSBuZXR3b3JrIGNhYmxpbmcgYW5kIHJvdXRpbmcgbmV2ZXIgDQpjaGFu Z2VzLCBhbmQgdGhlcmVmb3JlIHRoZSBEZXROZXQgdHJhZmZpYyBpcyBuZXZlciBleHBlY3RlZCB0 byBjaGFuZ2UuIA0KVHJhZmZpYyBmb3Igb3RoZXIgcHVycG9zZXMgKGUuZy4gSW50ZXJuZXQgYnJv d3NpbmcpIG1heSBiZSBkZXNpcmFibGUsIGJ1dCANCml0IGlzIGRlZmluaXRlbHkgbm90IGFzIGNy aXRpY2FsLiBGb3IgdGhpcyBhcHBsaWNhdGlvbiwgbG9ja2luZyBkb3duIHRoZSANCnJlc291cmNl cyBmb3IgRGV0TmV0IHRyYWZmaWMgaXMgZGVzaXJlZC4NCg0KSW4gdGhlIFRTTiB3b3JrIHRodXMg ZmFyLCB0aGUgbWVjaGFuaXNtIGZvciBjb25maWd1cmluZyA4MDIuMVFidiBzY2hlZHVsZXMgDQpp cyBtYW5hZ2VtZW50LiBUaGUgZ2VuZXJhbCBhc3N1bXB0aW9uIGlzIHRoYXQgbWFuYWdlbWVudCBv ZiA4MDIuMVFidiBjYW4gDQpiZSBoYW5kbGVkIGluIGVpdGhlciBhIGhhcmQtc3RhdGUgb3Igc29m dC1zdGF0ZSBtYW5uZXIsIGRlcGVuZGluZyBvbiB0aGUgDQphcHBsaWNhdGlvbi4gSWYgODAyLjFR YnYgaXMgdXNlZCBpbiBhbiBJVCBuZXR3b3JrLCBJIHdvdWxkIGV4cGVjdCANCnNvZnQtc3RhdGUg dG8gYmUgdXNlZC4NCg0KVGhlIGV4aXN0aW5nIEFWQiBzdGFuZGFyZHMgaW4gdGhlIGZpZWxkICg4 MDIuMVFhdiBhbmQgODAyLjFRYXQsIGFrYSBTUlApIA0KYXJlIGVudGlyZWx5IHNvZnQtc3RhdGUs IHdpdGggU1JQIHVzaW5nIGJhbmR3aWR0aCBmb3IgQVZCIHRyYWZmaWMgb25seSANCndoZW4gQVZC IHBhY2tldHMgZXhpc3QsIGFuZCBTUlAgZnJlZWluZyBhbGwgcmVzb3VyY2VzIG9uIHRpbWVvdXQg DQooc29mdC1zdGF0ZSkuIE5ldmVydGhlbGVzcywgaW4gdGhlIGFtZW5kbWVudCB0byBTUlAgKDgw Mi4xUWNjKSwgd2UgYXJlIA0KYWRkaW5nIHRoZSBjYXBhYmlsaXR5IHRvIGNvbmZpZ3VyZSBBVkIg cmVzb3VyY2VzIHVzaW5nIG1hbmFnZW1lbnQsIHdoaWNoIA0Kd2lsbCBlbmFibGUgaGFyZC1zdGF0 ZSBhcHBsaWNhdGlvbnMuIEF1dG9tb3RpdmUgYXBwbGljYXRpb25zIG9mIEFWQiBhcmUgDQp1c2lu ZyBhIGhhcmQtc3RhdGUgYXBwcm9hY2ggYWxyZWFkeS4NCg0KUm9kbmV5DQoNCg0KDQpGcm9tOiAg IEJhbMOhenMgVmFyZ2EgQSA8YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPg0KVG86ICAgICAi ZGV0bmV0QGlldGYub3JnIiA8ZGV0bmV0QGlldGYub3JnPiwgDQpEYXRlOiAgIDA4LzMxLzIwMTUg MDc6MjggQU0NClN1YmplY3Q6ICAgICAgICBSZTogW0RldG5ldF0gRHJhZnQgRGV0TmV0IENoYXJ0 ZXINClNlbnQgYnk6ICAgICAgICAiZGV0bmV0IiA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc+DQoN Cg0KDQpIaSwNCiANCkkgYWdyZWUsIHJlbGVhc2Ugb2YgdW51c2VkIHJlc291cmNlcyBpcyBhbiBp bXBvcnRhbnQgdGFzayB0byBiZSBzb2x2ZWQgYnkgDQp0aGUgV0cuIA0KIA0KVGhlIHNpdHVhdGlv biB3aXRoIHNvbWUgVFNOIHRvb2xzIGNhbiBiZSBldmVuIHdvcnN0IHRoYW4gd2hhdCB5b3UgaGF2 ZSANCmRlc2NyaWJlZCBiZWxvdy4NCkUuZy4gdXNpbmcg4oCcODAyLjFRYnYgRW5oYW5jZW1lbnRz IGZvciBTY2hlZHVsZWQgVHJhZmZpY+KAnSBpbiBzb21lIGNhc2VzIG5vIA0Kb3RoZXIgdHJhZmZp YyAoaW5jbHVkaW5nIGJlc3QtZWZmb3J0KSBjYW4gdXNlIHRoZSByZXNlcnZlZCBiYW5kd2lkdGgu DQpTbyBpZiBZb3UgaGF2ZSByZXNlcnZlZCBhbGwgdGhlIGJhbmR3aWR0aCBidXQgYWxsIGhpZ2gg cHJpb3JpdHkgZmxvd3MgYXJlIA0KdGVybWluYXRlZCBubyB0cmFmZmljIGNhbiBjcm9zcyB5b3Vy IGxpbmsuDQpDaGVlcnMNCkJhbGHigJl6cw0KIA0KRnJvbTogZGV0bmV0IFttYWlsdG86ZGV0bmV0 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXNjYWwgVGh1YmVydCANCihwdGh1YmVy dCkNClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjksIDIwMTUgMTI6MjQgUE0NClRvOiBKb2huIEdy YW50DQpDYzogZGV0bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RldG5ldF0gRHJhZnQgRGV0 TmV0IENoYXJ0ZXINCiANClllcywgSXQgaXMgS2luZCBvZiBFYXN5IHRvIHJldXNlIGJhbmR3aWR0 aCBvdXRnb2luZyB0aGUgc3dpdGNoIGlmIHRoZXJlIA0Kd2FzIG5vIGluY29taW5nIHBhY2tldDsg d2hhdCdzIGhhcmRlciBpcyB0byBkaXNjb3ZlciB0aGF0IHRoZSBmbG93IGlzIA0KdGVybWluYXRl ZC4NCiANClRoaXMgd2lsbCBpbXBhY3QgdGhlIGZsb3cgZGVzY3JpcHRpb24gYW5kIG9yIHRoZSBw cm90b2NvbHMgKGUuZy4gDQpBc3NvY2lhdGluZyBhIGxpZmV0aW1lIGFuZCBhIGNvbnRpbnVvdXMg cmVuZXdhbCBwcm9jZXNzIHRvIHRoZSANCnJlZ2lzdHJhdGlvbikNCiANClBvaW50IHRha2VuISBJ IGFncmVlIHRoYXQgdGhpcyBkb2VzIG5vdCBpbXBhY3QgdGhlIGNoYXJ0ZXIsIHRob3VnaC4NCiAN CkNoZWVycywNCiANClBhc2NhbA0KDQoNClBhc2NhbA0KDQpMZSAyOSBhb8O7dCAyMDE1IMOgIDEy OjExLCBKb2huIEdyYW50IDxqQG5pbmV0aWxlcy5jb20+IGEgw6ljcml0IDoNCiANCk9uIDI4IEF1 ZyAyMDE1LCBhdCAyMzoxNSwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3RlOg0KDQoNCkhpIEZvbGtz LA0KSSB0aGluayB0aGUgZHJhZnQgY2hhcnRlciBsb29rcyByZWFsbHkgZ29vZCwgYW5kIGhpdHMg dGhlIHJpZ2h0IHBvaW50cy4gSSANCmhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGlzIHBocmFzZTog DQogDQoiLi4uYW5kIDIpIHJlbGVhc2UvcmV1c2UgdGhlIHJlc291cmNlcyB3aGVuIHRoZXkgYXJl IG5vIG1vcmUgcmVxdWlyZWQuLi4iIA0KIA0KT25lIG9mIHRoZSBjb25jZXJucyBhYm91dCBBVkIv VFNOIChhbmQgInJlc2VydmVkIGJhbmR3aWR0aCIgc2NoZW1lcyBpbiANCmdlbmVyYWwpIHRoYXQg SSBoZWFyZCBmcm9tIG91ciBJVCBndXlzLCBpbiB0aGUgY29udGV4dCBvZiBhIGNvcnBvcmF0ZSAN Cm5ldHdvcmssIHdhcyB0aGF0ICJvbmNlIHVzZXJzIHJlc2VydmVkIGJhbmR3aWR0aCBmb3IgdGhl IHN0cmVhbXMgdGhleSANCndhbnRlZCwgd2hlbiB0aGV5IHdlcmUgImRvbmUiIHRoZXkgd291bGQg bmV2ZXIgZ2V0IGFyb3VuZCB0byB0ZWFyaW5nIHRoZSANCnN0cmVhbXMgZG93biwgYW5kIHNvIHRo YXQgYmFuZHdpZHRoIHdvdWxkIHJlbWFpbiB1bnVzYWJsZSBieSBvdGhlcnMgb24gdGhlIA0KbmV0 d29yayIuIA0KIA0KW3NuaXBdDQoNCg0KSSBzdXBwb3NlIHN1Y2ggInN0YWxlIiByZXNlcnZlZCBi YW5kd2lkdGggd291bGQgcHJldmVudCBvdGhlcnMgZnJvbSANCnJlc2VydmluZyB0aGF0IGJhbmR3 aWR0aCwNCiANCkV4YWN0bHkgLS0gSSB0aGluayB0aGF0J3Mgd2hhdCB0aGV5J3JlIHJlZmVycmlu ZyB0bzsgeW91IGNvdWxkIGZpbmlzaCB1cCANCndpdGggYSBsaW5rIG9uIHdoaWNoIGFsbCB0aGUg YmFuZHdpZHRoIGlzIHJlc2VydmVkIGJ1dCBub25lIGlzIHVzZWQsIGluIA0Kd2hpY2ggY2FzZSAx MDAlIG9mIHRoZSBsaW5rIGlzIGF2YWlsYWJsZSBmb3IgYmVzdC1lZmZvcnQgdHJhZmZpYyBidXQg bm8gDQpuZXcgdGltZS1zZW5zaXRpdmUgZmxvd3MgY2FuIHVzZSBpdC4NCiANClRoZXJlJ3MgYWx3 YXlzIGEgcHJvYmxlbSB0aGF0IGZvbGtzIG1heSByZXNlcnZlIHJlc291cmNlcyB0aGV5IGFyZW4n dCANCnVzaW5nLCB3aGljaCBjb3VsZCBpbnZvbHZlIGFjdHVhbCB0cmFmZmljIGFzIHdlbGwgYXMg cmVzZXJ2YXRpb25zLCBlLmcuIA0Kc2VuZGluZyB2aWRlbyB0byBhIHNjcmVlbiB3aGVuIG5vLW9u ZSdzIHdhdGNoaW5nIGl0Lg0KIA0KSm9obiBHcmFudA0KTmluZSBUaWxlcywgQ2FtYnJpZGdlLCBF bmdsYW5kDQorNDQgMTIyMyA4NjI1OTkgYW5kICs0NCAxMjIzIDUxMTQ1NQ0KaHR0cDovL3d3dy5u aW5ldGlsZXMuY29tDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KZGV0bmV0IG1haWxpbmcgbGlzdA0KZGV0bmV0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg0K DQo= --=_alternative 0054F45386257EB2_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBhZGRy ZXNzIGFwcGxpY2F0aW9ucw0KdGhhdCBuZWVkIHNvZnQtc3RhdGUgKGkuZS4gYXV0b21hdGljIHJl bGVhc2Ugb2YgcmVzb3VyY2VzIHdoZW4gbm8gbG9uZ2VyDQp1c2VkKSwgYnV0IEkgZG8gbm90IHRo aW5rIHRoYXQgdGhlIERldE5ldCB3b3JrIHNob3VsZCBwcm9oaWJpdCBhcHBsaWNhdGlvbnMNCmZy b20gdXNpbmcgaGFyZC1zdGF0ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkFzIGEgc3BlY2lmaWMgZXhhbXBsZSwgY29uc2lkZXIgYSBuZXR3b3JrDQp3 aXRoaW4gYSBjYXIgdGhhdCBpcyB1c2VkIGZvciBjeWJlci1waHlzaWNhbCBjb250cm9sIChlLmcu IGVuZ2luZSwgdHJhbnNtaXNzaW9uKS4NClRoZSBkZXZpY2VzIGZvciB0aGlzIGFwcGxpY2F0aW9u IG5ldmVyIGNoYW5nZSwgYW5kIHRoZSBuZXR3b3JrIGNhYmxpbmcNCmFuZCByb3V0aW5nIG5ldmVy IGNoYW5nZXMsIGFuZCB0aGVyZWZvcmUgdGhlIERldE5ldCB0cmFmZmljIGlzIG5ldmVyIGV4cGVj dGVkDQp0byBjaGFuZ2UuIFRyYWZmaWMgZm9yIG90aGVyIHB1cnBvc2VzIChlLmcuIEludGVybmV0 IGJyb3dzaW5nKSBtYXkgYmUgZGVzaXJhYmxlLA0KYnV0IGl0IGlzIGRlZmluaXRlbHkgbm90IGFz IGNyaXRpY2FsLiBGb3IgdGhpcyBhcHBsaWNhdGlvbiwgbG9ja2luZyBkb3duDQp0aGUgcmVzb3Vy Y2VzIGZvciBEZXROZXQgdHJhZmZpYyBpcyBkZXNpcmVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gdGhlIFRTTiB3b3JrIHRodXMgZmFyLCB0aGUg bWVjaGFuaXNtDQpmb3IgY29uZmlndXJpbmcgODAyLjFRYnYgc2NoZWR1bGVzIGlzIG1hbmFnZW1l bnQuIFRoZSBnZW5lcmFsIGFzc3VtcHRpb24NCmlzIHRoYXQgbWFuYWdlbWVudCBvZiA4MDIuMVFi diBjYW4gYmUgaGFuZGxlZCBpbiBlaXRoZXIgYSBoYXJkLXN0YXRlIG9yDQpzb2Z0LXN0YXRlIG1h bm5lciwgZGVwZW5kaW5nIG9uIHRoZSBhcHBsaWNhdGlvbi4gSWYgODAyLjFRYnYgaXMgdXNlZCBp bg0KYW4gSVQgbmV0d29yaywgSSB3b3VsZCBleHBlY3Qgc29mdC1zdGF0ZSB0byBiZSB1c2VkLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGV4aXN0 aW5nIEFWQiBzdGFuZGFyZHMgaW4gdGhlIGZpZWxkDQooODAyLjFRYXYgYW5kIDgwMi4xUWF0LCBh a2EgU1JQKSBhcmUgZW50aXJlbHkgc29mdC1zdGF0ZSwgd2l0aCBTUlAgdXNpbmcNCmJhbmR3aWR0 aCBmb3IgQVZCIHRyYWZmaWMgb25seSB3aGVuIEFWQiBwYWNrZXRzIGV4aXN0LCBhbmQgU1JQIGZy ZWVpbmcNCmFsbCByZXNvdXJjZXMgb24gdGltZW91dCAoc29mdC1zdGF0ZSkuIE5ldmVydGhlbGVz cywgaW4gdGhlIGFtZW5kbWVudCB0bw0KU1JQICg4MDIuMVFjYyksIHdlIGFyZSBhZGRpbmcgdGhl IGNhcGFiaWxpdHkgdG8gY29uZmlndXJlIEFWQiByZXNvdXJjZXMNCnVzaW5nIG1hbmFnZW1lbnQs IHdoaWNoIHdpbGwgZW5hYmxlIGhhcmQtc3RhdGUgYXBwbGljYXRpb25zLiBBdXRvbW90aXZlDQph cHBsaWNhdGlvbnMgb2YgQVZCIGFyZSB1c2luZyBhIGhhcmQtc3RhdGUgYXBwcm9hY2ggYWxyZWFk eS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJvZG5l eTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9m b250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5CYWzDoXpzIFZhcmdhIEEgJmx0O2Jh bGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2RldG5ldEBp ZXRmLm9yZyZxdW90Ow0KJmx0O2RldG5ldEBpZXRmLm9yZyZndDssIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4w OC8zMS8yMDE1IDA3OjI4IEFNPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVm IGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRGV0bmV0XQ0KRHJhZnQg RGV0TmV0IENoYXJ0ZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFj ZT0ic2Fucy1zZXJpZiI+U2VudCBieTogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZGV0bmV0JnF1b3Q7DQombHQ7 ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+ SGksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj5JIGFncmVlLCByZWxlYXNlIG9mIHVudXNlZA0KcmVzb3VyY2VzIGlzIGFuIGltcG9ydGFu dCB0YXNrIHRvIGJlIHNvbHZlZCBieSB0aGUgV0cuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+VGhlIHNpdHVhdGlvbiB3aXRoIHNvbWUg VFNODQp0b29scyBjYW4gYmUgZXZlbiB3b3JzdCB0aGFuIHdoYXQgeW91IGhhdmUgZGVzY3JpYmVk IGJlbG93LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj5FLmcuIHVzaW5nIOKAnDgwMi4xUWJ2IEVuaGFuY2VtZW50cw0KZm9yIFNjaGVkdWxlZCBU cmFmZmlj4oCdIGluIHNvbWUgY2FzZXMgbm8gb3RoZXIgdHJhZmZpYyAoaW5jbHVkaW5nIGJlc3Qt ZWZmb3J0KQ0KY2FuIHVzZSB0aGUgcmVzZXJ2ZWQgYmFuZHdpZHRoLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5TbyBpZiBZb3UgaGF2ZSByZXNl cnZlZCBhbGwNCnRoZSBiYW5kd2lkdGggYnV0IGFsbCBoaWdoIHByaW9yaXR5IGZsb3dzIGFyZSB0 ZXJtaW5hdGVkIG5vIHRyYWZmaWMgY2FuDQpjcm9zcyB5b3VyIGxpbmsuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkNoZWVyczwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5CYWxh4oCZenM8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBkZXRu ZXQgWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmciPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPm1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Q YXNjYWwgVGh1YmVydCAocHRodWJlcnQpPGI+PGJyPg0KU2VudDo8L2I+IFNhdHVyZGF5LCBBdWd1 c3QgMjksIDIwMTUgMTI6MjQgUE08Yj48YnI+DQpUbzo8L2I+IEpvaG4gR3JhbnQ8Yj48YnI+DQpD Yzo8L2I+IGRldG5ldEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0RldG5ldF0g RHJhZnQgRGV0TmV0IENoYXJ0ZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPlllcywgSXQgaXMgS2luZCBvZiBFYXN5IHRvIHJldXNlDQpiYW5kd2lkdGggb3V0 Z29pbmcgdGhlIHN3aXRjaCBpZiB0aGVyZSB3YXMgbm8gaW5jb21pbmcgcGFja2V0OyB3aGF0J3Mg aGFyZGVyDQppcyB0byBkaXNjb3ZlciB0aGF0IHRoZSBmbG93IGlzIHRlcm1pbmF0ZWQuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGlzIHdpbGwgaW1wYWN0 IHRoZSBmbG93IGRlc2NyaXB0aW9uDQphbmQgb3IgdGhlIHByb3RvY29scyAoZS5nLiBBc3NvY2lh dGluZyBhIGxpZmV0aW1lIGFuZCBhIGNvbnRpbnVvdXMgcmVuZXdhbA0KcHJvY2VzcyB0byB0aGUg cmVnaXN0cmF0aW9uKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+UG9pbnQgdGFrZW4hIEkgYWdyZWUgdGhhdCB0aGlzDQpkb2VzIG5vdCBpbXBhY3QgdGhlIGNo YXJ0ZXIsIHRob3VnaC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPkNoZWVycyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PlBhc2NhbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQo8YnI+DQpQYXNjYWw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KTGUgMjkgYW/Du3QgMjAxNSDDoCAxMjoxMSwgSm9obiBHcmFudCAmbHQ7 PC9mb250PjxhIGhyZWY9bWFpbHRvOmpAbmluZXRpbGVzLmNvbT48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1PmpAbmluZXRpbGVzLmNvbTwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZndDsNCmEgw6ljcml0IDo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk9uIDI4IEF1ZyAy MDE1LCBhdCAyMzoxNSwgR3Jvc3NtYW4sDQpFdGhhbiBBLiB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhpIEZvbGtzLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHRoaW5rIHRoZSBkcmFmdCBjaGFydGVy IGxvb2tzDQpyZWFsbHkgZ29vZCwgYW5kIGhpdHMgdGhlIHJpZ2h0IHBvaW50cy4gSSBoYXZlIGEg cXVlc3Rpb24gYWJvdXQgdGhpcyBwaHJhc2U6DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZxdW90Oy4uLmFuZCAyKSByZWxlYXNlL3JldXNlIHRoZQ0KcmVz b3VyY2VzIHdoZW4gdGhleSBhcmUgbm8gbW9yZSByZXF1aXJlZC4uLiZxdW90OzwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+T25lIG9mIHRoZSBjb25jZXJucyBhYm91dCBBVkIvVFNODQooYW5kICZxdW90O3Jlc2Vy dmVkIGJhbmR3aWR0aCZxdW90OyBzY2hlbWVzIGluIGdlbmVyYWwpIHRoYXQgSSBoZWFyZCBmcm9t DQpvdXIgSVQgZ3V5cywgaW4gdGhlIGNvbnRleHQgb2YgYSBjb3Jwb3JhdGUgbmV0d29yaywgd2Fz IHRoYXQgJnF1b3Q7b25jZQ0KdXNlcnMgcmVzZXJ2ZWQgYmFuZHdpZHRoIGZvciB0aGUgc3RyZWFt cyB0aGV5IHdhbnRlZCwgd2hlbiB0aGV5IHdlcmUgJnF1b3Q7ZG9uZSZxdW90Ow0KdGhleSB3b3Vs ZCBuZXZlciBnZXQgYXJvdW5kIHRvIHRlYXJpbmcgdGhlIHN0cmVhbXMgZG93biwgYW5kIHNvIHRo YXQgYmFuZHdpZHRoDQp3b3VsZCByZW1haW4gdW51c2FibGUgYnkgb3RoZXJzIG9uIHRoZSBuZXR3 b3JrJnF1b3Q7LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PltzbmlwXTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SSBz dXBwb3NlIHN1Y2ggJnF1b3Q7c3RhbGUmcXVvdDsNCnJlc2VydmVkIGJhbmR3aWR0aCB3b3VsZCBw cmV2ZW50IG90aGVycyBmcm9tIHJlc2VydmluZyB0aGF0IGJhbmR3aWR0aCw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkV4YWN0bHkgLS0gSSB0aGluayB0aGF0 J3Mgd2hhdA0KdGhleSdyZSByZWZlcnJpbmcgdG87IHlvdSBjb3VsZCBmaW5pc2ggdXAgd2l0aCBh IGxpbmsgb24gd2hpY2ggYWxsIHRoZQ0KYmFuZHdpZHRoIGlzIHJlc2VydmVkIGJ1dCBub25lIGlz IHVzZWQsIGluIHdoaWNoIGNhc2UgMTAwJSBvZiB0aGUgbGluaw0KaXMgYXZhaWxhYmxlIGZvciBi ZXN0LWVmZm9ydCB0cmFmZmljIGJ1dCBubyBuZXcgdGltZS1zZW5zaXRpdmUgZmxvd3MgY2FuDQp1 c2UgaXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGVy ZSdzIGFsd2F5cyBhIHByb2JsZW0gdGhhdCBmb2xrcw0KbWF5IHJlc2VydmUgcmVzb3VyY2VzIHRo ZXkgYXJlbid0IHVzaW5nLCB3aGljaCBjb3VsZCBpbnZvbHZlIGFjdHVhbCB0cmFmZmljDQphcyB3 ZWxsIGFzIHJlc2VydmF0aW9ucywgZS5nLiBzZW5kaW5nIHZpZGVvIHRvIGEgc2NyZWVuIHdoZW4g bm8tb25lJ3Mgd2F0Y2hpbmcNCml0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT00IGZhY2U9InNhbnMt c2VyaWYiPkpvaG4gR3JhbnQ8YnI+DQpOaW5lIFRpbGVzLCBDYW1icmlkZ2UsIEVuZ2xhbmQ8YnI+ DQorNDQgMTIyMyA4NjI1OTkgYW5kICs0NCAxMjIzIDUxMTQ1NTwvZm9udD48Zm9udCBzaXplPTQg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9 aHR0cDovL3d3dy5uaW5ldGlsZXMuY29tLz48Zm9udCBzaXplPTQgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT5odHRwOi8vd3d3Lm5pbmV0aWxlcy5jb208L3U+PC9mb250PjwvYT4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkZXRuZXQgbWFpbGluZyBsaXN0PC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPW1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5kZXRuZXRAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RldG5ldD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC91Pjwv Zm9udD48L2E+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCmRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQpkZXRuZXRAaWV0 Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGV0bmV0Pjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0054F45386257EB2_=-- From nobody Mon Aug 31 10:53:08 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6E11A8AF0 for ; Mon, 31 Aug 2015 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x3Gg4FEsOQk for ; Mon, 31 Aug 2015 10:53:02 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC21A898D for ; Mon, 31 Aug 2015 10:52:54 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,442,1437462000"; d="scan'208,217"; a="73868571" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 31 Aug 2015 11:16:04 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Aug 2015 10:52:54 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 31 Aug 2015 10:52:54 -0700 From: "Pat (Patricia) Thaler" To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , "detnet@ietf.org" Thread-Topic: [Detnet] Draft DetNet Charter Thread-Index: AdDh2/0oQ4rd4u/SSNquI+3KOK24qQAocbIAAABt+QAAaO1HgAADuClw Date: Mon, 31 Aug 2015 17:52:53 +0000 Message-ID: References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net>, <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> In-Reply-To: <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B2D7DSJEXCHMB09corpa_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 17:53:06 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B2D7DSJEXCHMB09corpa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Release of unused bandwidth is important. As far as TSN, currently the reservations use MSRP or MMRP (802.1 reservati= on protocols) which require periodic refreshes to keep the reservation aliv= e. A current project 802.1Qcc is increasing the time out because the traffi= c from the protocol becomes excessive in a large subnet. Whether the bandwidth is reusable by other traffic when the reserved bandwi= dth isn't used depends on which 802.1 protocol is being used. If it is jus= t credit-based shaper and strict priority that is being used to ensure the = bandwidth, then other traffic can use the bandwidth. This is the protocol d= efined by the original AVB work and it provides for limiting latency and ji= tter. But for cases where tighter latency control is required (e.g. control loops= for automotive and industrial), the enhancements for scheduled traffic gat= es off transmission from other traffic classes so that the scheduled traffi= c can be sent exactly on schedule. Even in the first case, terminating reservations for flows that had finishe= d would be important for keeping a build-up of stale context in the routing= /switching devices and for freeing the bandwidth for new reservations. Regards, Pat From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A Sent: Monday, August 31, 2015 5:28 AM To: detnet@ietf.org Subject: Re: [Detnet] Draft DetNet Charter Hi, I agree, release of unused resources is an important task to be solved by t= he WG. The situation with some TSN tools can be even worst than what you have desc= ribed below. E.g. using "802.1Qbv Enhancements for Scheduled Traffic" in some cases no o= ther traffic (including best-effort) can use the reserved bandwidth. So if You have reserved all the bandwidth but all high priority flows are t= erminated no traffic can cross your link. Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Saturday, August 29, 2015 12:24 PM To: John Grant Cc: detnet@ietf.org Subject: Re: [Detnet] Draft DetNet Charter Yes, It is Kind of Easy to reuse bandwidth outgoing the switch if there was= no incoming packet; what's harder is to discover that the flow is terminat= ed. This will impact the flow description and or the protocols (e.g. Associatin= g a lifetime and a continuous renewal process to the registration) Point taken! I agree that this does not impact the charter, though. Cheers, Pascal Pascal Le 29 ao=FBt 2015 =E0 12:11, John Grant > a =E9crit : On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote: Hi Folks, I think the draft charter looks really good, and hits the right points. I h= ave a question about this phrase: "...and 2) release/reuse the resources when they are no more required..." One of the concerns about AVB/TSN (and "reserved bandwidth" schemes in gene= ral) that I heard from our IT guys, in the context of a corporate network, = was that "once users reserved bandwidth for the streams they wanted, when t= hey were "done" they would never get around to tearing the streams down, an= d so that bandwidth would remain unusable by others on the network". [snip] I suppose such "stale" reserved bandwidth would prevent others from reservi= ng that bandwidth, Exactly -- I think that's what they're referring to; you could finish up wi= th a link on which all the bandwidth is reserved but none is used, in which= case 100% of the link is available for best-effort traffic but no new time= -sensitive flows can use it. There's always a problem that folks may reserve resources they aren't using= , which could involve actual traffic as well as reservations, e.g. sending = video to a screen when no-one's watching it. John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B2D7DSJEXCHMB09corpa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Release of unused bandwidth is importan= t.

 

As far as TSN, currently the reservatio= ns use MSRP or MMRP (802.1 reservation protocols) which require periodic re= freshes to keep the reservation alive. A current project 802.1Qcc is increasing the time out because the traffic from the protocol = becomes excessive in a large subnet.

 

Whether the bandwidth is reusable by ot= her traffic when the reserved bandwidth isn’t used depends on which 8= 02.1 protocol is being used.  If it is just credit-based shaper and strict priority that is being used to ensure the bandwidth, then other= traffic can use the bandwidth. This is the protocol defined by the origina= l AVB work and it provides for limiting latency and jitter.

 

But for cases where tighter latency con= trol is required (e.g. control loops for automotive and industrial), the en= hancements for scheduled traffic gates off transmission from other traffic classes so that the scheduled traffic can be sent exact= ly on schedule.

 

Even in the first case, terminating res= ervations for flows that had finished would be important for keeping a buil= d-up of stale context in the routing/switching devices and for freeing the bandwidth for new reservations.

 

Regards,

Pat

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A
Sent: Monday, August 31, 2015 5:28 AM
To: detnet@ietf.org
Subject: Re: [Detnet] Draft DetNet Charter

 

Hi,

 <= /p>

I agree, release of unuse= d resources is an important task to be solved by the WG.

 <= /p>

The situation with some T= SN tools can be even worst than what you have described below.<= /o:p>

E.g. using “802.1Qb= v Enhancements for Scheduled Traffic” in some cases no other traffic = (including best-effort) can use the reserved bandwidth.

So if You have reserved a= ll the bandwidth but all high priority flows are terminated no traffic can = cross your link.

Cheers<= /p>

Bala’zs=

 <= /p>

 

Yes, It is Kind of Easy to reuse bandwidth outgoing = the switch if there was no incoming packet; what's harder is to discover th= at the flow is terminated.

 

This will impact the flow description and or the pro= tocols (e.g. Associating a lifetime and a continuous renewal process to the= registration)

 

Point taken! I agree that this does not impact the c= harter, though.

 

Cheers,

 

Pascal



Pascal


Le 29 ao=FBt 2015 =E0 12:11, John Grant <j@ninetiles.com> a =E9crit :

 

On 28 Aug 2015, at 23:15, Grossman, Ethan A. wrote:<= o:p>




Hi Folks,

I think the draft charter looks really good, and hits the right p= oints. I have a question about this phrase: 

 

"...and 2) release/reuse the resources when they are no more= required..."

 

One of = the concerns about AVB/TSN (and "reserved bandwidth" schemes in g= eneral) that I heard from our IT guys, in the context of a corporate networ= k, was that "once users reserved bandwidth for the streams they wanted, when they were "done" they would never = get around to tearing the streams down, and so that bandwidth would remain = unusable by others on the network". 

 

[snip]




I suppo= se such "stale" reserved bandwidth would prevent others from rese= rving that bandwidth,

 

Exactly -- I think that's what they're referring to;= you could finish up with a link on which all the bandwidth is reserved but= none is used, in which case 100% of the link is available for best-effort = traffic but no new time-sensitive flows can use it.

 

There's always a problem that folks may reserve reso= urces they aren't using, which could involve actual traffic as well as rese= rvations, e.g. sending video to a screen when no-one's watching it.

 

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

 

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet

--_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B2D7DSJEXCHMB09corpa_-- From nobody Mon Aug 31 19:18:07 2015 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46A51B73FA for ; Mon, 31 Aug 2015 19:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvbzhBWaIhV4 for ; Mon, 31 Aug 2015 19:18:03 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6971B4100 for ; Mon, 31 Aug 2015 19:18:03 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,446,1437462000"; d="scan'208,217"; a="73762349" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 31 Aug 2015 19:40:07 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Aug 2015 19:18:01 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 31 Aug 2015 19:18:00 -0700 From: "Pat (Patricia) Thaler" To: "rodney.cummings@ni.com" , "detnet@ietf.org" Thread-Topic: [Detnet] Draft DetNet Charter Thread-Index: AdDh2/0oQ4rd4u/SSNquI+3KOK24qQAocbIAAABt+QAAaO1HgAAGRcCAAActHdA= Date: Tue, 1 Sep 2015 02:18:00 +0000 Message-ID: References: <6CE1AE4935C63549B80243EE77A7246E0109CEBB1C@DLB-XCHPW02.dolby.net>, <24DD07B7-239B-4A00-B19D-627447B656E1@cisco.com> <3002A87EA61E0A4DB56546AC16A0D5171EDB9805@ESESSMB103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B375ASJEXCHMB09corpa_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Draft DetNet Charter X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 02:18:05 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B375ASJEXCHMB09corpa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9kbmV5LA0KDQpUaGUgY2hhcnRlciB0ZXh0IHNheXM6DQoiLi4uYW5kIDIpIHJlbGVhc2Uv cmV1c2UgdGhlIHJlc291cmNlcyB3aGVuIHRoZXkgYXJlIG5vIG1vcmUgcmVxdWlyZWQuLi4iDQp3 aGljaCBzYXlzIG5vdGhpbmcgYWJvdXQgYXV0b21hdGljIHJlbGVhc2Ugb2YgcmVzb3VyY2VzLiBX aGVuIHJlc2VydmF0aW9ucyBhcmUgc2V0IHVwIGJ5IG1hbmFnZW1lbnQsIG1hbmFnZW1lbnQgd291 bGQgYWxzbyBoYXZlIGEgd2F5IHRvIHJlbGVhc2UgdGhlIHJlc291cmNlLiBUaGUgdGV4dCBhcHBs aWVzIGVxdWFsbHkgdG8gbWFuYWdlbWVudCBvciB0aGUgYmFuZHdpZHRoIGNvbnN1bWVyIGV4cGxp Y2l0bHkgcmVsZWFzaW5nIGJhbmR3aWR0aCBhcyB3ZWxsIGFzIHRvIGNhc2VzIHdoZXJlIGF1dG9t YXRpYyByZWxlYXNlIG9jY3Vycy4NCg0KSXQgaXMgbW9yZSBsaWtlbHkgdGhhdCBhbiBpbiBjYXIg Y29udHJvbCBwYXRoIHdvdWxkIGJlIGxheWVyIDIgYW5kIGNvdmVyZWQgYnkgdGhlIHdvcmsgSUVF RSA4MDIuMSBpcyBkb2luZy4gIFRoZSBidWlsZGluZyBtb25pdG9yaW5nIGFuZCBjb250cm9sIHVz ZSBjYXNlIGlzIGFuIGV4YW1wbGUgd2hlcmUgTGF5ZXIgMyB3aXRoIHNvbWUgb2YgdGhlIGNvbmZp Z3VyYXRpb24gcmVsYXRpdmVseSBzdGF0aWMgKHNlY3VyaXR5IG1vbml0b3Jpbmcgc3lzdGVtcywg ZW52aXJvbm1lbnRhbCBjb250cm9sLCBldGMuKS4gT3IgY29udHJvbCBvbiBhIG1hbnVmYWN0dXJp bmcgbGluZS4NCg0KUmVnYXJkcywNClBhdA0KDQpGcm9tOiBkZXRuZXQgW21haWx0bzpkZXRuZXQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvZG5leSBDdW1taW5ncw0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMzEsIDIwMTUgODoyOCBBTQ0KVG86IGRldG5ldEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtEZXRuZXRdIERyYWZ0IERldE5ldCBDaGFydGVyDQoNCkhlbGxvLA0KDQpJIGFncmVl IHRoYXQgd2Ugc2hvdWxkIGFkZHJlc3MgYXBwbGljYXRpb25zIHRoYXQgbmVlZCBzb2Z0LXN0YXRl IChpLmUuIGF1dG9tYXRpYyByZWxlYXNlIG9mIHJlc291cmNlcyB3aGVuIG5vIGxvbmdlciB1c2Vk KSwgYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIERldE5ldCB3b3JrIHNob3VsZCBwcm9oaWJp dCBhcHBsaWNhdGlvbnMgZnJvbSB1c2luZyBoYXJkLXN0YXRlLg0KDQpBcyBhIHNwZWNpZmljIGV4 YW1wbGUsIGNvbnNpZGVyIGEgbmV0d29yayB3aXRoaW4gYSBjYXIgdGhhdCBpcyB1c2VkIGZvciBj eWJlci1waHlzaWNhbCBjb250cm9sIChlLmcuIGVuZ2luZSwgdHJhbnNtaXNzaW9uKS4gVGhlIGRl dmljZXMgZm9yIHRoaXMgYXBwbGljYXRpb24gbmV2ZXIgY2hhbmdlLCBhbmQgdGhlIG5ldHdvcmsg Y2FibGluZyBhbmQgcm91dGluZyBuZXZlciBjaGFuZ2VzLCBhbmQgdGhlcmVmb3JlIHRoZSBEZXRO ZXQgdHJhZmZpYyBpcyBuZXZlciBleHBlY3RlZCB0byBjaGFuZ2UuIFRyYWZmaWMgZm9yIG90aGVy IHB1cnBvc2VzIChlLmcuIEludGVybmV0IGJyb3dzaW5nKSBtYXkgYmUgZGVzaXJhYmxlLCBidXQg aXQgaXMgZGVmaW5pdGVseSBub3QgYXMgY3JpdGljYWwuIEZvciB0aGlzIGFwcGxpY2F0aW9uLCBs b2NraW5nIGRvd24gdGhlIHJlc291cmNlcyBmb3IgRGV0TmV0IHRyYWZmaWMgaXMgZGVzaXJlZC4N Cg0KSW4gdGhlIFRTTiB3b3JrIHRodXMgZmFyLCB0aGUgbWVjaGFuaXNtIGZvciBjb25maWd1cmlu ZyA4MDIuMVFidiBzY2hlZHVsZXMgaXMgbWFuYWdlbWVudC4gVGhlIGdlbmVyYWwgYXNzdW1wdGlv biBpcyB0aGF0IG1hbmFnZW1lbnQgb2YgODAyLjFRYnYgY2FuIGJlIGhhbmRsZWQgaW4gZWl0aGVy IGEgaGFyZC1zdGF0ZSBvciBzb2Z0LXN0YXRlIG1hbm5lciwgZGVwZW5kaW5nIG9uIHRoZSBhcHBs aWNhdGlvbi4gSWYgODAyLjFRYnYgaXMgdXNlZCBpbiBhbiBJVCBuZXR3b3JrLCBJIHdvdWxkIGV4 cGVjdCBzb2Z0LXN0YXRlIHRvIGJlIHVzZWQuDQoNClRoZSBleGlzdGluZyBBVkIgc3RhbmRhcmRz IGluIHRoZSBmaWVsZCAoODAyLjFRYXYgYW5kIDgwMi4xUWF0LCBha2EgU1JQKSBhcmUgZW50aXJl bHkgc29mdC1zdGF0ZSwgd2l0aCBTUlAgdXNpbmcgYmFuZHdpZHRoIGZvciBBVkIgdHJhZmZpYyBv bmx5IHdoZW4gQVZCIHBhY2tldHMgZXhpc3QsIGFuZCBTUlAgZnJlZWluZyBhbGwgcmVzb3VyY2Vz IG9uIHRpbWVvdXQgKHNvZnQtc3RhdGUpLiBOZXZlcnRoZWxlc3MsIGluIHRoZSBhbWVuZG1lbnQg dG8gU1JQICg4MDIuMVFjYyksIHdlIGFyZSBhZGRpbmcgdGhlIGNhcGFiaWxpdHkgdG8gY29uZmln dXJlIEFWQiByZXNvdXJjZXMgdXNpbmcgbWFuYWdlbWVudCwgd2hpY2ggd2lsbCBlbmFibGUgaGFy ZC1zdGF0ZSBhcHBsaWNhdGlvbnMuIEF1dG9tb3RpdmUgYXBwbGljYXRpb25zIG9mIEFWQiBhcmUg dXNpbmcgYSBoYXJkLXN0YXRlIGFwcHJvYWNoIGFscmVhZHkuDQoNClJvZG5leQ0KDQoNCg0KRnJv bTogICAgICAgIEJhbMOhenMgVmFyZ2EgQSA8YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPG1h aWx0bzpiYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb20+Pg0KVG86ICAgICAgICAiZGV0bmV0QGll dGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+IiA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpk ZXRuZXRAaWV0Zi5vcmc+PiwNCkRhdGU6ICAgICAgICAwOC8zMS8yMDE1IDA3OjI4IEFNDQpTdWJq ZWN0OiAgICAgICAgUmU6IFtEZXRuZXRdIERyYWZ0IERldE5ldCBDaGFydGVyDQpTZW50IGJ5OiAg ICAgICAgImRldG5ldCIgPGRldG5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91 bmNlc0BpZXRmLm9yZz4+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0K SGksDQoNCkkgYWdyZWUsIHJlbGVhc2Ugb2YgdW51c2VkIHJlc291cmNlcyBpcyBhbiBpbXBvcnRh bnQgdGFzayB0byBiZSBzb2x2ZWQgYnkgdGhlIFdHLg0KDQpUaGUgc2l0dWF0aW9uIHdpdGggc29t ZSBUU04gdG9vbHMgY2FuIGJlIGV2ZW4gd29yc3QgdGhhbiB3aGF0IHlvdSBoYXZlIGRlc2NyaWJl ZCBiZWxvdy4NCkUuZy4gdXNpbmcg4oCcODAyLjFRYnYgRW5oYW5jZW1lbnRzIGZvciBTY2hlZHVs ZWQgVHJhZmZpY+KAnSBpbiBzb21lIGNhc2VzIG5vIG90aGVyIHRyYWZmaWMgKGluY2x1ZGluZyBi ZXN0LWVmZm9ydCkgY2FuIHVzZSB0aGUgcmVzZXJ2ZWQgYmFuZHdpZHRoLg0KU28gaWYgWW91IGhh dmUgcmVzZXJ2ZWQgYWxsIHRoZSBiYW5kd2lkdGggYnV0IGFsbCBoaWdoIHByaW9yaXR5IGZsb3dz IGFyZSB0ZXJtaW5hdGVkIG5vIHRyYWZmaWMgY2FuIGNyb3NzIHlvdXIgbGluay4NCkNoZWVycw0K QmFsYeKAmXpzDQoNCkZyb206IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogU2F0dXJkYXks IEF1Z3VzdCAyOSwgMjAxNSAxMjoyNCBQTQ0KVG86IEpvaG4gR3JhbnQNCkNjOiBkZXRuZXRAaWV0 Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBEcmFm dCBEZXROZXQgQ2hhcnRlcg0KDQpZZXMsIEl0IGlzIEtpbmQgb2YgRWFzeSB0byByZXVzZSBiYW5k d2lkdGggb3V0Z29pbmcgdGhlIHN3aXRjaCBpZiB0aGVyZSB3YXMgbm8gaW5jb21pbmcgcGFja2V0 OyB3aGF0J3MgaGFyZGVyIGlzIHRvIGRpc2NvdmVyIHRoYXQgdGhlIGZsb3cgaXMgdGVybWluYXRl ZC4NCg0KVGhpcyB3aWxsIGltcGFjdCB0aGUgZmxvdyBkZXNjcmlwdGlvbiBhbmQgb3IgdGhlIHBy b3RvY29scyAoZS5nLiBBc3NvY2lhdGluZyBhIGxpZmV0aW1lIGFuZCBhIGNvbnRpbnVvdXMgcmVu ZXdhbCBwcm9jZXNzIHRvIHRoZSByZWdpc3RyYXRpb24pDQoNClBvaW50IHRha2VuISBJIGFncmVl IHRoYXQgdGhpcyBkb2VzIG5vdCBpbXBhY3QgdGhlIGNoYXJ0ZXIsIHRob3VnaC4NCg0KQ2hlZXJz LA0KDQpQYXNjYWwNCg0KDQpQYXNjYWwNCg0KTGUgMjkgYW/Du3QgMjAxNSDDoCAxMjoxMSwgSm9o biBHcmFudCA8akBuaW5ldGlsZXMuY29tPG1haWx0bzpqQG5pbmV0aWxlcy5jb20+PiBhIMOpY3Jp dCA6DQoNCk9uIDI4IEF1ZyAyMDE1LCBhdCAyMzoxNSwgR3Jvc3NtYW4sIEV0aGFuIEEuIHdyb3Rl Og0KDQoNCkhpIEZvbGtzLA0KSSB0aGluayB0aGUgZHJhZnQgY2hhcnRlciBsb29rcyByZWFsbHkg Z29vZCwgYW5kIGhpdHMgdGhlIHJpZ2h0IHBvaW50cy4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQg dGhpcyBwaHJhc2U6DQoNCiIuLi5hbmQgMikgcmVsZWFzZS9yZXVzZSB0aGUgcmVzb3VyY2VzIHdo ZW4gdGhleSBhcmUgbm8gbW9yZSByZXF1aXJlZC4uLiINCg0KT25lIG9mIHRoZSBjb25jZXJucyBh Ym91dCBBVkIvVFNOIChhbmQgInJlc2VydmVkIGJhbmR3aWR0aCIgc2NoZW1lcyBpbiBnZW5lcmFs KSB0aGF0IEkgaGVhcmQgZnJvbSBvdXIgSVQgZ3V5cywgaW4gdGhlIGNvbnRleHQgb2YgYSBjb3Jw b3JhdGUgbmV0d29yaywgd2FzIHRoYXQgIm9uY2UgdXNlcnMgcmVzZXJ2ZWQgYmFuZHdpZHRoIGZv ciB0aGUgc3RyZWFtcyB0aGV5IHdhbnRlZCwgd2hlbiB0aGV5IHdlcmUgImRvbmUiIHRoZXkgd291 bGQgbmV2ZXIgZ2V0IGFyb3VuZCB0byB0ZWFyaW5nIHRoZSBzdHJlYW1zIGRvd24sIGFuZCBzbyB0 aGF0IGJhbmR3aWR0aCB3b3VsZCByZW1haW4gdW51c2FibGUgYnkgb3RoZXJzIG9uIHRoZSBuZXR3 b3JrIi4NCg0KW3NuaXBdDQoNCg0KSSBzdXBwb3NlIHN1Y2ggInN0YWxlIiByZXNlcnZlZCBiYW5k d2lkdGggd291bGQgcHJldmVudCBvdGhlcnMgZnJvbSByZXNlcnZpbmcgdGhhdCBiYW5kd2lkdGgs DQoNCkV4YWN0bHkgLS0gSSB0aGluayB0aGF0J3Mgd2hhdCB0aGV5J3JlIHJlZmVycmluZyB0bzsg eW91IGNvdWxkIGZpbmlzaCB1cCB3aXRoIGEgbGluayBvbiB3aGljaCBhbGwgdGhlIGJhbmR3aWR0 aCBpcyByZXNlcnZlZCBidXQgbm9uZSBpcyB1c2VkLCBpbiB3aGljaCBjYXNlIDEwMCUgb2YgdGhl IGxpbmsgaXMgYXZhaWxhYmxlIGZvciBiZXN0LWVmZm9ydCB0cmFmZmljIGJ1dCBubyBuZXcgdGlt ZS1zZW5zaXRpdmUgZmxvd3MgY2FuIHVzZSBpdC4NCg0KVGhlcmUncyBhbHdheXMgYSBwcm9ibGVt IHRoYXQgZm9sa3MgbWF5IHJlc2VydmUgcmVzb3VyY2VzIHRoZXkgYXJlbid0IHVzaW5nLCB3aGlj aCBjb3VsZCBpbnZvbHZlIGFjdHVhbCB0cmFmZmljIGFzIHdlbGwgYXMgcmVzZXJ2YXRpb25zLCBl LmcuIHNlbmRpbmcgdmlkZW8gdG8gYSBzY3JlZW4gd2hlbiBuby1vbmUncyB3YXRjaGluZyBpdC4N Cg0KSm9obiBHcmFudA0KTmluZSBUaWxlcywgQ2FtYnJpZGdlLCBFbmdsYW5kDQorNDQgMTIyMyA4 NjI1OTkgYW5kICs0NCAxMjIzIDUxMTQ1NQ0KaHR0cDovL3d3dy5uaW5ldGlsZXMuY29tPGh0dHA6 Ly93d3cubmluZXRpbGVzLmNvbS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpkZXRuZXQgbWFpbGluZyBsaXN0DQpkZXRuZXRAaWV0Zi5vcmc8bWFp bHRvOmRldG5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGV0bmV0X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmRldG5ldCBtYWlsaW5nIGxpc3QNCmRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg== --_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B375ASJEXCHMB09corpa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBSb2RuZXks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBjaGFydGVyIHRleHQg c2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7Li4uYW5kIDIpIHJlbGVhc2UvcmV1c2UgdGhl IHJlc291cmNlcyB3aGVuIHRoZXkgYXJlIG5vIG1vcmUgcmVxdWlyZWQuLi4mcXVvdDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPndoaWNoIHNheXMg bm90aGluZyBhYm91dCBhdXRvbWF0aWMgcmVsZWFzZSBvZiByZXNvdXJjZXMuIFdoZW4gcmVzZXJ2 YXRpb25zIGFyZSBzZXQgdXAgYnkgbWFuYWdlbWVudCwgbWFuYWdlbWVudCB3b3VsZCBhbHNvIGhh dmUgYSB3YXkgdG8gcmVsZWFzZSB0aGUgcmVzb3VyY2UuIFRoZSB0ZXh0IGFwcGxpZXMNCiBlcXVh bGx5IHRvIG1hbmFnZW1lbnQgb3IgdGhlIGJhbmR3aWR0aCBjb25zdW1lciBleHBsaWNpdGx5IHJl bGVhc2luZyBiYW5kd2lkdGggYXMgd2VsbCBhcyB0byBjYXNlcyB3aGVyZSBhdXRvbWF0aWMgcmVs ZWFzZSBvY2N1cnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQg aXMgbW9yZSBsaWtlbHkgdGhhdCBhbiBpbiBjYXIgY29udHJvbCBwYXRoIHdvdWxkIGJlIGxheWVy IDIgYW5kIGNvdmVyZWQgYnkgdGhlIHdvcmsgSUVFRSA4MDIuMSBpcyBkb2luZy4gJm5ic3A7VGhl IGJ1aWxkaW5nIG1vbml0b3JpbmcgYW5kIGNvbnRyb2wgdXNlIGNhc2UgaXMgYW4gZXhhbXBsZSB3 aGVyZQ0KIExheWVyIDMgd2l0aCBzb21lIG9mIHRoZSBjb25maWd1cmF0aW9uIHJlbGF0aXZlbHkg c3RhdGljIChzZWN1cml0eSBtb25pdG9yaW5nIHN5c3RlbXMsIGVudmlyb25tZW50YWwgY29udHJv bCwgZXRjLikuIE9yIGNvbnRyb2wgb24gYSBtYW51ZmFjdHVyaW5nIGxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYXQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRldG5ldCBbbWFpbHRv OmRldG5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2RuZXkgQ3Vt bWluZ3M8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMzEsIDIwMTUgODoyOCBBTTxi cj4NCjxiPlRvOjwvYj4gZGV0bmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb RGV0bmV0XSBEcmFmdCBEZXROZXQgQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVsbG8sPC9zcGFuPg0KPGJyPg0KPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBhZGRyZXNz IGFwcGxpY2F0aW9ucyB0aGF0IG5lZWQgc29mdC1zdGF0ZSAoaS5lLiBhdXRvbWF0aWMgcmVsZWFz ZSBvZiByZXNvdXJjZXMgd2hlbiBubyBsb25nZXIgdXNlZCksIGJ1dCBJIGRvIG5vdCB0aGluayB0 aGF0IHRoZSBEZXROZXQgd29yayBzaG91bGQgcHJvaGliaXQgYXBwbGljYXRpb25zDQogZnJvbSB1 c2luZyBoYXJkLXN0YXRlLjwvc3Bhbj4gPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+QXMgYSBzcGVjaWZpYyBleGFtcGxlLCBjb25zaWRlciBhIG5ldHdvcmsgd2l0aGluIGEg Y2FyIHRoYXQgaXMgdXNlZCBmb3IgY3liZXItcGh5c2ljYWwgY29udHJvbCAoZS5nLiBlbmdpbmUs IHRyYW5zbWlzc2lvbikuIFRoZSBkZXZpY2VzIGZvciB0aGlzIGFwcGxpY2F0aW9uIG5ldmVyIGNo YW5nZSwgYW5kIHRoZSBuZXR3b3JrIGNhYmxpbmcNCiBhbmQgcm91dGluZyBuZXZlciBjaGFuZ2Vz LCBhbmQgdGhlcmVmb3JlIHRoZSBEZXROZXQgdHJhZmZpYyBpcyBuZXZlciBleHBlY3RlZCB0byBj aGFuZ2UuIFRyYWZmaWMgZm9yIG90aGVyIHB1cnBvc2VzIChlLmcuIEludGVybmV0IGJyb3dzaW5n KSBtYXkgYmUgZGVzaXJhYmxlLCBidXQgaXQgaXMgZGVmaW5pdGVseSBub3QgYXMgY3JpdGljYWwu IEZvciB0aGlzIGFwcGxpY2F0aW9uLCBsb2NraW5nIGRvd24gdGhlIHJlc291cmNlcyBmb3IgRGV0 TmV0DQogdHJhZmZpYyBpcyBkZXNpcmVkLjwvc3Bhbj4gPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SW4gdGhlIFRTTiB3b3JrIHRodXMgZmFyLCB0aGUgbWVjaGFuaXNtIGZv ciBjb25maWd1cmluZyA4MDIuMVFidiBzY2hlZHVsZXMgaXMgbWFuYWdlbWVudC4gVGhlIGdlbmVy YWwgYXNzdW1wdGlvbiBpcyB0aGF0IG1hbmFnZW1lbnQgb2YgODAyLjFRYnYgY2FuIGJlIGhhbmRs ZWQgaW4gZWl0aGVyIGEgaGFyZC1zdGF0ZSBvciBzb2Z0LXN0YXRlDQogbWFubmVyLCBkZXBlbmRp bmcgb24gdGhlIGFwcGxpY2F0aW9uLiBJZiA4MDIuMVFidiBpcyB1c2VkIGluIGFuIElUIG5ldHdv cmssIEkgd291bGQgZXhwZWN0IHNvZnQtc3RhdGUgdG8gYmUgdXNlZC48L3NwYW4+DQo8YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgZXhpc3RpbmcgQVZCIHN0YW5kYXJk cyBpbiB0aGUgZmllbGQgKDgwMi4xUWF2IGFuZCA4MDIuMVFhdCwgYWthIFNSUCkgYXJlIGVudGly ZWx5IHNvZnQtc3RhdGUsIHdpdGggU1JQIHVzaW5nIGJhbmR3aWR0aCBmb3IgQVZCIHRyYWZmaWMg b25seSB3aGVuIEFWQiBwYWNrZXRzIGV4aXN0LCBhbmQgU1JQIGZyZWVpbmcgYWxsIHJlc291cmNl cw0KIG9uIHRpbWVvdXQgKHNvZnQtc3RhdGUpLiBOZXZlcnRoZWxlc3MsIGluIHRoZSBhbWVuZG1l bnQgdG8gU1JQICg4MDIuMVFjYyksIHdlIGFyZSBhZGRpbmcgdGhlIGNhcGFiaWxpdHkgdG8gY29u ZmlndXJlIEFWQiByZXNvdXJjZXMgdXNpbmcgbWFuYWdlbWVudCwgd2hpY2ggd2lsbCBlbmFibGUg aGFyZC1zdGF0ZSBhcHBsaWNhdGlvbnMuIEF1dG9tb3RpdmUgYXBwbGljYXRpb25zIG9mIEFWQiBh cmUgdXNpbmcgYSBoYXJkLXN0YXRlIGFwcHJvYWNoIGFscmVhZHkuPC9zcGFuPg0KPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Um9kbmV5PC9zcGFuPiA8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RnJvbTog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QmFsw6F6cyBWYXJnYSBBICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmEudmFyZ2FAZXJp Y3Nzb24uY29tIj5iYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5UbzogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9h PiZndDssDQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVG NUYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjA4LzMxLzIwMTUgMDc6MjggQU08L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtEZXRuZXRdIERy YWZ0IERldE5ldCBDaGFydGVyPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM1RjVGNUYiPlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90O2RldG5ldCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnIj5kZXRuZXQtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIg d2lkdGg9IjEwMCUiIG5vc2hhZGU9IiIgc3R5bGU9ImNvbG9yOiNBMEEwQTAiIGFsaWduPSJjZW50 ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDA0MDgwIj5IaSw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDQwODAiPkkgYWdyZWUsIHJlbGVhc2Ugb2YgdW51c2VkIHJlc291cmNl cyBpcyBhbiBpbXBvcnRhbnQgdGFzayB0byBiZSBzb2x2ZWQgYnkgdGhlIFdHLg0KPC9zcGFuPjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj4mbmJzcDs8L3Nw YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+VGhl IHNpdHVhdGlvbiB3aXRoIHNvbWUgVFNOIHRvb2xzIGNhbiBiZSBldmVuIHdvcnN0IHRoYW4gd2hh dCB5b3UgaGF2ZSBkZXNjcmliZWQgYmVsb3cuPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPkUuZy4gdXNpbmcg4oCcODAyLjFRYnYgRW5oYW5j ZW1lbnRzIGZvciBTY2hlZHVsZWQgVHJhZmZpY+KAnSBpbiBzb21lIGNhc2VzIG5vIG90aGVyIHRy YWZmaWMgKGluY2x1ZGluZyBiZXN0LWVmZm9ydCkgY2FuIHVzZSB0aGUgcmVzZXJ2ZWQgYmFuZHdp ZHRoLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0 MDgwIj5TbyBpZiBZb3UgaGF2ZSByZXNlcnZlZCBhbGwgdGhlIGJhbmR3aWR0aCBidXQgYWxsIGhp Z2ggcHJpb3JpdHkgZmxvd3MgYXJlIHRlcm1pbmF0ZWQgbm8gdHJhZmZpYyBjYW4gY3Jvc3MgeW91 ciBsaW5rLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDA0MDgwIj5DaGVlcnM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwNDA4MCI+QmFsYeKAmXpzPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBkZXRuZXQgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZGV0bmV0LWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk8Yj48YnI+DQpTZW50OjwvYj4g U2F0dXJkYXksIEF1Z3VzdCAyOSwgMjAxNSAxMjoyNCBQTTxiPjxicj4NClRvOjwvYj4gSm9obiBH cmFudDxiPjxicj4NCkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0 bmV0QGlldGYub3JnPC9hPjxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0RldG5ldF0gRHJhZnQg RGV0TmV0IENoYXJ0ZXI8L3NwYW4+IDxicj4NCiZuYnNwOyA8YnI+DQpZZXMsIEl0IGlzIEtpbmQg b2YgRWFzeSB0byByZXVzZSBiYW5kd2lkdGggb3V0Z29pbmcgdGhlIHN3aXRjaCBpZiB0aGVyZSB3 YXMgbm8gaW5jb21pbmcgcGFja2V0OyB3aGF0J3MgaGFyZGVyIGlzIHRvIGRpc2NvdmVyIHRoYXQg dGhlIGZsb3cgaXMgdGVybWluYXRlZC4NCjxicj4NCiZuYnNwOyA8YnI+DQpUaGlzIHdpbGwgaW1w YWN0IHRoZSBmbG93IGRlc2NyaXB0aW9uIGFuZCBvciB0aGUgcHJvdG9jb2xzIChlLmcuIEFzc29j aWF0aW5nIGEgbGlmZXRpbWUgYW5kIGEgY29udGludW91cyByZW5ld2FsIHByb2Nlc3MgdG8gdGhl IHJlZ2lzdHJhdGlvbikNCjxicj4NCiZuYnNwOyA8YnI+DQpQb2ludCB0YWtlbiEgSSBhZ3JlZSB0 aGF0IHRoaXMgZG9lcyBub3QgaW1wYWN0IHRoZSBjaGFydGVyLCB0aG91Z2guIDxicj4NCiZuYnNw OyA8YnI+DQpDaGVlcnMsIDxicj4NCiZuYnNwOyA8YnI+DQpQYXNjYWwgPGJyPg0KPGJyPg0KPGJy Pg0KUGFzY2FsIDxicj4NCjxicj4NCkxlIDI5IGFvw7t0IDIwMTUgw6AgMTI6MTEsIEpvaG4gR3Jh bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpqQG5pbmV0aWxlcy5jb20iPmpAbmluZXRpbGVzLmNvbTwv YT4mZ3Q7IGEgw6ljcml0IDoNCjxicj4NCiZuYnNwOyA8YnI+DQpPbiAyOCBBdWcgMjAxNSwgYXQg MjM6MTUsIEdyb3NzbWFuLCBFdGhhbiBBLiB3cm90ZTogPGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkhpIEZvbGtzLDwvc3Bhbj4gPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgdGhpbmsgdGhlIGRyYWZ0IGNoYXJ0ZXIgbG9va3MgcmVh bGx5IGdvb2QsIGFuZCBoaXRzIHRoZSByaWdodCBwb2ludHMuIEkgaGF2ZSBhIHF1ZXN0aW9uIGFi b3V0IHRoaXMgcGhyYXNlOg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m cXVvdDsuLi5hbmQgMikgcmVsZWFzZS9yZXVzZSB0aGUgcmVzb3VyY2VzIHdoZW4gdGhleSBhcmUg bm8gbW9yZSByZXF1aXJlZC4uLiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj4gPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uZSBvZiB0aGUgY29uY2Vy bnMgYWJvdXQgQVZCL1RTTiAoYW5kICZxdW90O3Jlc2VydmVkIGJhbmR3aWR0aCZxdW90OyBzY2hl bWVzIGluIGdlbmVyYWwpIHRoYXQgSSBoZWFyZCBmcm9tIG91ciBJVCBndXlzLCBpbiB0aGUgY29u dGV4dCBvZiBhIGNvcnBvcmF0ZSBuZXR3b3JrLCB3YXMgdGhhdCAmcXVvdDtvbmNlIHVzZXJzIHJl c2VydmVkIGJhbmR3aWR0aCBmb3IgdGhlIHN0cmVhbXMgdGhleSB3YW50ZWQsIHdoZW4gdGhleQ0K IHdlcmUgJnF1b3Q7ZG9uZSZxdW90OyB0aGV5IHdvdWxkIG5ldmVyIGdldCBhcm91bmQgdG8gdGVh cmluZyB0aGUgc3RyZWFtcyBkb3duLCBhbmQgc28gdGhhdCBiYW5kd2lkdGggd291bGQgcmVtYWlu IHVudXNhYmxlIGJ5IG90aGVycyBvbiB0aGUgbmV0d29yayZxdW90Oy4NCjwvc3Bhbj48YnI+DQom bmJzcDsgPGJyPg0KW3NuaXBdIDxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5JIHN1cHBvc2Ugc3VjaCAmcXVvdDtzdGFsZSZxdW90OyByZXNlcnZlZCBiYW5k d2lkdGggd291bGQgcHJldmVudCBvdGhlcnMgZnJvbSByZXNlcnZpbmcgdGhhdCBiYW5kd2lkdGgs PC9zcGFuPg0KPGJyPg0KJm5ic3A7IDxicj4NCkV4YWN0bHkgLS0gSSB0aGluayB0aGF0J3Mgd2hh dCB0aGV5J3JlIHJlZmVycmluZyB0bzsgeW91IGNvdWxkIGZpbmlzaCB1cCB3aXRoIGEgbGluayBv biB3aGljaCBhbGwgdGhlIGJhbmR3aWR0aCBpcyByZXNlcnZlZCBidXQgbm9uZSBpcyB1c2VkLCBp biB3aGljaCBjYXNlIDEwMCUgb2YgdGhlIGxpbmsgaXMgYXZhaWxhYmxlIGZvciBiZXN0LWVmZm9y dCB0cmFmZmljIGJ1dCBubyBuZXcgdGltZS1zZW5zaXRpdmUgZmxvd3MgY2FuIHVzZSBpdC4NCjxi cj4NCiZuYnNwOyA8YnI+DQpUaGVyZSdzIGFsd2F5cyBhIHByb2JsZW0gdGhhdCBmb2xrcyBtYXkg cmVzZXJ2ZSByZXNvdXJjZXMgdGhleSBhcmVuJ3QgdXNpbmcsIHdoaWNoIGNvdWxkIGludm9sdmUg YWN0dWFsIHRyYWZmaWMgYXMgd2VsbCBhcyByZXNlcnZhdGlvbnMsIGUuZy4gc2VuZGluZyB2aWRl byB0byBhIHNjcmVlbiB3aGVuIG5vLW9uZSdzIHdhdGNoaW5nIGl0Lg0KPGJyPg0KJm5ic3A7IDxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkpvaG4gR3JhbnQ8YnI+DQpOaW5lIFRpbGVz LCBDYW1icmlkZ2UsIEVuZ2xhbmQ8YnI+DQomIzQzOzQ0IDEyMjMgODYyNTk5IGFuZCAmIzQzOzQ0 IDEyMjMgNTExNDU1PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+ PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cubmluZXRpbGVzLmNvbS8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmh0dHA6Ly93d3cubmluZXRpbGVzLmNvbTwvc3Bhbj48L2E+DQo8YnI+DQom bmJzcDsgPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpkZXRuZXQgbWFpbGluZyBsaXN0PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxi cj4NCjwvc3Bhbj48L3U+PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGll dGYub3JnPC9hPjx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91Pjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldDwvYT48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5kZXRuZXQgbWFpbGlu ZyBsaXN0PC90dD48YnI+DQo8dHQ+PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0 bmV0QGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0Ij48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0PC9z cGFuPjwvdHQ+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EB9B93801780FD4CA165E0FBCB3C3E672B3B375ASJEXCHMB09corpa_--