From aec235a1f5110ae9eac6c0d0ea106cdd40d6b024 Mon Sep 17 00:00:00 2001 From: David Oran Date: Mon, 25 Oct 2021 10:40:15 -0400 Subject: [PATCH] Refresh to version 06 - no changes --- draft-oran-icnrg-flowbalance-06.html | 1722 ++++++++++++++++++ draft-oran-icnrg-flowbalance-06.pdf | 2426 ++++++++++++++++++++++++++ draft-oran-icnrg-flowbalance-06.txt | 896 ++++++++++ draft-oran-icnrg-flowbalance-06.xml | 477 +++++ 4 files changed, 5521 insertions(+) create mode 100644 draft-oran-icnrg-flowbalance-06.html create mode 100644 draft-oran-icnrg-flowbalance-06.pdf create mode 100644 draft-oran-icnrg-flowbalance-06.txt create mode 100644 draft-oran-icnrg-flowbalance-06.xml diff --git a/draft-oran-icnrg-flowbalance-06.html b/draft-oran-icnrg-flowbalance-06.html new file mode 100644 index 0000000..78299b8 --- /dev/null +++ b/draft-oran-icnrg-flowbalance-06.html @@ -0,0 +1,1722 @@ + + + + + + +Maintaining CCNx or NDN flow balance with highly variable data object sizes + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftMaintaining Flow BalanceOctober 2021
OranExpires 28 April 2022[Page]
+
+
+
+
Workgroup:
+
ICNRG
+
Internet-Draft:
+
draft-oran-icnrg-flowbalance-06
+
Published:
+
+ +
+
Intended Status:
+
Experimental
+
Expires:
+
+
Author:
+
+
+
D. Oran
+
Network Systems Research and Design
+
+
+
+
+

Maintaining CCNx or NDN flow balance with highly variable data object sizes

+
+

Abstract

+

Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network.

+

Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 28 April 2022.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. Introduction +

+

Deeply embedded in some ICN architectures, especially Named Data Networking ([NDN]) and Content-Centric Networking (CCNx [RFC8569],[RFC8609]) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network.

+

This approach leads to a desire to make the size of the objects carried in Data messages small and near constant, because flow balance can then be kept using simple bookkeeping of how many Interest messages are outstanding. While simple, constraining Data messages to be quite small - usually on the order of a link Maximum Transmission Unit (MTU) - has some constraints and deleterious effects, among which are:

+
    +
  • Such small data objects are inconvenient for many applications; their natural data object sizes can be considerably larger than a link MTU. +
    • +
  • Applications with truly small data objects (e.g. voice packets in an Internet telephony applications) have no way to communicate that to the network, causing resources to still be allocated for MTU-sized data objects +
    • +
  • When chunking a larger data object into multiple Data messages, each message has to be individually cryptographically hashed and signed, increasing both computational overhead and overall message header size. The signature can be elided when Manifests are used (by signing the Manifest instead), but the overhead of hashing multiple small messages rather than fewer larger ones remains. +
    • +
+

One approach which helps with the last of these is to employ fragmentation for Data messages larger than the Path MTU (PMTU). Such messages are carved into smaller pieces for transmission over the link(s). There are three flavors of fragmentation: end-to-end, hop-by-hop with reassembly at every hop, and hop-by-hop with cut-through of individual fragments. A number of ICN protocol architectures incorporate fragmentation and schemes have been proposed for both NDN and CCNx, for example in [Ghali2013]. Fragmentation alone does not ameliorate the flow balance problem however, since from a resource allocation standpoint both memory and link bandwidth must be set aside for maximum-sized data objects to avoid congestion collapse under overload.

+

The design space considered in this document does not however extend to arbitrarily large objects (e.g. 100's of kilobytes or larger). As the dynamic range of data object sizes gets very large, finding the right tradeoff between handling a large number of small data objects versus a single very large data object when allocating link and buffer resources becomes intractable. Further, the semantics of Interest-Data exchanges means that any error in the exchange results in a re-issue of an Interest for the entire Data object. Very large data objects represent a performance problem because the cost of retransmission when Interests are retransmitted (or re-issued) becomes unsustainably high. Therefore, the method we propose deals with a dynamic range of object sizes from very small (a fraction of a link MTU) to moderately large - about 64 kilobytes or equivalently about 40 Ethernet packets, and assumes an associated fragmentation scheme to handle link MTUs that cannot carry the Data message in a single link-layer packet.

+

The approach described in the rest of this document maintains flow balance under the conditions outlined above by allocating resources accurately based on expected Data message size, rather than employing simple interest counting.

+
+
+
+

+2. Requirements Language +

+

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119].

+
+
+
+

+3. Method to enhance congestion control with signaled size information in Interest Messages +

+

Before diving into the specifics of the design, it is useful to consider how congestion control works in NDN/CCNx. Unlike the IP protocol family, which relies on end-to-end congestion control (e.g. TCP[RFC0793], DCCP[RFC4340], SCTP[RFC4960], QUIC[I-D.ietf-quic-transport]), CCNx and NDN employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path and therefore for each outstanding Interest, bandwidth for data returning on the inverse path can be allocated. In many current designs, this allocation is done using simple Interest counting - by queueing and subsequently forwarding one Interest message from a downstream node, implicitly this provides a guarantee (either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send back one Data message. A number of congestion control schemes have been developed that operate in this fashion, for example [Wang2013],[Mahdian2016],[Song2018],[Carofiglio2012]. Other schemes, like [Schneider2016] neither count nor police interests, but instead monitor queues using AQM (active queue management) to mark or drop returning Data packets that have experienced congestion. It is worth noting that every congestion control algorithm has an explicit fairness goal and associated objective function (usually either [minmaxfairness] or [proportionalfairness]). If your fairness is to be based on resource usage, pure interest counting doesn't do the trick, since a consumer asking for large thing can saturate a link and shift loss to consumers asking for small things.

+

In order to deal with a larger dynamic range of Data message size, some means is required to allocate link bandwidth for Data messages in bytes with an upper bound larger than a Path MTU and a lower bound lower than a single link MTU. Since resources are allocated for returning Data based on arriving Interests, this information must be available in Interest messages.

+

Therefore, one key idea is the inclusion of an expected data size TLV in each Interest message. This allows each forwarder on the path taken by the Interest to more accurately allocate bandwidth on the inverse path for the returning Data message. Also, by including the expected data size, large objects will have a corresponding weight in resource allocation, maintaining link and forwarder buffering fairness. The simpler Interest counting scheme was nominally "fair" on a per-exchange basis within the variations of data that fit in a single PMTU packet because all Interests produced similar amounts of data in return. In the absence of such a field, it is not feasible to allow a large dynamic range in object size. While schemes like [Schneider2016] would not employ the expected data size to allocate reverse link bandwidth, they can still benefit from the information to affect the AQM congestion marking algorithm, preferentially marking data packets that exceed the expected data size from the corresponding Interest.

+

It is natural to ask whether the additional complexity introduced into an ICN forwarder, and the additional computational cost for the congestion control operations is worthwhile. For congestion control schemes like [Schneider2016] the additional overhead is not trivial, since no Interest counting is happening. However, if a congestion control is already counting Interests, the additional overhead is minimal, only reading one extra TLV from the Interest and incrementing the outstanding data amount for the corresponding queue by that number rather than a constant of 1. The overhead on returning data is simply reducing the amount by the actual Data message size, rather than by 1.

+
+
+

+3.1. How to predict the size of returning Data messages +

+

This of course raises the question "How does the requester know how big the corresponding Data message coming back will be?". For a number of important applications, the size is known a priori due to the characteristics of the application. Here are some examples:

+
    +
  • For many sensor and other Internet-of-Things applications, the data is instrument readings which have fixed known size. +
    • +
  • In video streaming, the data is output of a video encoder which produces variable sized frames. This information is typically made available ahead of time to the streaming clients in the form of a Manifest (e.g [DASH], FLIC [I-D.irtf-icnrg-flic]), which contains the names of the corresponding segments (or individual frames) of video and audio and their sizes. +
    • +
  • Internet telephony applications use vocoders that typically employ fixed-size audio frames. Therefore, their size is known either a priori, or via an initialization exchange at the start of an audio session. +
    • +
+

The more complex cases arise where the data size is not known at the time the Interest must be sent. Much of the nuance of the proposed scheme is in how mismatches between the expected data size and the actual Data message returned are handled. The consumer can either under- or over-estimate the data size. In the former case, the under-estimate can lead to congestion and possible loss of data. In the latter case, bandwidth that could have been used by data objects requested by other consumers might be wasted. We first consider "honest" mis-estimates due to imperfect knowledge by the ICN application; later we consider malicious applications that are using the machinery to mount some form of attack. We also consider the effects of Interest aggregation if the aggregated Interests have differing expected data sizes. Also, it should be obvious that if the Data message arrives, the application learns its actual size, which may or may not be useful in adjusting the expected data size estimate for future Interests.

+

In all cases, the expected data size from the Interest can be incorporated in the corresponding Pending Interest Table (PIT) entry of each CCNx/NDN forwarder on the path and hence when a (possibly fragmented) Data object comes back, its total size is known and can be compared to the expected size in the PIT for a mismatch. Aside: In the case of fragmentation, we assume a fragmentation scheme in which the total Data message size can be known as soon as any one fragment is received (a reasonable assumption for most any well-designed fragmentation method, such as that in [Ghali2013]).

+
+
+
+
+

+3.2. Handling 'too big' cases +

+

If the returning Data message is larger than the expected data size, the extra data could result in either unfair bandwidth allocation or possibly data loss under congestion conditions. When this is detected, the forwarder has three choices:

+
    +
  1. It could forward the Data message anyway, which is safe under non-congestion conditions, but unfair and possibly unstable when the output link is congested +
    2. +
  2. It could forward the data when un-congested (e.g. by assessing output queue depth) but drop it when congested +
    3. +
  3. It could always drop the data, as a way of "punishing" the requester for the mis-estimate. +
    4. +
+

Either of the latter two strategies is acceptable from a congestion control point of view. However, it is not a good idea to simply drop the Data message with no feedback to the issuer of the Interest because the application has no way to learn the actual data size and retry. Further, recovery would be delayed until the failing Interest timed out. Therefore, an additional element needed in protocol semantics is the incorporation of a "Data too big" error message (achieved via the use of an "Interest Return" packet in CCNx).

+

Upon dropping data as above, the CCNx/NDN forwarder converts the normal Data message into an Interest Return packet containing the existing [RFC8609] T_MTU_TOO_LARGE error code and the actual size of the Data message instead of the original content. It propagates that back toward the client identically to how the original Data message would have been handled. Subsequent nodes upon receiving the T_MTU_TOO_LARGE error treat identically to other Interest Return errors. When the Interest Return eventually arrives back to the issuer of the Interest, the user MAY reissue the Interest with the correct expected data size.

+

One detail to note is that an Interest Return carrying T_MTU_TOO_LARGE must be deterministically smaller than the expected data size in all cases. This is clearly the case for large data objects, but there is a corner case with small data objects. There has to be a minimum expected data size that a client can specify in their Interests, and that minimum cannot be smaller than the size of a T_MTU_TOO_LARGE Interest Return packet.

+
+
+
+
+

+3.3. Handling 'too small' cases +

+

Next we consider the case where the returning data is smaller than the expected data size. While this case does not result in congestion, it can cause resources to be inefficiently allocated because not all of the set-aside bandwidth for the returning data object gets used. The simplest and most straightforward way to deal with this case is to essentially ignore it. The motivation for not worrying about the smaller data mismatch is that in many situations that employ usage-based resource measurement (and possibly charging), it is trivial to just account for the usage according to the larger expected data size rather than actual returned data size. Properly adjusting congestion control parameters to somehow penalize users for over-estimating their resource usage requires fairly heavyweight machinery, which in most cases is not warranted. If desired, any of the following mechanisms could be considered:

+
    +
  • Attempt to identify future Interests for the same object or closely related objects and allocate resources based on some retained state about the actual size of prior objects +
    • +
  • Police consumer behavior and decrease the expected data size in one or more future Interests to compensate +
    • +
  • For small objects, do more optimistic resource allocation on the links on the presumption that there will be some "slack" due to clients overestimating data object size. +
    • +
+
+
+
+
+

+3.4. Interactions with Interest Aggregation +

+

One protocol detail of CCNx/NDN that needs to be dealt with is Interest Aggregation. Interest Aggregation, while a powerful feature for maintaining flow balance when multiple consumers send Interests for the same Named object, introduces subtle complications. Whenever a second or subsequent Interest arrives at a forwarder with an active PIT entry it is possible that those Interests carry different parameters, for example hop limit, payload, etc. It is therefore necessary to specify the exact behavior of the forwarder for each of the parameters that might differ. In the case of the expected data size parameter defined here, the value is associated with the ingress face on which the Interest creating the PIT entry arrived, as opposed to being global to the PIT entry as a whole. Interest aggregation interacts with expected data size if Interests from different clients contain different values of the expected data size. As above in Section 3.3, the simplest solution to this problem is to ignore it, as most error cases are benign. However, there is one problematic error case where one client provides an accurate expected data size, but another who issued the Interest first underestimates, causing both to receive a T_MTU_TOO_LARGE error. This introduces a denial of service vulnerability, which we discuss below together with the other malicious actor cases.

+

There are two cases to consider:

+
    +
  1. The arriving Interest carries an expected data size smaller than any of the values associated with the PIT entry. +
    2. +
  2. The arriving Interest carries an expected data size larger than any of the values associated with the PIT entry. +
    3. +
+

For Case (1) the Interest can be safely aggregated since the upstream links will have sufficient bandwidth allocated based on the larger expected data size (assuming the original Interest's expected data size was itself sufficiently large to accommodate the actual size of the returning Data). On the other hand, should the incoming face have bandwidth allocated based on the larger existing Interest's expected data size, or on the smaller value in the arriving interest? Here there are two possible approaches:

+
    +
  1. Allocate based on the data size already in the PIT. In this case the consumer sending the earlier Interest can cause over-allocation of link bandwidth for other incoming faces, but there will not be a T_MTU_TOO_LARGE error generated for that Interest +
    2. +
  2. Allocate based on the value in the arriving Interest. If the returning Data is in fact larger, generate a T_MTU_TOO_LARGE Interest Return on that ingress face, while successfully returning the Data message on any faces that do not exhibit a too small expected data size +
    3. +
+

It is RECOMMENDED that the second policy be followed. The reasons behind this recommendation are as follows:

+
    +
  1. The link can be congested quite quickly after the queuing decision is made, especially if the data has a long link-occupancy time, so this is a safer alternative. +
    2. +
  2. The cost of returning the error is only one link RTT, since the consumer (or downstream forwarder) can immediately re-issue the Interest with the correct size and perhaps pick up the cached object from the upstream forwarder's Content Store. +
    3. +
  3. Being optimistic and returning the data interacts with the behavior of aggregate resource control and resource accounting, which in turn raises the messy issue of whether to "charge" the consumer for the actual bandwidth used or only for the requested bandwidth in the expected data. +
    4. +
  4. The rabbit hole goes deeper if you add differential QoS to the equation or consumers "playing games" and intentionally underestimating so their interests get satisfied when links aren't congested. This makes handling malicious actors (Section 4) more difficult. +
    5. +
+

For Case (2) above, the Interest MUST be forwarded rather than aggregated to prevent a consumer from mounting a denial of service attack by sending intentionally too small expected data size (see Section 4 for additional detail on this and other attacks). As above for Case (1) it is RECOMMENDED that policy (b) above be followed.

+
+
+
+
+

+3.5. Operation when some Interests lack the expected data size option and some have it +

+

Since the expected data size is an optional hop-by-hop packet field, forwarders need to be prepared to handle an arbitrary mix of packets containing or lacking this option. There are two general things to address.

+

First, we assume that any forwarder supporting expected data size is running a more sophisticated congestion control algorithm that one employing simple interest counting. The link bandwidth resource allocation is therefore based directly, or indirectly, on the expected Data size in bytes. Therefore, the forwarder has to assign a value to use in the resource allocation for the reverse link. This specification does not mandate any particular approach or a default value to use. However, in the absence on other guidance, it makes sense to do one of two things:

+
    +
  1. Pick a default based on the link MTU of the face on which the Interest arrived and use that for all Interests lacking an expected data size. This is likely to be most compatible with simple interest counting which would rate limit all incoming interests equally. +
    2. +
  2. +

    Configure some values for given Name prefixes that have known sizes. This may be appropriate for dedicated forwarders supporting single use cases, such as:

    +
      +
    • A forwarder handling IoT sensors sending very small Data messages +
      • +
    • A forwarder handling real-time video with large average Data packets that exceed link MTU and are routinely fragmented +
      • +
    • A forwarder doing voice trunking where the vocoders produce moderate sized packets, still much smaller than the link MTU +
      • +
    +
    3. +
+

The second area to address is what to do if an interest lacking an expected Data size is responded to by a Data message whose size exceeds the default discussed above. It would be inappropriate to issue a T_MTU_TOO_LARGE error, since the consumer is unlikely to understand or deal correctly with that new error case. Instead, it is RECOMMENDED that the forwarder:

+
    +
  • Ignore the mismatch if the reverse link is not congested and return the requested Data message anyway. +
    • +
  • If the reverse link is congested, issue an Interest Return with the T_NO_RESOURCES error code +
    • +
+

This specification does not define or recommend any particular algorithm for assessing the congestion state of the link(s) to carry the Data message downstream to the requesting consumers. It is assumed that a reasonable algorithm is in use, because otherwise even basic Interest counting forms of congestion control would not be effective.

+
+
+
+
+
+
+

+4. Dealing with malicious actors +

+

First we note that various known attacks in CCNx or NDN can also be mounted by users employing this method. Attacks that involve interest flooding, cache pollution, cache poisoning, etc. are neither worsened nor ameliorated by the introduction of the congestion control capabilities described here. However, there are two new vulnerabilities that need to be dealt with. These two new vulnerabilities involve intentional mis-estimation of data size.

+

The first is a consumer who intentionally over-estimates data size with the goal of preventing other users from using the bandwidth. This is at most a minor additional concern given the discussion of how to handle over-estimation by honest clients in Section 3.2. If one of the amelioration techniques described there is used, the case of malicious over-estimation is also dealt with adequately.

+

The second is a user who intentionally under-estimates the data size with the goal having its Interest processed while the other aggregated interests are not processed, thereby causing T_MTU_TOO_LARGE errors and denying service to the other users with overlapping requests. There are a number of possible mitigation techniques for this attack vector, ranging in complexity. We outline two below; there may be others as or more effective with acceptable complexity and overhead:

+
    +
  • (Simplest) A user sending Interests resulting in a T_MTU_TOO_LARGE error is treated similarly to users mounting interest flooding attacks; the a router aggregating Interests with differing expected data sizes rate limits the face(s) exhibiting these errors, thus decreasing the ability of a user to issue enough mis-estimated Interests to collide and generate Interest aggregation. +
    • +
  • An ICN forwarder aggregating Interests remembers in the PIT entry not only the expected data size of the Interest it forwarded, but the maximum of the expected data size of the other Interests it aggregated. If a T_MTU_TOO_LARGE error comes back, instead of propagating it, the forwarder MAY treat this as a transient error, drop the Interest Return, and re-forward the Interest using the maximum expected data size in the PIT (assuming it is is bigger). This recovers from the error, but the attacker can still cause an extra round trip to the producer or to an upstream forwarder with a copy of the data in its Content Store. +
    • +
+
+
+
+
+

+5. Mapping to CCNx and NDN packet encodings +

+

The only actual protocol needed is a TLV in Interest messages that states the size in bytes of the expected Data Message coming back, and in the Interest Return on a "too big" error to carry the actual data size. In the case of CCNx, this covers the encapsulated Data Object, but not the hop-by-hop headers.

+
+
+

+5.1. Packet encoding for CCNx +

+

For CCNx[RFC8569] there is a new hop-by-hop header TLV, and a new value of the Interest Return "Return Type".

+

Expected Data Size (for Interest messages), or Actual Data Size (for Interest Return messages) TLV

+
+ + + + + + + + + + + + + + + + +
+Table 1: +Data Size TLV +
AbbrevNameDescription
T_DATASIZEData SizeExpected (Section 3) or Actual (Section 3.2) Data Size
+
+
+
+
+
+

+5.2. Packet encoding for NDN +

+

TBD based on [NDNTLV]. Suggestions from the NDN team greatly appreciated.

+
+
+
+
+
+
+

+6. IANA Considerations +

+

Please Add the T_DATASIZE TLV to the Hop-by-Hop TLV types registry of RFC8609, with fixed length of 2, and data type numeric

+

Expected/Actual Data Size TLV encoding. The range has an upper bound of 64K bytes, since that is the largest MTU supported by CCNx.

+
+
+
+
+                     1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++---------------+---------------+---------------+---------------+
+|             T_DATASIZE        |               2               |
++---------------+---------------+---------------+---------------+
+|   Expected/Actual Data Size   |
++---------------+---------------+
+
+
+
Figure 1: +Expected/Actual Datazize using RFC8609 encoding +
+
+
+
+
+
+

+7. Security Considerations +

+

Section 4 addresses the major security considerations for this specification.

+
+
+
+
+

+8. Acknowledgements +

+

Klaus Schneider and Ken Calvert have contributed a number of useful comments which have substantially improved the document.

+
+
+
+

+9. References +

+
+

+9.1. Normative References +

+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
+
+
[RFC8569]
+
+Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, , <https://www.rfc-editor.org/info/rfc8569>.
+
+
[RFC8609]
+
+Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, , <https://www.rfc-editor.org/info/rfc8609>.
+
+
+
+
+

+9.2. Informative References +

+
+
[Carofiglio2012]
+
+Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks, in ICN Workshop at SIGcomm 2012", DOI 10.1145/2377677.2377772, , <http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p37.pdf>.
+
+
[DASH]
+
+"Dynamic Adaptive Streaming over HTTP", various, <https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP>.
+
+
[Ghali2013]
+
+Ghali, C., Narayanan, A., Oran, D., Tsudik, G., and C. Wood, "Secure Fragmentation for Content-Centric Networks, in IEEE 14th International Symposium on Network Computing and Applications", DOI 10.1109/nca.2015.34, , <http://dx.doi.org/10.1109/NCA.2015.34>.
+
+
[I-D.ietf-quic-transport]
+
+Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-27, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-27>.
+
+
[I-D.irtf-icnrg-flic]
+
+Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-02, , <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-02>.
+
+
[Mahdian2016]
+
+Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, "MIRCC: Multipath-aware ICN Rate-based Congestion Control, in Proceedings of the 3rd ACM Conference on Information-Centric Networking", DOI 10.1145/2984356.2984365, , <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p1-mahdian.pdf>.
+
+
[minmaxfairness]
+
+"Max-min Fairness", various, <https://en.wikipedia.org/wiki/Max-min_fairness>.
+
+
[NDN]
+
+"Named Data Networking", various, <https://named-data.net/project/execsummary/>.
+
+
[NDNTLV]
+
+"NDN Packet Format Specification.", , <http://named-data.net/doc/ndn-tlv/>.
+
+
[proportionalfairness]
+
+"Proportionally Fair", various, <https://en.wikipedia.org/wiki/Proportionally_fair>.
+
+
[RFC0793]
+
+Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, , <https://www.rfc-editor.org/info/rfc793>.
+
+
[RFC4340]
+
+Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, , <https://www.rfc-editor.org/info/rfc4340>.
+
+
[RFC4960]
+
+Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, , <https://www.rfc-editor.org/info/rfc4960>.
+
+
[Schneider2016]
+
+Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A Practical Congestion Control Scheme for Named Data Networking, in Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking - ACM-ICN '16", DOI 10.1145/2984356.2984369, , <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf>.
+
+
[Song2018]
+
+Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level Multi-path Interest Control for Information Centric Networking, in 5th ACM Conference on Information-Centric Networking", DOI 10.1145/3267955.3267971, , <https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final62.pdf>.
+
+
[Wang2013]
+
+Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I. Rhee, "An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking, in ACM SIGCOMM Workshop on Information-Centric Networking", DOI 10.1145/2534169.2491233, , <http://conferences.sigcomm.org/sigcomm/2013/papers/icn/p55.pdf>.
+
+
+
+
+
+
+

+Author's Address +

+
+
Dave Oran
+
Network Systems Research and Design
+
4 Shady Hill Square
+
+Cambridge, MA 02138 +
+
United States of America
+ +
+
+
+ + + diff --git a/draft-oran-icnrg-flowbalance-06.pdf b/draft-oran-icnrg-flowbalance-06.pdf new file mode 100644 index 0000000..92fc929 --- /dev/null +++ b/draft-oran-icnrg-flowbalance-06.pdf @@ -0,0 +1,2426 @@ +%PDF-1.3 +% +1 0 obj +< /Producer + (WeasyPrint 0.42.3 \(http://weasyprint.org/\)) /Subject + ( + Deeply embedded in some ICN architectures, especially Named Data Networking \(NDN\) and Content-Centric Networking \(CCNx\) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. + Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. + + ) + /Title + (Maintaining CCNx or NDN flow balance with highly variable data object sizes)>> +endobj +2 0 obj +<> + /Pages 4 0 R /Type /Catalog>> +endobj +3 0 obj +<> + /Count 24 /First 179 0 R /Last 180 0 R /Title + (Maintaining CCNx or NDN flow balance with highly variable data object sizes)>> +endobj +4 0 obj +<> +endobj +5 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 588.238123155 128.155511811 569.518123155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 343.823591905 214.405511811 325.103591905] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [162.655511811 267.10476378 362.155511811 253.505154405] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 171 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 172 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +6 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 763.28976378 189.655511811 744.56976378] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [126.655511811 686.570935655 287.155511811 672.97132628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 626.92210753 194.155511811 608.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 600.70210753 71.155511811 587.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 600.70210753 139.405511811 587.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 580.20210753 71.155511811 567.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 580.20210753 193.405511811 567.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 559.70210753 71.155511811 546.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 559.70210753 508.405511811 546.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 539.20210753 90.655511811 526.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 539.20210753 338.155511811 526.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 518.70210753 90.655511811 505.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 518.70210753 209.155511811 505.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 498.20210753 90.655511811 485.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 498.20210753 221.155511811 485.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 477.70210753 90.655511811 464.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 477.70210753 279.655511811 464.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 457.20210753 90.655511811 444.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 457.20210753 492.655511811 444.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 434.20210753 71.155511811 421.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 434.20210753 218.905511811 421.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 413.70210753 71.155511811 400.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 413.70210753 291.655511811 400.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 393.20210753 90.655511811 380.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 393.20210753 220.405511811 380.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 372.70210753 90.655511811 359.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 372.70210753 217.405511811 359.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 349.70210753 71.155511811 336.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 349.70210753 176.905511811 336.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 329.20210753 71.155511811 316.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 329.20210753 191.155511811 316.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 308.70210753 71.155511811 295.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 308.70210753 171.655511811 295.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 288.20210753 71.155511811 275.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 288.20210753 130.405511811 275.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 267.70210753 90.655511811 254.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 267.70210753 203.905511811 254.70210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [77.905511811 247.20210753 90.655511811 234.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [97.405511811 247.20210753 210.655511811 234.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 224.20210753 65.905511811 211.20210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 224.20210753 145.405511811 211.20210753] /Subtype /Link + /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 163 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 164 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +7 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 763.28976378 89.605511811 744.56976378] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 763.28976378 184.105511811 744.56976378] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [457.405511811 737.36976378 479.905511811 723.770154405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [237.655511811 723.770154405 277.405511811 710.17054503] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [287.155511811 723.770154405 326.905511811 710.17054503] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [217.405511811 335.180310655 263.905511811 321.58070128] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 148 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 149 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +8 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 661.69210753 89.605511811 642.97210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 661.69210753 268.855511811 642.97210753] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [125.905511811 608.57288878 167.905511811 594.973279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [173.905511811 608.57288878 213.655511811 594.973279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 576.873279405 89.605511811 558.153279405] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 576.873279405 504.355511811 558.153279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 558.153279405 308.905511811 539.433279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [87.655511811 505.034060655 127.405511811 491.43445128] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [164.905511811 505.034060655 204.655511811 491.43445128] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [239.905511811 505.034060655 279.655511811 491.43445128] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [316.405511811 505.034060655 419.905511811 491.43445128] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [407.155511811 409.83679503 455.905511811 396.237185655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [69.655511811 396.237185655 134.155511811 382.63757628] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [143.905511811 396.237185655 188.155511811 382.63757628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [197.905511811 396.237185655 265.405511811 382.63757628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [371.155511811 396.237185655 439.405511811 382.63757628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [140.155511811 341.838748155 219.655511811 328.23913878] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [242.155511811 341.838748155 341.905511811 328.23913878] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 140 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 141 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +9 0 obj +<> + /Border [0 0 0] /Rect + [416.905511811 744.19054503 485.155511811 730.590935655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [224.155511811 652.59288878 292.405511811 638.993279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 556.49523253 95.905511811 540.89523253] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 556.49523253 403.405511811 540.89523253] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [215.655511811 427.197966905 242.655511811 413.59835753] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [250.905511811 427.197966905 272.655511811 413.59835753] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [278.655511811 427.197966905 355.155511811 413.59835753] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 132 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 133 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +10 0 obj +<> + /Border [0 0 0] /Rect + [181.405511811 689.79210753 227.905511811 676.192498155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 661.692498155 95.905511811 646.092498155] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 661.692498155 239.905511811 646.092498155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [305.905511811 401.09835753 345.655511811 387.498748155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 227.002654405 95.905511811 211.402654405] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 227.002654405 255.655511811 211.402654405] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 124 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 125 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +11 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 578.69445128 95.905511811 563.09445128] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 578.69445128 328.405511811 563.09445128] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [393.655511811 434.697966905 443.905511811 421.09835753] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 115 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 116 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +12 0 obj +<> + /Border [0 0 0] /Rect + [323.655511811 432.19835753 366.405511811 418.598748155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [131.155511811 381.399529405 173.905511811 367.79992003] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 339.700310655 95.905511811 324.100310655] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 339.700310655 518.905511811 324.100310655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 324.100310655 143.155511811 308.500310655] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 106 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 107 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +13 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 376.89913878 89.605511811 358.17913878] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 376.89913878 308.605511811 358.17913878] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [372.655511811 245.781873155 422.905511811 232.18226378] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 91 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 92 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +14 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 536.795623155 89.605511811 518.075623155] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 536.795623155 414.355511811 518.075623155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 441.977185655 95.905511811 426.377185655] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 441.977185655 252.655511811 426.377185655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [113.155511811 420.377185655 152.905511811 406.77757628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [288.637795276 329.478748155 331.387795276 315.87913878] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [386.887795276 329.478748155 437.137795276 315.87913878] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [99.637795276 310.12913878 132.637795276 296.529529405] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [137.887795276 310.12913878 202.387795276 296.529529405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 282.029529405 95.905511811 266.429529405] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 282.029529405 247.405511811 266.429529405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [137.155511811 260.429529405 178.405511811 246.82992003] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 228.72992003 89.605511811 210.00992003] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 228.72992003 242.605511811 210.00992003] /Subtype /Link + /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 83 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 84 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +15 0 obj +<> + /Border [0 0 0] /Rect + [65.905511811 629.207981553 103.405511811 615.608372178] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [108.655511811 629.207981553 341.155511811 615.608372178] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 597.508372178 89.605511811 578.788372178] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 597.508372178 265.105511811 578.788372178] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 571.588372178 108.655511811 557.988762803] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 539.888762803 89.605511811 521.168762803] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 539.888762803 231.355511811 521.168762803] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 468.669544053 89.605511811 449.949544053] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [89.605511811 468.669544053 170.605511811 449.949544053] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 438.249544053 95.905511811 422.649544053] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 438.249544053 231.655511811 422.649544053] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [364.155511811 399.049934678 512.655511811 385.450325303] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 385.450325303 180.405511811 371.850715928] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [409.155511811 350.251106553 485.655511811 336.651497178] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 336.651497178 252.405511811 323.051887803] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [427.905511811 301.452278428 504.405511811 287.852669053] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 287.852669053 252.405511811 274.253059678] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 259.753059678 95.905511811 244.153059678] /Subtype /Link + /Type /Annot>> + <> + /Border [0 0 0] /Rect + [95.905511811 259.753059678 239.905511811 244.153059678] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [405.405511811 206.953840928 433.905511811 193.354231553] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 193.354231553 424.905511811 179.754622178] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 63 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 64 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +16 0 obj +<> + /Border [0 0 0] /Rect + [397.155511811 771.38976378 511.905511811 757.790154405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 757.790154405 371.655511811 744.19054503] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [480.405511811 708.99132628 508.905511811 695.391716905] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 695.391716905 289.155511811 681.79210753] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [235.155511811 646.59288878 478.905511811 632.993279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 632.993279405 205.155511811 619.39367003] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [176.655511811 584.19445128 452.655511811 570.594841905] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [478.905511811 535.395623155 507.405511811 521.79601378] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 521.79601378 478.905511811 508.196404405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [313.655511811 500.196404405 476.405511811 486.59679503] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 486.59679503 208.155511811 472.997185655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [322.155511811 464.997185655 471.405511811 451.39757628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 451.39757628 217.155511811 437.797966905] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [349.905511811 429.797966905 516.405511811 416.19835753] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [342.155511811 408.19835753 480.155511811 394.598748155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 394.598748155 238.155511811 380.99913878] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [229.905511811 359.399529405 407.655511811 345.79992003] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [405.405511811 324.200310655 481.905511811 310.60070128] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 310.60070128 252.405511811 297.001091905] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [274.155511811 275.40148253 457.155511811 261.801873155] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [293.655511811 213.00304503 518.655511811 199.403435655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 199.403435655 290.655511811 185.80382628] /Subtype + /Link /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 48 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 49 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +17 0 obj +<> + /Border [0 0 0] /Rect + [379.155511811 744.19054503 412.155511811 730.590935655] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 730.590935655 477.405511811 716.99132628] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [293.655511811 668.192498155 517.905511811 654.59288878] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [145.905511811 654.59288878 233.655511811 640.993279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [65.905511811 622.893279405 191.155511811 604.173279405] /Subtype + /Link /Type /Annot>> + <> + /Border [0 0 0] /Rect + [98.905511811 526.17523253 217.405511811 512.575623155] /Subtype /Link + /Type /Annot>>] + /BleedBox [0 0 595 841] /Contents 18 0 R /Group + <> /MediaBox + [0 0 595 841] /Parent 4 0 R /Resources 19 0 R /TrimBox [0 0 595 841] + /Type /Page>> +endobj +18 0 obj +<> +stream +xXYs6~ǯdqxiiZL'Ŷ촶bKrw)V{awU&T0Nč^NW<;Yf{ʶdMevzKl&^WٍMmf]Vre V#l.Tlz&4v|dlDVm_I28eHHL{ʡI9tcC:AkSd dޏ&W{g֪ƒrilr%f,%d&o4qQ:P(ϋ cs]:8(Zo'D)+㬔>+Aalr.ΧoddzFtQ`n!o +m v/t +352?-@{$q* {]@yHX" b+1!-v:k 8AUz=szRI @H-Ъ&*z}櫡JWZ[;/U[Aԍf!C#U2RjHd84Džx6s ^385TY$J@|Rm'xO@խư|"_љ)h3;<OV٧U?;ͤl?9GG9UȴUK)ry @&/hGXQHM}%Fc8TVii/Z\K{Q)"_fbrJzJyWjA&19D]l1 +Ak +ю5L3F'%2E1лNci8 :{ڻfgM xPDBw?$>DS.?"-@֨XU(SU/5=હP jpp0G"Yl d:Ǽ7.' L6VR!*X|`gH|HyΆ06k@ѓ/M|'f#GZrtho +& fMX+dv,5I'G7ui=rjVcXo:dOP}kb4RvWLbvWSA1aKpzo`޿ (`琤9̱gC pg&#PwlPDIU0QXVu +#S!B\u R**21= Nlh=m(7;\c^E:2vuE]=.v:oڰd1j: (`nz{b ޑ# y^7Ag{:"%[6 lgp{{~+nox65@u|7qYu0X# !wȭF+쮰qŎ|?6Mxeѹ3ptpm8WKèlCcK&s&wwb$VMƆ/"(I䰀6L.=/W1b>z4, +8dXq,p,bM&tAU@ S%T٭5A+ +̰1r¨R0AKǺ$x xClë1 ΢T[)gnƾ뾷\GJ6cpbAJ~\MCrz!l$HD5J~J5ZbӁJ`z|u^K +oC$?,ŧ, 4־훸H*M&-bAap|RDX>FH\ Ub|)We0<:,t7; +/Ѳ˶yp,q'wyAG +W+ +PQGD/sO;<w;筪;s!U MJ'lYq.֮25U߇mS͸W+)d'Lk̶dRb.В4iqu7 Kjaf-FRxbqV>` J +endstream +endobj +19 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +20 0 obj +<> +endobj +21 0 obj +<> +endobj +22 0 obj +<> +endobj +23 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x159 Do + +endstream +endobj +24 0 obj +11 +endobj +25 0 obj +<> +stream +x+ +T(*O4PH/VЯ043Vp +Bc +endstream +endobj +26 0 obj +34 +endobj +27 0 obj +<>>> /XObject <>>> +endobj +28 0 obj +<> +stream +x+ + +endstream +endobj +29 0 obj +12 +endobj +30 0 obj +<<>> +endobj +31 0 obj +<> + /FontDescriptor 34 0 R /Subtype /CIDFontType2 /Type /Font /W + [0 [600 662 663 1002 708 260]]>> +endobj +32 0 obj +<> +stream +x]j0 ~ +C%uc̰Fqyt0 ?I}28W#F0io&cM ڪxEƓx׈g]#H;Fnuq t{hRWnrAE|t۸/smᦎ5H$݌zL◪T=/Vj*++=U.tq˨(Q.Xȣ[#_p| +endstream +endobj +33 0 obj +245 +endobj +34 0 obj +<> +endobj +35 0 obj +<> +stream +xc`d```cp``bPHϩLe a``Z"ݓY(fIg*%  _"'?9er+ +K|q ?N10330 * +* +*17iS͌Rw231U +* *BMԔDEE!ҼJ%<)J1+ٙΜi$%X/SJ_R e%(t(.fvCLEEؔMԠ*qF":@!.Q4R]5YUe}o-Q Lj0@]v]qu67&FxȨi+|9X\c 4Tp7OFQGn!&h~+G Sf.`:(q>0{{ lxZ[pmT> +endobj +38 0 obj +<> +stream +x]Tˎ0 +tvDFb{ɡ485؆p[DxHG4n)mn~MvɝewmO]ۥ(sq8 s4_޶>9}*sO8]}Yk6WӐ}mo5Ғ}~?n$yGIܧvimK*:fE޽TL9[jVU^hbeq^2s{1V5r8g񍒯+9 +2W[ߡFK~m5_C=z"獘sFo3Fg{ӛ'ÇHN[CY"f[[\ERo '#)) ¾3[ .pz๒8 |NN+]7~~eZ.{bQӓWb+UCg?b`8?5hMG'0`{X uy%Sǝqtuׇ]\voq-,/x +endstream +endobj +39 0 obj +580 +endobj +40 0 obj +<> +stream +xZyx[Օ=-lZo.˒-rbَ,q$I# R/H + a+҅ah tB)4L X0CXJ,͹=ٲ|_z{w fD䶉~|f̯!D o޺oӆgO074qbJd!kja|s ߧ}z0B8uvr - ^&@7r~ 9_P/"d@Qp0 +f K~E8W>'s7ܧB/1g"uHds)2ZCaF#w޺u={\1~G~|(zѣwÚ/i !Fa55b 0E"lvծ&fsR]R\pC"-+6髦{7Ҽ +vFk٭*E6eԕhTt૲@Q?ed*PTcd[O*uܠp[n12^23e,X#)yϑr +vO)ggCV)YO]{tS:TC4&h'fUWj&J s imsfO F,PX+i+m_&űPP`lm~ܬzC&rC:U5rh%+x شD~ފcr&)X. mJL5>+p0 L S诳y"uu?-ǚN߫`o2)sŒ&J$Ϙ8V<κ䇘¼wn]=P qn.1ej%oF",kNg<^m&Z=cKDd^ع$pҧuWppk&ZpR.#qJ}!1Nk+e`Gu~V]mj8 [Y=% 2H޵p&".xFدrդ6ZRU!_kXm*Iu<mc6tZ?o5oƪMΈGo15:&pT3S=?J@2bUa-̼u[ٕn!͇:|bv]Dș8 9S$c0Us \mܕX 2kJ`^LԞ=2i*D;}#A}IY`\2z5,Ns7uGBU>fN%ƅb!o=7eyso_sV +E@ɬ}8HmWn>Zd|\ Vmhrz}JU^v*ͫZ$=}"fS&jOO 82+Rl7RE(Q<hLߩJM"Ff XO&8`oPcaoāXUmjj3i^lW(]}.* X`=5Qfz.mzd!T:H%S^Yꛨ*(&p:EJBcSҘ}5qW(1U#ѐ$1E_Q$( bEjֆ~>Yg@nYƾұ6Ȟ[bC!rеHNj*DuQZ1kktZy!`! 8m䱐HD<$Rxƣh5V&3k?ԸT\NPm[V4D'N 2|Ka*˼^FLYexCMy?IS$ŷ@K+|!DPcFFzvgI`d\m4EZꃹC&<_+!;P2m!&E| c aL45Sd<ZBUބ0"$/G\# #HlV]Z QRj6q )XTO)XO(r1Où׉H_k7CX\wTͅ--3[!m2ҪYQ +ɺhTePYǚ*u}Zۅt.*U6LP&F˿#G s'ڿ:tXs +DѫPkq:cѥ̳ pS"j!miKd +wGolo')WK%t~u= mVZ_~Y:18ס+ސ)lV ]$IxQ6e  8>?qϪj U؀ R2f;w'[`E{ŅZua.D\Nn}Pk"->FujG9DڭKZPaJRnc[d >:M53 7HzLoGMK˜SƘ;Vπ DXTBUc>z {%;OXBЍG<ΈEζ d`[,1|Pv'% BzT))Z?KZߢ.+D|5Cv׺~(B8^nThWP^\O(}To+|ng:A@}.)PUL}e2<v{.Dδfzz2蓀Qx VW]f׺5[w2֪Ì Fwdfisz"ѽjk`_ + UzI'? LӃ=cl2ّOIF=9<|}=zѣ#ަqiUYty!#N+& +>K7;&꧛$Vk_6K΂ !X>xcu$*ɉmCWc s#2oULut/a!/<zxXff=Qȓ.UtIc4=-XLW@,?SU mK _ʒm]!+;LweeIb:Covnoyfp6{x㎑q}Q`*BхŰ:sU LXѵ1c;ӝ׭si"޺Lw"XDWC!e)0j͚l-3!3%Xmkn+V5 :~mP-l)ҌD`y* GZ`VOFԁcvl!|3{ :@bEy*+,gVIԷMZ24Y@ѶBP>zsGn־..[*ej澈 'RWF#z͟cEyT& a"K&L +5(mm3 ͦpZReU.J/0Qݴci+z [nطnh!O8+**ӌ}"W82SjU>>zs9F'5 +^?8_qN>&KCIKtU{4]oRfƶB@/"&FlrjlMۼ+-ro8UH$Cs^+iiyCSwԹ,jS`wMWV[" aͼ~ E/@SMNBi'ށkCC" ߟ? Wq#OI4gU<Օt6 4U7%j9kl5,{'@ xK08\c17 B ^!] diYrxڿnr-aðT nlZEq0uGp;H%V9~ w郄%&.WxdY}bŊ9o\.%>-OgWK̥ &*2 V'w6 6 ϳKbLɡğRjES/)*%% O\_,n!G*PvAn4R^/S{(uO., +T4)oXm7MmZK8k]5sן<W|"#7dzQ.l{~?r7a?6$V~!L!,Lon>Kzj#ho!pj-7o{mOm=ظ%9=2Uz;dٱ´ chEl2?pcߴဿA&T7E˼D%XECgww޴iা~m~)(kJfk7Yb{bNYk2xŪ5{]'7jF,w$ͿkV[b1"4%ʑꁫ aFAy<'^|zzⴄ,))ƚϳ?zjw/ {wq!,5O3k[P#dw}XE=C Ieu>D)w[ehf`?rj\ -r>(P `8aCz$\yFV{bPIvY*Ou鿒We{\W*G> +endobj +43 0 obj +<> +stream +x]Sˎ0 +tvL=6^rM,g 48}5!ј&ñXi3S8CNc2tjךakVu)>=n[q?ۖӧSC|1O_O ']Ӽ:̐B_dj-~>=Kٿ_5Vw!>ϗTuMs084s{窳CImrT).G{=p"N%rN!j k_P;vDeE>-=s{UWBNgKZxeBpvZzbP‡~SMM_X|3RS͜QtF8X-B;.##66Kl^E#Ӿ).mu^~Q\VHWw[3ceE +endstream +endobj +44 0 obj +494 +endobj +45 0 obj +<> +stream +xYy{kgv9{꙽f}hW:VK.+ !$1GW6U&lc$q8pJ ¸랞j? y{~BrԆ>;=qB6BĆ&}$!鉱q}^Gi/@Y{g;#߅řcʋuivlnt-!9DP@|^.=үs410r D>-.re9h)Q9#%}Gr<(N9TzIq[Vq (Hq%'3KLqFR `ŸC^CL6@>ztLQD6,d\ƹkWP~gqYæ; HhKL5rdHBRmP]\5v6dcv ^NHhT^IF[# 7O55J4X cN\iá@&tDiK@,ڡAعL&7RS<\G3{ g`uщc6wn1f ,油4 Уdϋtfnu-m3ECRIDĂCE4XX~3rp`We͂F6{aߦOn]lRpyzΤ59MJi|[g0r qMRuP~X`,dV[k 5#=l+i+J<6}o^ eU6"?$ç>40=]ۖ7%oKv% vٹIn }ԩΰEtbk?b̕ŗbm +?Bot3D]Z|.Нaq+aE͢\.pinŒ+Kr\ o䢝(v8hqɚ- qB~t=SFmeiإ88Π185mq\i -zB,Et5'о4MTǎ?zcs;w9q"K7^ uD%H& s$5+P:^ty8[3+7!/5|?Gیxlf.CHa26]8cb/޻ajǎƊ~791>}gL5PƯ@ae#.wggx9s9[:&amh 45*ə[2ocqFaҌ3ާ }OS,Ǽ%:xgQz,dz o|T'o?~L nkVUtKx)_u RI Q,(I"Q.!/$Bkl]s(HWఁ%[R,ԑsMJCItxdNCZC"Ғ8-}"~7szJa?OKi6`Þ`iwG}lxVrB.˟Ψ|4ΆhYTR|Tf68ϛL)#<⧞e6kZNJ&=(R(|KKrD",m玱J.$hgYCiiDS O38zTqCD|<[]tA 8O*Aii0书ھKӅIxͿa^ b%βi!&xKVz5[2[G9gG0:s'iiWQSG] :1X^n[6s)ho]I4򾍅|h + i+-Ł{-VE)ˡ5KSZe)FUU*qSdvD.}/5>kmǁd?wJCvS: ? +8Xk4dp e=VEXSUd5)Ê !O9ԱrU +k +y*o)N+ެ +{ +tu&R$pQg/gQOtXL x53-ڎ}خj;/YryՂTph\kR;)Wd"U Qr [)vY :ZAO[X{vu *& +#B;q}@wS~e\%W+<`hqaׇ)w)= #J_Be'_"~V8AF2M>ac{<3!weL_^G윎?`OtіH)YeQ>*:qÓqM0W +R>7dA +J˫E`K%ݟ6_'A5|vX@*9[ߺn恡lشyhH5ܙ͝mĉG=q +|J\TxyR:P7T>jI ^ݮqe+躎GՠWbIM;thP=־\1P=ZqpxrpEB&\D[W}rvخ!6ۡv؛dbzsh2lkq+NʻwV]G:wN/7o-ű30H0>El8h n.U!iTp?z\ [_!E t@\9ީ=LG)KK!uҙZsMnvO笋IpC,Wi%0 wÊSH;hAY˵uMU-]iC%0mLciOW.Κ;3MG֥u߱iόݕJͬm`\- <}ZMSxaӌX-Ūed)ҧĦt>u_Lz[ 0'Ȫ'omv FjqhzǦ9uaRr_ 5d2mӎ*`8{lYT+ erEX'M+gz҄)iYZdB!zG vpM[uIb+ԔPڏlOnoN$0:?k ~Fe'j aDnE x%|/*q$> +stream +xioE,'0 Wi $Y谵rc.^A6L3o޼ZIVp[:oG77'חjrup$Wg4du*^v+Vmܪ;8եP+{} &k#g#/JK_/N<@_ V,BSBNTl$.ފl?里CｳKT]{(绾_^ӵ\KSmm6]V6Z'?LU㭔mZvL?^::׺^T6m%bimYaJpֵֺQx06:Aoᦫ4JTp_#Y] |rVu0wE'g,%>7GV߼;:?|hL#gaN Y+,5ʺ ʸGx 0\k[ڡwh[n +ԾT JMWgU UgʊU;jgImDUkoS)%EFS'T @afX^aᣁ,LDJEJ=mDP]\77$m5ԍW̻ 㹒 SeGFK;KޖF3{-FE;cF#m [H( gP C' <#kh:\'DzvC-ue8B:(d">13'dZXTg[if1tBCJ/vR؇GHB6@e| ,RVTN-IGy|%Y|AÕv' k~t@4*xd6 +5E2C-L,_1'5/¤j:J=r0bn>؂1o8چ.]c$TCXYX"4? X #'q0QlB'f0K,0"ڈg(Y +`x]P%C)?ԹPLX{I'kQA +l^ +H\\~C=E7QW$ U i/3  +Ag5m$9" n"rOW{! |$Vjݍ]i4SaDF>[`=Y[#e4,u'+"%M$_IT}Q,N{D Vqj= +4ف9L](9;VpB"}^T?e4I]vhl(4&8ᰡg:/bUZ5'yyƜ"2&U-Ӏ UrL51X414ic|@€fY2u!fxcOeb/\ -SHm!j1ǔI%)v>*/RڅlzC3yëb;ȡqa$3Ǽp)yMi!98$HO2sT˥'&*+1Q^bFŢe@;w5"ͳJV~ֲB +OiUnxtY``߳V 9z,Ng^XVoh%u#ͤQ֮_ |#Fd)>evLgg +.\)a`r[q?r`qF W>>S`YtURʖ{u{9+@! U lo `:dl"q5!Ya*k*:Q5CZ lW|pg gTt(Vf Sר.n/ڄʔ}+S,j*H? VlS.ΆUt4M=ͧqUqSY(U/@އ{xL;HOP.+E6_+uKqtͻOf?y2PxQ%Kdœ :wWnEs,s<ͤi=$NNtޚIah7dZij[֪.I]7x4+ IlGyE,>3 Kq,vν/xffmߥG^ɩ}|wV|k]e:8$Z(1ok%ʩRђ_ry"yHJ<$5 `{O$WA7ֹ())јŶӥԲO_Y&Kq\ ?8'oNݤq$?EZEjuy-- Eubc:2ѫ?mJ%rg]5APaZ ER% CQ' du<ɨp=D><) r{*lY+xw@myߴ9s# 䥮u~=T =ds8tG=ٌ㾶 нLh[:ҲU[ݪFA8~S+qS"¸>n=JS!bn^-d( 1u;)Xpųrv_+kCf_ts,bӓHAVrGV8rAN߶JcqֺygS%{P%(LۺHBBV>EiX)ͤ9fCMV͞}EGc_tܶt!v b'bB9r{#pҋW+R,v ϙ϶[ڏʋ;$a.ܩ?k[01Ef|S3]{b9i=4Mȉu6ݿ]ܗmغs)vl]޹ľuV_ⱦSc,O%wsS{o1sƠy["49 OqnL62Hњs>>> /Font + <> /Pattern + <>>> +endobj +50 0 obj +<> +endobj +51 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x147 Do + +endstream +endobj +52 0 obj +<> /Length + 26 0 R /Resources 53 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ045Tp +Bc +endstream +endobj +53 0 obj +<>>> /XObject <>>> +endobj +54 0 obj +<> /Length + 29 0 R /Resources 55 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +55 0 obj +<<>> +endobj +56 0 obj +<> + /FontDescriptor 59 0 R /Subtype /CIDFontType2 /Type /Font /W + [0 [582 719 719]]>> +endobj +57 0 obj +<> +stream +x] >C1ҽ>1+4*sۯ҅( /G]EA:oFqrg- =7D&xd? 9?2Og &%yUśxO}S[DU{$ .Qi$'d]KBgsI޼NV*FȪĮ>]eJ+^rr_!?s +endstream +endobj +58 0 obj +228 +endobj +59 0 obj +<> +endobj +60 0 obj +<> +stream +xc`d```cp``bPHϩLtĄ(萑"^3 +xo*%O8|D [E|Ċ 7@ +#)fvcAEAUEAPf0;tꯙ1S +#0P>fF#*Sc#33SAeScS3c#qcA11ccQE2TBX_Q<2NA\&>%qFq]ZqE~ASN8rοu22`"VvN..Fbb"l&jj`DMW~ 5#duikDeTʹwWAbb`Wo󕁙P2}_\oY4jـjA:Xta`w?[80312gaojf  D3hh{ +endstream +endobj +61 0 obj +428 +endobj +62 0 obj +4266 +endobj +63 0 obj +<> +stream +xio;O&K!À-EMl*D\;f8oIJ:ƶ9߼yR߹OtytY-ޖ{_V۫hYhkUwe|i<)**/}(]kB@o *toO7@:Dm~2~ۮV&`墯m 9Vө.!Z !ՇN$6ފAO9.d]u] KT_kک t:tMW\{'s5W '7omf+kf/*g~\>}dё,kH)e#/T촲~vQ͍Җizڙ;)]S6Qmk$F}Q^iܘlqUltak H8-Ӿ˸N^26o+XP9f-ُU"gA%nU`QeU e5;%:3Ǵ3!}.A@6J "X McЀ/d@rmͭa ȊC8 xi!E A!4%nQpWsE?]8$! ҁh=\5)Y# i9kX-v w‚_}6XMmW>lyQLhp~J}j!6#+.tٌt +tWk;P"jVjTjdԺe.S{j4hv^4bI*Ҥm6m v f~wBԂD3ɊXA =r +aBH8?>n]2uA~`O;/Su1ykF;EW;jP&C)GrYf~li))R￰'ʺ@ Aq c8G: ,?A-Kض.hSN\ˊ7ZHb/ba4VL3Gw +e iu%@pJsS[=c,*=- ^Xc1=h[0 dwDH+m}JDGrDr#^GDfPC"EJX1 C, +#2[:ci5L}SvT~uu+O5m ٮ5յ.KD.wT琚gЍ:,dM%@:z^l0JeP1zHy_0N% ZQv*V;QVC}aŞF+oXǨ(7-0rËr#[ +Orc xpAS6`F:b[z3FO߂vP}F-O| oAR>n6>`X܎kj ސc\obyEy=< Z|!y&W uS~3{d!460N*sQk<ܞ aE_0+GrVd)-ǕcmJ#aw %w & /,΁ ݛ.]ĉLIuIF"0DjR漣J2OiUaN zc? U4 +c3Q"V5[!KP&|SuLntȾiRF*Ggg٭@,]&G -ڏhژ.zjM䈘m'" P"=~Jߋ*x);E}ځΊ#ƍ>d + );*<(UTxG:Qᵂ2I +cQ>>> /Font + <> + /Pattern <>>> +endobj +65 0 obj +<> +endobj +66 0 obj +<> +endobj +67 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x135 Do + +endstream +endobj +68 0 obj +<> +stream +x+ +T(*O4PH/VЯ04Tp +Bd +endstream +endobj +69 0 obj +<>>> /XObject <>>> +endobj +70 0 obj +<> +stream +x+ + +endstream +endobj +71 0 obj +<<>> +endobj +72 0 obj +<> +endobj +73 0 obj +<> +stream +x]Mn0F>" !UEԴ{HAYRďY>~\ef{Uw%X=F/vt]o_N"X|WZ?̢e7k͓{zR-8 +?,?4_e.F:q/M$Tm]6e|^EAΎKg)tDF^P .85"r8. p\Kf)_s5X3a~?2Eف]dcEzUܫB\q\_犝z)Uuwbg7nw4|G9gj>Ӡ fPkR-4iK44ŅB> +stream +xy{xUyϩk-Iҝ4IH4HYDԄ1$N0!b&!!&I0"Q~̇q܁A8FG+ٙ}y:^VBd+a$tU{3!tM߿ I;ԬǦ^EH=-o!%ʪp.'NB]9vp{V._wBF +8n }[qpͺ5w86P.ߊHDM0dXZwM AV,&A_️ge5Mf ^Yf//)b2Ҝc/~L5d3Ms5vj-C\+weB28jӍ->ZEUuv1e:nI^LA ma*Jia\XH^~n|1bx<)_=)A4]TItOB R5$MXc:~_=Uֺ'/4Цnʳ/_'`ФE/k{Qfh&R0 ЀN)#[d@]L&~=,I-29sldTRX@~8C('$XYH_Z!#Qaԡ&QX]fę1p8]j&PrHUݹ*=d`fcko +u׺^aIb@TV +~<pz'mg Ͻ,G WģvNQNpXs"շL:ȹpG"sLϏ R06g<ܒ>r4f >I f૯wll{;7M ,)o4ܮ Of3 ͧ#+*$w޶qT焐})D^M[j>G~@3h;b|cݲp742BY ?-^ Uã;O,lyf\1.Y5~OG@K"|&)D{AއPŦPC؟ξx~ui-~Sسem{ҧ=~ ~fOpkqq~#}]L7 + + (&ES@1C00AEqF M{b1:jf`xDKA<#xBd +@f_Qh%E9EIv/aˈ قg~0Y4?7"oQ!NDՂ-$U + Cm}g;_/u%:+އ1xCfF֩&Hrj@KdyAf$%K5frD_QFE`*82Gtl%#Spv<wZ_[KV"S"d9\#|5&+-)KwePcc1(>b*3DQt# +'de<eVpv}<5c?XT|O?*-xm¹{V[x>6{Wm3LX@pо,dR,M,S7l}ft= xq\' 焼l_ .T%]9= +LCf"tDA,FlDI!1sÅx%<7Dw 녆OXa`L;(3st"!fwZ"og%Btu3#Da3h(I֮i`ĩ z&D hȲ$ +IP(Bxa̬IP<Ͳh1+!`DTi@`ld9 +8j +ǨІ(\Prd@ZsÈG(?xmOХR3 :W 7 +a +a @զ&RZ4yxx +V(.a6aYǵQ8coj}~S7M߆h)lprn~bh[8//O6;.4@6QYxpDS1һS/UӤqA#OY%/뿨xHM_<C0e"d]hehnGFf6:N%ӡJItvKm$YcTqu^WyDđɂJȈ|OD<21IHw>;~f_^=Pi06~/̻gzyMg:etz0ianQFU0tncxvqup<$D<42APb0\h}:#cY[>4\ ~ڡh +b6ű\?((se< vQ;-tz\Hf8%d")^pS o$`_-@4N) BQ.jA <ޥ.X]8kYE4AIS6vqy"9_bɌkͰvcSBEp)DىܝUvnpդH9(mv'4mrL+eN1XPH&MĻB;`>fyE Ӏ]xx_w5{m{ƺέo}pWϽV)m< e?O< M9cZGIa Oow#=Bߤ0b")EQeekxVpBy:q[ėkNcUr&RRĄHr1Ityrǂ*[sJՎTM1 +i#O8 yigC4a(=_YXվgaXJǫ=OP6}*@FWc`mnD1'sI=,sGpS0K *ME/8;}06° +Yˣb(>scoLIIJF,y5 K-g DD3O~2{F8ב1PxTN"kF !GEYxr4 ܍g7N{vsn|1'@Uo_n_>Me+`׬€7?s-s)7xn2b̘v + .bbFN ?]9͇;,؅M (wxÒ_1BL]w%箯;g_)t'=w$FF\{0{~pr|I2usp%9dht!67PD2m]"aa;;ԢjB Ƥ *VpWTr.V[Z NwUVoD'wE%E᢫/DFPHK--E*$>A2.\[~ H -hBCXTE|_YZJy΂p@+3(ZԆg 0ޚǫ<Ҳ4ϐUp4q|Kf~29c~Kx8\\RTT n]9sZU ?5(ԊZuͮxPq2 +,Z ;<:W4hVĜ@ȱ wG|%K s5*t$tdۓ!&#mY|H(ݧ/F@z[Ib$KϓXvVWx+[Vlߘ xZ],^伄4 03G +4_E@؂:uXS#8h4:ŸoϹmQIސ b:p$U R,ay59XިOK{;X|kؾ-߅ghX_3w2~fa9Iw2]HGX,|-)]Fmrd&~I/#8>#Fhظf,~I64Uqښ^M杝$ {G*Uj*f^ݱ'%iHd֯5oU8oLGLjiaA.?FYj +endstream +endobj +76 0 obj +7171 +endobj +77 0 obj +<> +endobj +78 0 obj +<> +stream +x]SAn0<&@H I}D$/@;Ԫz9iϴlz\S=iծq +S~UU&oM·y\TW>l2ȽZW?R4'}񺮟ryӵu1˽{]!i=dڿ߷UtSw($qdYC0>J.TڂsP琱'Y3"0 ?0?d砺Cb0yɍf[4wYJ##0⟞<[b ס,^ +ި9,'O#?k!.{Yjm]x KlԷз1oP@pY $,6`]{),_v[7} +Vu/x +endstream +endobj +79 0 obj +427 +endobj +80 0 obj +<> +stream +xY{[y?\IWZi꭫+JW]C{{^mKpy:4a +RJ@ʣtдә%{H2Z)']߽WƤ#s{;}]B4C) BBܸ7y{;a؁}{M::X ?X;rlw<[YE9k g9MÜ+ D (ƶ6v?^} O(^k"Du}81-b!<8Li[.G[tPEK\3 +=>/8RM-N~U>gD5(XS@>C 2emVFqy6HSpp#b!bP@ƿ?XalH0R퇂S-9 ,$sxlD"WsKbO*#8|Xg356!4[{ʘg!ևF&|;:\4+.̾hͭ +h/{KfKY͉~kt n? 莩񠄇E!QgWq + +p +?melWR,Cl4LA?\n=L9ӷ< : QlǨ5k-Z.+$2Q)eCbt.iQ+BHS b;3y5pLg<4c%-<_;->P kZ4ҏy]KIyUt6+ˋDIҁ! o7PdJ' $^cMw/BV̟#&YlxF뮢y$aECWXŦU9 Ck gYo+)VrYO)Bd z?O(VncZsl[H WͼiL̥h(h&7ӇMÈK\H"Zwq ѝnFRW4FUf z)9)YcT[1#^S=j]E:X7d (I$0()}-|\rFoΪ~%9<ӵ]'(i;ԭJ:|=$^8g5GѬ79;fe3ԒW/)1U+C?sh8D2h%%vr6> H{=\}6Z{l3bѴciiti-3O.}3٠Ko\R)]%$10qe hqHF"S惛䖺Kv9:|n+[cP' mbV';'VBVZd+ k!=~WN8Pg=`[ l_yp5 (! nاsLM':w֠m:5,M e.'4mo\Bۣ-Ӣ] Y}B[]bNNNSKЗp +Yt;'n/-<~r஻ wݝ6V[ f捋sco*I Ƴ^m}S#űs{L8ϝӺBuW`I;Nݴ+y x|x%2M()Bқ"[F/2݃jx^ari96 wg, _7R8?ϙ|^H:)ǐMŤ7uPaGFcp܀tRt2FdC +xHi( !5$ >JaB/q!aMZ]= @gcB.z(`>Ru}hwx^GTH߄k%*ڏhbB$?V =YԠOު]iT&E.8'v,S!I0"?9 ןFdvSE=M^NnCy--߅J/ ᗜ&G#\S?}8Fw972pp]7;Ć pq +fsY-ymo">m/4 `ȨEi`{B} +endstream +endobj +81 0 obj +4216 +endobj +82 0 obj +3373 +endobj +83 0 obj +<> +stream +xiݶ;OOELRԕ|MѸ9 $({8Iw7}i_ Ic6,Hzpf87GVkѨZ'__TgɭҪڜTONen#npEu)_VE72nazxӍڎ-@f<ٌAp"&Wr|a"iږC)3BBפFOD_izw${8F S?ɵxrVk qr)]Ԫ]PVruWkEw}wZۡooVjxVQ?kݮ.uOϷv l~YW0Ku .W8oY :8E=ୣ&|o|o`VO8p*8Еrתg: GD",{Cɟ5$MM4U'簯-A<&T~4o7v∽EX 8~w DЬ +%$N9eE!,됍EPl{H7F'_ߞTOVO?^\z_=gճgՋW/I۔Ӷϔ|*4,ןLn[/'QLL<$iRHW-(BT"hn~w +\s|%Ӻw+6Dq#8qyB؉R=l#F%-\}VGO'q![2{`AH1l'>̾<3q3[Fxq}ٗb6~mg5_-iZy:8.~GDdz!-j*GlfsiȠGF\Qӓܾsl:(2Z!f o#6A,cA,4)g1WD.aYЂ9{AS9f0mQ'1EޤK.">@f):O"j;6EǜcLeƵqE٣dV,u,P?gڻfmZĄ26{9Src3/jChm' +2-GÅVZdfg_]=7'Z{X-SA.foC|zƽ[kjb"ͻCz̈́b "Kb?Eb:,P_1'Ź{gۓس3ٓ`(y^8vv =,}ubO{vڷ%ORz+N>,i̼Fz]۸C%NgY@&|هG1t`pbc۳gx%dbHl&8=wq[vJ +bYPZJjv;F1ԉwhcMYq֡X >wlˎl6qOc-rXRpklǍ|/y6d0+d:$E /6eE!埱%灣,yMxdFCX05׮8+ќ.͖sXNcTe/IMf h8C))qU1WZ6詟y՘WW[XwRU3P5A8bh0@MiҠ5/˛ѶB@hy re{KkDu h + .`ED!^:k S*ngNčH½Z3Y34wTQ♲h1[%L|1C7vY!eaNƺw6H㧅dȜf4Y;(Hlc\[/ۢr,Y9}p|$_fZV$" Rp>I}8ob*v;$4Lr]!#cH%VH?J2#Ρ1b'gru5Gpa.S")km;<ܦv"6gC^Z;72J *rnyZx LmG +Ƅ< p܃Ž`*7%W7T&5nԤsOiw*l37=d18\z1{0djݦz ]RJl\wWcl}ԋYs hqk!NGWp$9L +sα!1\]lYO``6Za q)x2;*'Gύ4vE13 RiACJ>I>)MoOQ.E}YTg/Lj4:RwE%!SԀi;В4pɌsR@l䇂[Ȼ]m@9vPf=/0=sq$O^rҴ; %uZ-:9jcˇSi25:Bu&e8~fxcy}D`\yiRI~HS.MI VўaE޷*wnlڭ \Ur :)Kڌƞn _ zg8IHECMۤg8xJ@FpVt L |^DT,u-魬#'t|Ҫkk/ScؘD(!LQ>C5Re?m# v~^=t4ߑ:?/yHHo&a,NY$WnP.:&aWԤ÷CfG#6slXɄVHuwudQkҀU( _ToyG{}6mP/g]\?vHȢ.:gmm!q&ZጃZJN3MM  &nAiiw >V1M'9s-J4v$gi-le@~y )ktXaxa@T.4KhYb$C>2Cʱ1'68n|3QGum6ﵞ2"pk#X/|l!M@ z A8~AR Iח⿓ŬO +endstream +endobj +84 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +85 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x122 Do + +endstream +endobj +86 0 obj +<> /Length + 26 0 R /Resources 87 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ042Sp +Bc +endstream +endobj +87 0 obj +<>>> /XObject <>>> +endobj +88 0 obj +<> /Length + 29 0 R /Resources 89 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +89 0 obj +<<>> +endobj +90 0 obj +3807 +endobj +91 0 obj +<> +stream +x\Ys~_E \,\*Uٖ8+>CJQ)3(Kv~}f=2mVJg[}[eo=Ϟ|}~yw]'r.n'e@~@7tevE7{vEe]>۹+ݾ>*^/Q"9)>*i7Y EY&P?f)E p X8RʢjYEbۉEMv]1;Gp_U? =Vas66&˛n2wϷu̫rs(z'U;wy]o^- +Wŏ򺓁BNGE;ǜ~s+Ϗă͞|rqp~sv},w;wx={}31*gu,Wvcy$ =0J!q0Z  asF;6.k9O5>*4b<.'gz̋e|046FԪ ~qX2h`fe>Yu#+XnE&q5@®_ ?R4 +٢v3zeͽ4X*Ų$}Bx٦%4^p2*dc4?.<`9k( WeM!]P h(RL0)@P+tJsj#*)rʒ ۄiZD W B*MI)„ŵ_΢\ژ\oճ?G9N?ɗ*#R +H&ľBBR<e3_P-er`g7 0N(△J|nGعi6r"?w_Mm6t6Bq};xɞt +( ` +6P4("W +6 LsUp$c.$?IXM\2+O2EE,E+jihpVE7m6*lq/} +`6)4Gw`I8t|!Z6~_םK,yDV䂩=dci:0 պ;+hs0+^{- :VVMLS;qIӦg'/I{.?"3Z#;)7EJ1ꅐj#j @t*OS{aǍ.w8IPǀI 9vBc Y .m] Y]Gh# 0ƢV]2hџ:*h氙LO-`bDQšޏ?Z7BƆ&iSy<v#,lKT:Ed+4D^-t0fP4MrϰhhJg+xﶝ|; +QcTM i/WӲGGgCKʼ:j{0EGOcIݢ-h,6Y՟ӡնpfiZnc++b~猏7' ~k^􆿝9;܄.] ??L +$5;/o\<n5izGX`cb(l1`q _N+џt6CB\nFXM؍L=$Si]h%Ȟ g!_kO{U JL Iے'wO%j:ٞZGLXkCG:f84q33NFCD Akzu[dNtDp4šWi4[YkݑgJTcR S*@P=ݶhz5l-J@e;R#1~{Lc57eklibrgCs9<] )dՖ҆xw(,$';vN:ⲈxI+w&wˣDkوVsxJ%Q"L.FiLZ8 IHLsL[;_8z˴%iYm(XZ6{σ +;v){6,z(n*u?LA]zg2/r;i׃7#IϛF%A]2+_lXa/5t]^IES;'m+}Y6vigrg]}ӷU3yAcB3Aff&^1Þy ?S2&Xw1m.mwi zTP%u$1z +endstream +endobj +92 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +93 0 obj +<> +endobj +94 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x110 Do + +endstream +endobj +95 0 obj +<> +stream +x+ +T(*O4PH/VЯ044Qp +Bc +endstream +endobj +96 0 obj +<>>> /XObject <>>> +endobj +97 0 obj +<> +stream +x+ + +endstream +endobj +98 0 obj +<<>> +endobj +99 0 obj +<> + /FontDescriptor 102 0 R /Subtype /CIDFontType2 /Type /Font /W + [0 [1000 354]]>> +endobj +100 0 obj +<> +stream +x]j0 ~ +CqN!0K[Dz=c˩aS6HҗAp=fTU 6]dqG4?E3pxqq}eh%2UۂC/Ͻn&]SDy= ZB]Fs2Ј9KxV!N w% {oG(0KdJ1mT9Gcp +endstream +endobj +101 0 obj +225 +endobj +102 0 obj +<> +endobj +103 0 obj +<> +stream +xmUlS>؉$/ ｚY+X=AvWT;P2 PέHB16U0ca2++?&QӴ?ZJS;%R#{s; `Ǟ#׶Q2z?>0.7w\gQ?7bHX/ OUD(Ȉ[#q,n'b9~xoC +,X2y&L)Ł`g 3|-ÅBi(jث[MGuMd fpV"Q~bťM&[&m-bc66{>rg{hVU|X*Ū^_czdlj*zq_G@{V!PZD=-t>XY[^ SN95 2W {ҐRG+;/[)o`_7W00By84YH+'-2D&< ǰdr[D0:|U. {ŒWlܢ< +o;XQ>=C0g^vg  +륟)xj`ypcZI(/+uSmpEcI9.Ŀ^NE o:Hlu2rNk\x_QT?-Ot5ø'Odq\}C)J xM\#1Yg8,c.?κ/5t\;r̭onjG?td>ZUW\md%%#huW2ix " NDXwDb2G[w٩*;U +-bziP=N#<_Trq֭!ZKz,$o-uT2X(S ҔHK8c6`)g9Ɂh#MF3].aDAxOY9{ts,s9ȩ7C[UR6j6K3'-j`ƾ~t[_*x9h] Xȫk>GZNt56YCZ^Ý{ ?9_̜w~ 5̱3Fgjaƶ7#*X@| +g2UV5zS\jh$<' +IaRzNNz&&G'O 6O8,!' :GݽFU +zTNG]Q,cb-s:m+$edq }M83gV#zY%U`b +CD: ,d^W4(I6T&di$$IW:颺kNfst!HW[r)dow Yc.1G\"GLs3Lx=̟2%⿞vI^l+ڞ^XW'քVnz\aА>%RJst&"z_YdhYCK|~ vL} +endstream +endobj +104 0 obj +1764 +endobj +105 0 obj +3812 +endobj +106 0 obj +<> +stream +x[Yo~hKOt`(𵉃8k!:-guY#y!جb=bXYi|l_OS*;f{7Cm2UvhLSO튪>k6U}֙;-R:EߎDb2k(^\^ɅLl8\s +MQלx-)-dz)ek/P з*b(;Cp f\^F!W/uUuݯrs1jWY^fuex/ۯ5 Gy9I?5^bo;d]nsXoWd{7kjԤ-nI*R $Y ԾVx=ۼA<7d*BʪdDn 5rQf%xGLR0 h)&Z?n~VtÁ^Z|T~Zc\T`gMCRK _$cN/ݬ "/I4U2BIYפX|E@>^S20Q`! Nԡ+h^s sWEW FM@>윶cDSL]( +p T 0@ EhU\/aEr/BSG6AE.rd+b-*DA|ߕT$ R6 )˗ A[śGZ[SE~ +JQnU &S\CTTJP.*sh ^'˅T. "WOa^9Ͷd=d#Qo< AMLMb%+b +& PEwDŽ3*phԾ%M\-楦KhQU4qm#`# "3-fp” y|D9ʞ>^~˞e~ <$!U-Wo^3$ye䝣,W:,`P:2 +f$d;o ݌l3aq{@a~wVfl #{ 7vDɩ P׬& F$SzeGh3mu{mՔ^"ӱtZ͠h/+qP .TJ2'Eß,vRjM2͘ E;c2h؅䩷z>VWuѵ[SErho6V̱wa늦\b(\p( g4ޡy=Ujd܇eQe_7$}xBdE_qCVx@.+`w^ḚBr"2>SQ$*IJ$J>>> /Font + <> /Pattern + <>>> +endobj +108 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x97 Do + +endstream +endobj +109 0 obj +10 +endobj +110 0 obj +<> /Length + 26 0 R /Resources 111 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ040Tp +Bc +endstream +endobj +111 0 obj +<>>> /XObject <>>> +endobj +112 0 obj +<> /Length + 29 0 R /Resources 113 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +113 0 obj +<<>> +endobj +114 0 obj +3621 +endobj +115 0 obj +<> +stream +x\o>/=910 $NҤhҤQuQز8IMҿ3>Hi[7)jwۘ}g--N~vss8;'o}q8.Nax₾o4v(m5c3w}k|W\SSؿ.ISW'}Tү헫tLɕYwg.~ RWMg)M4Mjwf}S5WtrmQ Dz7mmޕm#?nؼ,zsm.et47y[s67|#{{y^6<2w'Aޖdg\A5[՘WZ;L`LAD2a=Qّ)w>dxlHmAM/LzڶC>*gd J"V!JJb<=*86QFMh)Ӽd(H3ń!B/Fzơb)(?\ڏF {L(툡A*A 3L|]NBm΂ + C48x߄RWʉ_6X]i*njD+?G}j +̒kfA +=q1N܋܄M]eC7czJe3֖ζκ5#Ε׈[ s=`ӰvIJST6s4)7DpciMAQ 3DB&ֳ>50 5n3k8o%C+Ev:nnI=7.?-7V=Kt88'lrms5=wsy&X,0Ѳ_`wJjBZNKf|/@@ #$&UL+|U V" :Nj>Z%Xj?^hwbkڰ+nm$No*v,*ܯ.xHʳwnr:!:餾xz]w q,_{{wqi׎VzpwDB)ƭ%4w\L9tC*ƭOnVR5$/kJc_I&'8ĵl-툺}wA^h#I܉MWUѸ+ƽlNwXG캇|)v;.كʥcҐQ8'I[۶#ulΛ՗[W>_qoa a)h-&IT=z>v;Rd&J/3Myq?x+S| ڗhꪱ ڵ]HW$wυJӖkO83x˭Ѵ!Z[WC;{8.m?Y~g.x}iZ,_G6/xʛH+jxlGWΤŐ>/K|hqW{m;䅂nΓiٳjr +3+a4n>ťR<|=20ٽ{*Tx37r@ +endstream +endobj +116 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +117 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x85 Do + +endstream +endobj +118 0 obj +<> /Length + 119 0 R /Resources 120 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯTp +B]h +endstream +endobj +119 0 obj +33 +endobj +120 0 obj +<>>> /XObject <>>> +endobj +121 0 obj +<> /Length + 29 0 R /Resources 122 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +122 0 obj +<<>> +endobj +123 0 obj +3638 +endobj +124 0 obj +<> +stream +x\mܶ_!KVWw@b'Mq+" |{W%gH#zY6jp8 G.\cWɛkNK^ߟ$omW&77I\ ;KՏjڬlK]u]N+͘U$4!BNu#gRISY^v+*RqꬪS8#,M<+*' //U}5-+m>o5]]v::\+emmnmoj6'\EtYٟgiQlOҲmYͥ>rs5g:85?xяeOuym7w旷"Sk]`7(NG[9 m60.&Ǐ5C~'}[BuEAg6bFӚ1D[Iu6V_~_ly $ u_I[5-e|P "b_Ud-rgdWW1nʺaU'C6G</@,]~jK;uqY;S|g {m#MIdV*CAr9Z)l}Ʀ +T2@Ȯ Ɇ.E8nm6דBq4c:(tQSQzUu,ՠ sQjbCe4ho(mF^JTe6<"*͹۶5åkoRo%iqFJcVōim>:]31Bym0|f\uIj;ܖ2ò(kH E1[~nX߭"l<8 *] + EAf?~LuE*<\Ef(F\* Wc8a`QOMMs0os izB [g{"*z +29q[>Fb<`da_!ᓒO{:l#'ٴA, !9xTd{9׾a(KCtB] + :C@CKH6 S"7OBUjr{$@BpF!,PBTP$+,d=Qe6hT̑P(]qrH(G cUՉDG*Za@tJzK!lXz9MB) +L\Dlafy=]ÃJ~t,F=5yXךV/DӠmgw, +spۢ0(bt?q\W~DR 8st'^+8c·f],fA"s{(?0[qPH 5 )0h- \4ȿ{MVA;P8[;z4!Ɠ#=!9?R4:+CO>;EA"eZ!=F1j|^7 ۸7GYA,5/É]8V+r62,&6eNJ5U./5twr1R}I`1^=9QqpfN][Ǐ~VmZč-d1Qmg=7߳cl.}>̭?th4=ؤ|qOM*i:.E'pSi𬊪UVSrx@~;klA -AcxBzV02!VbC%\7 Hf@n. +wzdbUg! PPPSHJ_E~24?!^C @c )àSR% s>2F@ E&CC%@SNGCi9]qثK%w,cr{$+te'81YߞbQE&~VJV0ryMi[)fH#XLltvj,Fo)i3HQMۘaX'= +U A(8d,Y1΅0PX#fEXhɝc|XC\Fx00:Tc}Lqz!["h/zC8"kvN?, &r|Q8'.;6 ?F zr[T/j趩sQe,>M !բʇ/x/xm0}VPy)%.5g<3`i\ʕ&^70&`9Tx5G]F!}ĩi`1$ +9`ӭS QZ|h\VȧlK:ko fiw&*w uSduWf@΋;* CUdw}첪f.I7 SQ7oo.+ڮop^q7oGz^s5ą69m#Z"-lnÑX< +#C"KnRM_2 `NyŦWk/|3?`-M +ܺx?&y49هy?K=K| Y?zFsώ@ax˗4_96ϾbgAl뛢v|Q5+DuZ|57:pwkzB|j"EU]]TҚV}3{1Îx:1yHE3~j}!kx\t8Z ^ *XglDG_+ +endstream +endobj +125 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +126 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x73 Do + +endstream +endobj +127 0 obj +<> +stream +x+ +T(*O4PH/VЯ07Wp +B]e +endstream +endobj +128 0 obj +<>>> /XObject <>>> +endobj +129 0 obj +<> +stream +x+ + +endstream +endobj +130 0 obj +<<>> +endobj +131 0 obj +3862 +endobj +132 0 obj +<> +stream +x\Yܶ~_0LTJٖ]v*J&~Kl"ٍ&Jbh檬J N=Ϟ<]+u.v`o;CU} U};Pg~ȮAeEz?yʢoIbȦyy髬Ǣzsq9_FJ.|YQ k9CSԵag8ȴVB,tyc1cvPUc U~!;'[-BmY]^|6'7oZ\Xf~zؽ3n\fg5MOfFw)atM# ~hMso;ٜ3m4k'?oO'_/>쳧geuYY󯈧鳺}Ze<[U E"#f +_Nlz7o(.喷MBEK,.=FCqu}[IpKdn~S`)Yn +EBB7Ȭ +wpvdR"CIO`&}H|%Q&+={?ߤjIn$!8N##1fV:3RINϻk+f+RW*KG/Wb-z~CM pO5j]66a ì 60>5oX0<$ lU}2!8ϵU*;ʣo8 p Rj]jzE& n\'jg/ :R5b-' 8oxSp^<kp“t! +^$d/b>!A**Pt0߻ +%~Aq:$(*HH$SsT#"ʥ8Br0'%~ s 1!0Hd),en7!&!=Uǃj!3 +!j422 \d&onvP`NG*8}K/&YUe cǒ&K")k/?K49p/CV|w<<-/ j +̋1T/ 3pX7?XVir(e>5rs#b:zq+xbΚE04ho7>TUa:cm%У\&R^ln@'< BGs[sasa1h2Y<덾 B ?.e"Srh(aR8v`uϹi9҃U&w΂[6CE(B-ҹtɲJ""dDǠ(9ZnVFXsbzp#4=LoP#e,Fˉ7DEHmG 2pGUoX4 jX₇tKTd Gu*ImѝYL=6s7L1jAmwzBx@5W)!Sm1jy _EO-}֨Ξr(~e^.N+Cwi>p AZC]&rĶFi:3\H6h>UU30ꛚ]?ǧj\&*{_k5*Sj[=_uьT(Om)qU-w9zAs2n +UO{;-F3'&s [2YGq{D\wsphp4>Ў̆ (R@řnСv~P컙 * !߂z C\byg d%fn8N`;!&HeW7!Ga!z`\3{H{XtDbIq#\F>3Ɍөy0 mLe^%7B ṡWd:XlMGkxRu4Do3~B* ^;-TYJD:zr# AϨtd9ـٴmV)qX\zpӥ`dpk+گߍ"s}Xc\ A1pjfdBWCw+@&qWђ4 ּ<'ж9$^5A^OhcKMAļ颲sMJ(f[,JX٧b:AogñJA Jv&,ED ء\,TH;h3c@tTet߶b/緶r3r (RZQFXvۺQf|^'U]9dh9` *#ql ;؊!1a˻X8D {+1 J|CiZ c&/Ca q:NS2F^8넏C7#@P",2*MrRGOp[k@^$/?yt`\h +i5?#j rMfUQ~a]/gUxr7m3LhznkІ5MIU!'X8? ?pRTBd/~ŕ k^aUvB$$h%QNMo;vM"@5 3kiQR="zNSҲV=- %UksbkxZAG)+?kќx.< [7>@ +KQtcx~)x+mdΘt'[<^x9_ 'VVY'PE}HW`'Þ甛 9_d./Ή5xBq3aDS9GXZlDǽI>xQ:y:QY}^; TM*֬W{sp;{w~HyU53?8PT.̻ʧ0wLXHJ% +0o$T(֋7!p +_E"yMsah% >HcQf&ul|}9v"N1TH6/(4ʛMhB*,_t7}-dA2̈́㛢Ac%CXB:PM6 ĪRÿgZE=Muʱ [_s=]7Z%e?פZ~X K((G iփAI|B۠ih[rOC$iG +n(ى?ZͮJqƿ)&Fn6G?m1~nQmmG96&P,WE[0uPG jұu|[~kۑMƯޣ _4/!T]cN(}c3}\=j5bh5K}W4A51Oc)w}7H:oUO|a@ьB@/CZ$+bXFg_nS +endstream +endobj +133 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +134 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x61 Do + +endstream +endobj +135 0 obj +<> /Length + 119 0 R /Resources 136 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ03Up +B]b +endstream +endobj +136 0 obj +<>>> /XObject <>>> +endobj +137 0 obj +<> /Length + 29 0 R /Resources 138 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +138 0 obj +<<>> +endobj +139 0 obj +4117 +endobj +140 0 obj +<> +stream +xio +"_J^/0+8A-DZUw9\J+h,vɹ}ʤVT_/Kn}I%MSm_5 ]'|u:Du2o6ifOFw{6LX>:En"Xo}U5?.$v|# +**W8+m J/ ~y$:(JX?:F/Yu^*UWert%UyTLHs٥I2g2]dEz?ezV*]oN6+4.+Ozbn`ʙt|OIok{fYMMG.Ñ2yV:ӫ'ozq?J?dU^ݫ@siXU~Jm (7$v τlMO8sd$@Jߚk,Ȫ"Όh15yÆG"9s9:\pW0)o2Jx7Y/4+:HQ`fe;06)<.P?ql3VഋLv-sWȑ 21` ikMOΆAu, z `34G^$[Jͺo{KV-9bԬR qZNU fCЮ>J[=L̗K_RM!GŽ7ZN&W؉@J +^!VF~0pD/߄U ~Yo8ƐIؽC&ZKuB'q*4r㾘w9e(2xc ` Bi++~@@L(öZx]2ب 0\׀DKgg<%h xݟJt]j{݃pfk6m/<31ۋ@nQާ?|$Ϟ%O_>]gӢhW}jگnVyFX hN*e pK1QEZuSdW#E͹;v"bȌKo!5}ŸyuM?%05qsMdX+Sz- mXp{+IBOhZE>-o@n:ۣ|s{}"-~U6E/BB\ʓU*G?wrYvY`c,*oc_$\dmT8R.2c{w IQ$ɗs->Lq֚ʪo8ߜ6+A0 J*l~~\}IȤ瀹0 U6ͳ!KLvC͘?N W wj,qjBkZM|:.,rA)D.P/z1mu$I8_uŌCػ#\41XWWVڏh%"3w!^R#\|} + ܣGtVp`o]Zb P2P,pzy =}Qx` +@XN8;ă]@ǮA\rNK&`Y:F4i@J2EH +BaYm]"B BLІu`S\a^CqC{y][EsI3oOw8i] 龀A.i n>20(uyന!\QCsDKûl b >*q>'{p + Ƴ'g{O"4,vum6,uKB lUcLݜ2':` ĀA4 FiMj!Pc<[RYIuD +IQ' ep+ +>|.h*$\9:[:䠧*M"2F=b)@` +S. e'3.g)Ԃ#kI#?"QX<a>o8P#6 j4H58U6$D5/gGL`WSѣl)Jq7ozb`&P΀;{~"+BZ<r\G5©+91}!`7)|$b**xij"D%Ġ8Dlrpؙw*&O@(pF#My0B.鋙v`꺇!Aˢ(ۆ=(1!ANTH-.g,ǪՀz{;*,UpޣVhI4H,]_#| ϧŸ;&C%/+EB>./dAΨ5Kw'bztDWStYw詐h'&o`IVL)D|*n GSj>&d^*w0F" Qyavi&{H"BX`)5AtD_/@S]%Н+{bnDtlSj5;jAJpN#kjQb d`T #I2atc5!aPU,%8^3_A=YbY3he=$Ya6kF/&S$v,:F}j+؄#Z=>8TUQZOk4Vzz(TES]zzҸ#>fY? cR-K3BL̉=;s*lzv!(K*xkb3BƸԵC{jGum:zE^˾\;2"Ew;l~?3r'1h66/ 0t= +ZlRsA1v2`.gmKݳjU}QU5Y[GٓmϪU!z)B|8U-^dUofALɗ6bple'ED1Py?Z +endstream +endobj +141 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +142 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x49 Do + +endstream +endobj +143 0 obj +<> /Length + 119 0 R /Resources 144 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ05Vp +B]d_ +endstream +endobj +144 0 obj +<>>> /XObject <>>> +endobj +145 0 obj +<> /Length + 29 0 R /Resources 146 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +146 0 obj +<<>> +endobj +147 0 obj +4513 +endobj +148 0 obj +<> +stream +x\Ys~_,R +7JUSeGEdlg{afvRk3}~}̀UV*;>{uvϞ4]?Ξ㷯 So.놬a\v}욪{{<¿~r;t~r:4U5㶬{v:)yF׳u>m<r[5,>P-˪EM} 9Z~gdprEO.(I\*7/lw+͗\jsǿy^{><{Wo_ڼk?8C稚&VXWR>ˋټ`s"ڣ_ \rs{t.7y]ZRv|p|j:vS ۼ El^O#)rK.(lr Kƃvf4䖩9"3ymMn;IAF?lzF/;2r/7=Y_O6LB< \ȋ<:{4{ۓWeO/^]\eߛΞeϞe?zI]TK>kqgvϿr'' JoT2K+*;#y뎮 [&f懆ڀ3͉ލ.aM{eZvpN\hт%M 24BKqn5.$N^۴8RLȹ-@ ӄaXo#bjZSk ,';H嚏 նLJj=,YƆV(ͥ=7?F ]!,,")jj源NmF3yrJKy_C˯Us^yGyo͡dSś9 ++*h0pN}mCȩ߽W"p̘t*ᕈT4!8OBֲ0ԇA20`-+^-sSU% - <`u"fpɖw)jV/ +Z7𿹂gC&s)0z\̟BK]-pLu@1Jp3_af4{$`-eO$ol95Ż\MqZ˯Li&N-zuv& ECw +H0Ls\t I;w CѾ!a`yy†PAi( { +J2ƣycO)V_4ӽ ++mH#;-ء?ku@ޯm(v*'DZ3ULŽ*0Ii)iYr@O^:3 b B~xkPI4jm!Y<# YcVuglԍ9P]^tfoj9#bQW Kc4A[#S"sirV  8L'.qrۓaMȩa1glwQ|:H8 r"B9(_b(jI) bhp:V4ʦ/]مNIsM\:ާJѲwou2 r w,$8X\v+*@rsx'!2? ;;c +<e iP+81>,}1&\(c:bKtXBRklsa/pW+]}AHpVbG(l]mΙbЪjCҲ *>Ddia]IC6"%xe\I萢D1D]1p!oR` 8Z)dάfeX.}&N9גKό?'jŔ(%Tdz aE*ISw*G8fWu15OFNAq J")]o-h.obb)b"$Vɦ,M ƒxPTQL|s͓lsDxC=(G)vf!2,B-Huhk +APIZ mRT-u5!F,v&j%JgE-6mI6;!={`D"kn +8 t㘬V(v,| >}0i[#mH 9Z%"r-Hl[3G%&rC.rh_S +iixnS:O..!OJss$nεRvG&Ra$\:(2>"Zs.8TiE-Dѭ@;Y 宂NT1U;tm5@v +SPbXe\.{`1P1n5η/ %.Ef) Dس*y>V7e<6\֊2?0|ʂ%0AgqZԘ +ӧC4kM;b1RJ~t%}+lQlS"_JX.WS_ +ɻGn2?+w6y~jEҢ<߁Eto{d _Ukh +I+Mqa}M%C_iR3<5Q- * ?ȐQ.hbQ ++ +&$K";dªG:Թ]LƄ wVwL`Ÿ+(|uosp_6 ا4+n˲`" +?ZUd\ہWsgQ  F{b=e+2f,0V-U.E@eyd,0~J"KUwP1+$BpSSAyl+_y8J&=@\x{#B[.z/[~o4Iތ-N%) ½1٭{*vƞZ J$Jb2o?` +endstream +endobj +149 0 obj +<>>> /Font + <> + /Pattern <>>> +endobj +150 0 obj +<> +endobj +151 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x37 Do + +endstream +endobj +152 0 obj +<> /Length + 119 0 R /Resources 153 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ01Tp +B]H\ +endstream +endobj +153 0 obj +<>>> /XObject <>>> +endobj +154 0 obj +<> /Length + 29 0 R /Resources 155 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +155 0 obj +<<>> +endobj +156 0 obj +<> + /FontDescriptor 159 0 R /Subtype /CIDFontType2 /Type /Font /W + [0 [600 593]]>> +endobj +157 0 obj +<> +stream +x] >C19%vfFǬЌ21 -;"oz֑a\aɑ0Nǽ+U2öD{^-[>(@~Av4~a 3RJt鹋 +W5#ztSގ- 47M(*UM $Oߩ_]gX5Ž3? +W攧lkYLSp +endstream +endobj +158 0 obj +223 +endobj +159 0 obj +<> +endobj +160 0 obj +<> +stream +xc`d```cp``bPHϩLS=)[9]| # W-`YONL@'7Aq #tXPQPUQP1qN3kf̔35=13HPMYI (n̮ W64ˌfKM4r+a`UPQb e1T7. ʬBE<4}n->c~nY uQ++ƉJ$#S^fb`X,+3 e>4}_\oY$؀T,:00pU{-T"@xAM  fV +endstream +endobj +161 0 obj +406 +endobj +162 0 obj +4151 +endobj +163 0 obj +<> +stream +xZQs6~ǯۑ ItfN.^IsNNyr0^Ɋ~J>0]R'JT-󪪒~ѵmH߇/W:iyQw.LeenJɭ쟯F s(AEJhV_i[O碰ŜŹPԹ%4*k`~NV3>[/Ig3!LsV7+5oERcHoEtdLnӥ{TB)Eet٬C&@*ol_R7ì(_'|#B^N ! $̭pqnjscF5\yziK&2kŠheybl_6Ф ]vH, A O~?_'7&9]-W+,yKBQ8O$?3+=z8MХ L Èd MɒQo2|kvc @WaTA7oʼЦ}8"AџIwh﬌߰5 ],}9Toyvtfi텢sXW0U3LjD4e '7e0QG6p+K\H/' :-cT:UuZ8nB7>35H*AB]:8[ BK TK T"@fbTYI+ N.ɟp}w ZxÏl;\?6Ddra TlHW; "Jxla;+j0g6߷XvJ.̅,rUBUycEn؅!g,m"6XXNʮ\;0tL4'+E{o1cT"zOMGpɩVΩ.(A4]R)"Kmd(+{(FXt +\CdҲdmE| >+r +`ynUcFL6}NkBHnzS^Z`!-{ Y͜DqTCzJMK w)bym=] 4D})عP;Tǥ w$3SOHG&IqHT<H5W%#2R=1[Te 覲RyQpŀU\S-6qI.PϹeQH]HǑ,z~Tt_`O7vHjQLcz@Av$ϵ4nz `s%9ʊ S.c6ߑ؞߶,t Bt*˼h/ P.cn89sjwO1p*वHgUB4A)򪨔(Z^e +J,hӡFc{YwƯt䮋FNp5 ė", +endstream +endobj +164 0 obj +<>>> /Font + <> /Pattern + <>>> +endobj +165 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x24 Do + +endstream +endobj +166 0 obj +<> +stream +x+ +T(*O4PH/VЯ0Pp +B]sa +endstream +endobj +167 0 obj +<>>> /XObject <>>> +endobj +168 0 obj +<> +stream +x+ + +endstream +endobj +169 0 obj +<<>> +endobj +170 0 obj +2322 +endobj +171 0 obj +<> +stream +xrܸ_ڧaCrצ{=}XAnj${tX3M*S$Fh@:gі:9T_ԗvJN6MlN<9(^u]&+^OLTMR&k&j 5R:۳i0= <:8qEcJ͖AMTREj4d^]2dC[45BF! x"N- :&fH ImLx to" 0gkṰ-TDe;½p%y'M^< tO>p8Tvgۤm紮FnqB24%Q/1 ->VZ@tWƌ~Ei _W"oBL +D_ |@|%Ods3^&Њ̀bÏЄs+ra}4ovTrݍ/|9sYb(WšKFJwE-ɂ: A 7T.({]2DI?%未%q1"7wh.Ÿ=1M̭8Ddwx9LsCPS}! l, CwAonfU +8._' {]!I U/S6e(PK$aQbKxjDCAi~\5FkT.)n$Tw%kQuk{9x5FBRJ +ɣ͈G؅?0 r\&> lƦl҈ߊ.S`tڻxdJw䙆uʪFQ'($NDŚVT'8BܿJlI@wbT$xOLOn\p-,i[Z֣h )_ 茯x\Vrw\<'K8\ur!J>VhqF阴뜟Ai<=cN@&P|5r4ih=US۴F Ua6ǵ8@MC8m<aO~T K7nnȟРm0~;:B4:GқEo4o4^,vT6Y]і.۲oνlun^mPjMOp6rȁ{N[$GXt`h_:y@4<8I\sCAɺRs&WDpU8i5ESW5EƥRL [ET[@hdžSĨ +endstream +endobj +172 0 obj +<>>> /Font + <> + /Pattern <>>> +endobj +173 0 obj +<>>> + /TilingType 1 /XStep 1588 /YStep 2246>> +stream + /x12 Do + +endstream +endobj +174 0 obj +<> /Length + 119 0 R /Resources 175 0 R /Subtype /Form /Type /XObject>> +stream +x+ +T(*O4PH/VЯ04Sp +B]W^ +endstream +endobj +175 0 obj +<>>> /XObject <>>> +endobj +176 0 obj +<> /Length + 29 0 R /Resources 177 0 R /Subtype /Form /Type /XObject>> +stream +x+ + +endstream +endobj +177 0 obj +<<>> +endobj +178 0 obj +3326 +endobj +179 0 obj +<> + /Count 1 /Next 198 0 R /Parent 3 0 R /Title (Abstract)>> +endobj +180 0 obj +<> + /Count 1 /Parent 3 0 R /Prev 181 0 R /Title (Author's Address)>> +endobj +181 0 obj +<> + /Count 3 /First 182 0 R /Last 183 0 R /Next 180 0 R /Parent 3 0 R + /Prev 184 0 R /Title (9. References)>> +endobj +182 0 obj +<> + /Count 1 /Next 183 0 R /Parent 181 0 R /Title + (9.1. Normative References)>> +endobj +183 0 obj +<> + /Count 1 /Parent 181 0 R /Prev 182 0 R /Title + (9.2. Informative References)>> +endobj +184 0 obj +<> + /Count 1 /Next 181 0 R /Parent 3 0 R /Prev 185 0 R /Title + (8. Acknowledgements)>> +endobj +185 0 obj +<> + /Count 1 /Next 184 0 R /Parent 3 0 R /Prev 186 0 R /Title + (7. Security Considerations)>> +endobj +186 0 obj +<> + /Count 1 /Next 185 0 R /Parent 3 0 R /Prev 187 0 R /Title + (6. IANA Considerations)>> +endobj +187 0 obj +<> + /Count 3 /First 188 0 R /Last 189 0 R /Next 186 0 R /Parent 3 0 R + /Prev 190 0 R /Title (5. Mapping to CCNx and NDN packet encodings)>> +endobj +188 0 obj +<> + /Count 1 /Next 189 0 R /Parent 187 0 R /Title + (5.1. Packet encoding for CCNx)>> +endobj +189 0 obj +<> + /Count 1 /Parent 187 0 R /Prev 188 0 R /Title + (5.2. Packet encoding for NDN)>> +endobj +190 0 obj +<> + /Count 1 /Next 187 0 R /Parent 3 0 R /Prev 191 0 R /Title + (4. Dealing with malicious actors)>> +endobj +191 0 obj +<> + /Count 6 /First 192 0 R /Last 193 0 R /Next 190 0 R /Parent 3 0 R + /Prev 194 0 R /Title + (3. Method to enhance congestion control with signaled size information in Interest Messages)>> +endobj +192 0 obj +<> + /Count 1 /Next 201 0 R /Parent 191 0 R /Title + (3.1. How to predict the size of returning Data messages)>> +endobj +193 0 obj +<> + /Count 1 /Parent 191 0 R /Prev 199 0 R /Title + (3.5. Operation when some Interests lack the expected data size option and some have it)>> +endobj +194 0 obj +<> + /Count 1 /Next 191 0 R /Parent 3 0 R /Prev 195 0 R /Title + (2. Requirements Language)>> +endobj +195 0 obj +<> + /Count 1 /Next 194 0 R /Parent 3 0 R /Prev 196 0 R /Title + (1. Introduction)>> +endobj +196 0 obj +<> + /Count 1 /Next 195 0 R /Parent 3 0 R /Prev 197 0 R /Title + (Table of Contents)>> +endobj +197 0 obj +<> + /Count 1 /Next 196 0 R /Parent 3 0 R /Prev 198 0 R /Title + (Copyright Notice)>> +endobj +198 0 obj +<> + /Count 1 /Next 197 0 R /Parent 3 0 R /Prev 179 0 R /Title + (Status of This Memo)>> +endobj +199 0 obj +<> + /Count 1 /Next 193 0 R /Parent 191 0 R /Prev 200 0 R /Title + (3.4. Interactions with Interest Aggregation)>> +endobj +200 0 obj +<> + /Count 1 /Next 199 0 R /Parent 191 0 R /Prev 201 0 R /Title + (3.3. Handling 'too small' cases)>> +endobj +201 0 obj +<> + /Count 1 /Next 200 0 R /Parent 191 0 R /Prev 192 0 R /Title + (3.2. Handling 'too big' cases)>> +endobj +xref +0 202 +0000000000 65535 f +0000000015 00000 n +0000001593 00000 n +0000001707 00000 n +0000001931 00000 n +0000002073 00000 n +0000002902 00000 n +0000011089 00000 n +0000012496 00000 n +0000016256 00000 n +0000017858 00000 n +0000019273 00000 n +0000020093 00000 n +0000021311 00000 n +0000022129 00000 n +0000025107 00000 n +0000029527 00000 n +0000034412 00000 n +0000035937 00000 n +0000038024 00000 n +0000038161 00000 n +0000038666 00000 n +0000039272 00000 n +0000039424 00000 n +0000039652 00000 n +0000039671 00000 n +0000039851 00000 n +0000039870 00000 n +0000039951 00000 n +0000040108 00000 n +0000040127 00000 n +0000040148 00000 n +0000040374 00000 n +0000040693 00000 n +0000040713 00000 n +0000040959 00000 n +0000041601 00000 n +0000041621 00000 n +0000041868 00000 n +0000042522 00000 n +0000042542 00000 n +0000048539 00000 n +0000048560 00000 n +0000048804 00000 n +0000049372 00000 n +0000049392 00000 n +0000054383 00000 n +0000054404 00000 n +0000054425 00000 n +0000058765 00000 n +0000058916 00000 n +0000059065 00000 n +0000059293 00000 n +0000059539 00000 n +0000059620 00000 n +0000059843 00000 n +0000059864 00000 n +0000060074 00000 n +0000060376 00000 n +0000060396 00000 n +0000060639 00000 n +0000061157 00000 n +0000061177 00000 n +0000061198 00000 n +0000064645 00000 n +0000064826 00000 n +0000065298 00000 n +0000065750 00000 n +0000065978 00000 n +0000066158 00000 n +0000066239 00000 n +0000066396 00000 n +0000066417 00000 n +0000066651 00000 n +0000067105 00000 n +0000067125 00000 n +0000074385 00000 n +0000074406 00000 n +0000074652 00000 n +0000075153 00000 n +0000075173 00000 n +0000079477 00000 n +0000079498 00000 n +0000079519 00000 n +0000083400 00000 n +0000083551 00000 n +0000083779 00000 n +0000084025 00000 n +0000084106 00000 n +0000084329 00000 n +0000084350 00000 n +0000084371 00000 n +0000088258 00000 n +0000088409 00000 n +0000088552 00000 n +0000088780 00000 n +0000088960 00000 n +0000089041 00000 n +0000089198 00000 n +0000089219 00000 n +0000089420 00000 n +0000089721 00000 n +0000089742 00000 n +0000089977 00000 n +0000091831 00000 n +0000091853 00000 n +0000091875 00000 n +0000095572 00000 n +0000095710 00000 n +0000095939 00000 n +0000095959 00000 n +0000096207 00000 n +0000096290 00000 n +0000096515 00000 n +0000096537 00000 n +0000096559 00000 n +0000100273 00000 n +0000100411 00000 n +0000100640 00000 n +0000100888 00000 n +0000100908 00000 n +0000100990 00000 n +0000101215 00000 n +0000101237 00000 n +0000101259 00000 n +0000105197 00000 n +0000105335 00000 n +0000105564 00000 n +0000105746 00000 n +0000105828 00000 n +0000105987 00000 n +0000106009 00000 n +0000106031 00000 n +0000110224 00000 n +0000110376 00000 n +0000110605 00000 n +0000110853 00000 n +0000110935 00000 n +0000111160 00000 n +0000111182 00000 n +0000111204 00000 n +0000115793 00000 n +0000115945 00000 n +0000116174 00000 n +0000116422 00000 n +0000116504 00000 n +0000116729 00000 n +0000116751 00000 n +0000116773 00000 n +0000121000 00000 n +0000121167 00000 n +0000121321 00000 n +0000121550 00000 n +0000121798 00000 n +0000121880 00000 n +0000122105 00000 n +0000122127 00000 n +0000122337 00000 n +0000122636 00000 n +0000122657 00000 n +0000122904 00000 n +0000123399 00000 n +0000123420 00000 n +0000123442 00000 n +0000125840 00000 n +0000125978 00000 n +0000126207 00000 n +0000126389 00000 n +0000126471 00000 n +0000126630 00000 n +0000126652 00000 n +0000126674 00000 n +0000130076 00000 n +0000130241 00000 n +0000130470 00000 n +0000130718 00000 n +0000130800 00000 n +0000131025 00000 n +0000131047 00000 n +0000131069 00000 n +0000131224 00000 n +0000131388 00000 n +0000131594 00000 n +0000131771 00000 n +0000131950 00000 n +0000132133 00000 n +0000132323 00000 n +0000132508 00000 n +0000132744 00000 n +0000132925 00000 n +0000133105 00000 n +0000133300 00000 n +0000133585 00000 n +0000133790 00000 n +0000134028 00000 n +0000134214 00000 n +0000134391 00000 n +0000134570 00000 n +0000134748 00000 n +0000134930 00000 n +0000135138 00000 n +0000135335 00000 n +trailer + +<> +startxref +135530 +%%EOF diff --git a/draft-oran-icnrg-flowbalance-06.txt b/draft-oran-icnrg-flowbalance-06.txt new file mode 100644 index 0000000..7246d0c --- /dev/null +++ b/draft-oran-icnrg-flowbalance-06.txt @@ -0,0 +1,896 @@ + + + + +ICNRG D. Oran +Internet-Draft Network Systems Research and Design +Intended status: Experimental 25 October 2021 +Expires: 28 April 2022 + + + Maintaining CCNx or NDN flow balance with highly variable data object + sizes + draft-oran-icnrg-flowbalance-06 + +Abstract + + Deeply embedded in some ICN architectures, especially Named Data + Networking (NDN) and Content-Centric Networking (CCNx) is the notion + of flow balance. This captures the idea that there is a one-to-one + correspondence between requests for data, carried in Interest + messages, and the responses with the requested data object, carried + in Data messages. This has a number of highly beneficial properties + for flow and congestion control in networks, as well as some + desirable security properties. For example, neither legitimate users + nor attackers are able to inject large amounts of un-requested data + into the network. + + Existing congestion control approaches however have a difficult time + dealing effectively with a widely varying MTU of ICN data messages, + because the protocols allow a dynamic range of 1-64K bytes. Since + Interest messages are used to allocate the reverse link bandwidth for + returning Data, there is large uncertainty in how to allocate that + bandwidth. Unfortunately, most current congestion control schemes in + CCNx and NDN only count Interest messages and have no idea how much + data is involved that could congest the inverse link. This document + proposes a method to maintain flow balance by accommodating the wide + dynamic range in Data message size. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + +Oran Expires 28 April 2022 [Page 1] + +Internet-Draft Maintaining Flow Balance October 2021 + + + This Internet-Draft will expire on 28 April 2022. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 + 3. Method to enhance congestion control with signaled size + information in Interest Messages . . . . . . . . . . . . 5 + 3.1. How to predict the size of returning Data messages . . . 6 + 3.2. Handling 'too big' cases . . . . . . . . . . . . . . . . 7 + 3.3. Handling 'too small' cases . . . . . . . . . . . . . . . 8 + 3.4. Interactions with Interest Aggregation . . . . . . . . . 9 + 3.5. Operation when some Interests lack the expected data size + option and some have it . . . . . . . . . . . . . . . . . 10 + 4. Dealing with malicious actors . . . . . . . . . . . . . . . . 12 + 5. Mapping to CCNx and NDN packet encodings . . . . . . . . . . 13 + 5.1. Packet encoding for CCNx . . . . . . . . . . . . . . . . 13 + 5.2. Packet encoding for NDN . . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + +Oran Expires 28 April 2022 [Page 2] + +Internet-Draft Maintaining Flow Balance October 2021 + + +1. Introduction + + Deeply embedded in some ICN architectures, especially Named Data + Networking ([NDN]) and Content-Centric Networking (CCNx + [RFC8569],[RFC8609]) is the notion of _flow balance_. This captures + the idea that there is a one-to-one correspondence between requests + for data, carried in Interest messages, and the responses with the + requested data object, carried in Data messages. This has a number + of highly beneficial properties for flow and congestion control in + networks, as well as some desirable security properties. For + example, neither legitimate users nor attackers are able to inject + large amounts of un-requested data into the network. + + This approach leads to a desire to make the size of the objects + carried in Data messages small and near constant, because flow + balance can then be kept using simple bookkeeping of how many + Interest messages are outstanding. While simple, constraining Data + messages to be quite small - usually on the order of a link Maximum + Transmission Unit (MTU) - has some constraints and deleterious + effects, among which are: + + * Such small data objects are inconvenient for many applications; + their natural data object sizes can be considerably larger than a + link MTU. + + * Applications with truly small data objects (e.g. voice packets in + an Internet telephony applications) have no way to communicate + that to the network, causing resources to still be allocated for + MTU-sized data objects + + * When chunking a larger data object into multiple Data messages, + each message has to be individually cryptographically hashed and + signed, increasing both computational overhead and overall message + header size. The signature can be elided when Manifests are used + (by signing the Manifest instead), but the overhead of hashing + multiple small messages rather than fewer larger ones remains. + + + + + + + + + + + + + + + +Oran Expires 28 April 2022 [Page 3] + +Internet-Draft Maintaining Flow Balance October 2021 + + + One approach which helps with the last of these is to employ + fragmentation for Data messages larger than the Path MTU (PMTU). + Such messages are carved into smaller pieces for transmission over + the link(s). There are three flavors of fragmentation: end-to-end, + hop-by-hop with reassembly at every hop, and hop-by-hop with cut- + through of individual fragments. A number of ICN protocol + architectures incorporate fragmentation and schemes have been + proposed for both NDN and CCNx, for example in [Ghali2013]. + Fragmentation alone does not ameliorate the flow balance problem + however, since from a resource allocation standpoint both memory and + link bandwidth must be set aside for maximum-sized data objects to + avoid congestion collapse under overload. + + The design space considered in this document does not however extend + to arbitrarily large objects (e.g. 100's of kilobytes or larger). As + the dynamic range of data object sizes gets very large, finding the + right tradeoff between handling a large number of small data objects + versus a single very large data object when allocating link and + buffer resources becomes intractable. Further, the semantics of + Interest-Data exchanges means that any error in the exchange results + in a re-issue of an Interest for the entire Data object. Very large + data objects represent a performance problem because the cost of + retransmission when Interests are retransmitted (or re-issued) + becomes unsustainably high. Therefore, the method we propose deals + with a dynamic range of object sizes from very small (a fraction of a + link MTU) to moderately large - about 64 kilobytes or equivalently + about 40 Ethernet packets, and assumes an associated fragmentation + scheme to handle link MTUs that cannot carry the Data message in a + single link-layer packet. + + The approach described in the rest of this document maintains flow + balance under the conditions outlined above by allocating resources + accurately based on expected Data message size, rather than employing + simple interest counting. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + + + + + + +Oran Expires 28 April 2022 [Page 4] + +Internet-Draft Maintaining Flow Balance October 2021 + + +3. Method to enhance congestion control with signaled size information + in Interest Messages + + Before diving into the specifics of the design, it is useful to + consider how congestion control works in NDN/CCNx. Unlike the IP + protocol family, which relies on end-to-end congestion control (e.g. + TCP[RFC0793], DCCP[RFC4340], SCTP[RFC4960], + QUIC[I-D.ietf-quic-transport]), CCNx and NDN employ hop-by-hop + congestion control. There is per-Interest/Data state at every hop of + the path and therefore for each outstanding Interest, bandwidth for + data returning on the inverse path can be allocated. In many current + designs, this allocation is done using simple Interest counting - by + queueing and subsequently forwarding one Interest message from a + downstream node, implicitly this provides a guarantee (either hard or + soft) that there is sufficient bandwidth on the inverse direction of + the link to send back one Data message. A number of congestion + control schemes have been developed that operate in this fashion, for + example [Wang2013],[Mahdian2016],[Song2018],[Carofiglio2012]. Other + schemes, like [Schneider2016] neither count nor police interests, but + instead monitor queues using AQM (active queue management) to mark or + drop returning Data packets that have experienced congestion. It is + worth noting that every congestion control algorithm has an explicit + fairness goal and associated objective function (usually either + [minmaxfairness] or [proportionalfairness]). If your fairness is to + be based on resource usage, pure interest counting doesn't do the + trick, since a consumer asking for large thing can saturate a link + and shift loss to consumers asking for small things. + + In order to deal with a larger dynamic range of Data message size, + some means is required to allocate link bandwidth for Data messages + in bytes with an upper bound larger than a Path MTU and a lower bound + lower than a single link MTU. Since resources are allocated for + returning Data based on arriving Interests, this information must be + available in Interest messages. + + Therefore, one key idea is the inclusion of an _expected data size_ + TLV in each Interest message. This allows each forwarder on the path + taken by the Interest to more accurately allocate bandwidth on the + inverse path for the returning Data message. Also, by including the + expected data size, large objects will have a corresponding weight in + resource allocation, maintaining link and forwarder buffering + fairness. The simpler Interest counting scheme was nominally "fair" + on a per-exchange basis within the variations of data that fit in a + single PMTU packet because all Interests produced similar amounts of + data in return. In the absence of such a field, it is not feasible + to allow a large dynamic range in object size. While schemes like + [Schneider2016] would not employ the expected data size to allocate + reverse link bandwidth, they can still benefit from the information + + + +Oran Expires 28 April 2022 [Page 5] + +Internet-Draft Maintaining Flow Balance October 2021 + + + to affect the AQM congestion marking algorithm, preferentially + marking data packets that exceed the expected data size from the + corresponding Interest. + + It is natural to ask whether the additional complexity introduced + into an ICN forwarder, and the additional computational cost for the + congestion control operations is worthwhile. For congestion control + schemes like [Schneider2016] the additional overhead is not trivial, + since no Interest counting is happening. However, if a congestion + control is _already_ counting Interests, the additional overhead is + minimal, only reading one extra TLV from the Interest and + incrementing the outstanding data amount for the corresponding queue + by that number rather than a constant of 1. The overhead on + returning data is simply reducing the amount by the actual Data + message size, rather than by 1. + +3.1. How to predict the size of returning Data messages + + This of course raises the question "How does the requester know how + big the corresponding Data message coming back will be?". For a + number of important applications, the size is known a priori due to + the characteristics of the application. Here are some examples: + + * For many sensor and other Internet-of-Things applications, the + data is instrument readings which have fixed known size. + + * In video streaming, the data is output of a video encoder which + produces variable sized frames. This information is typically + made available ahead of time to the streaming clients in the form + of a _Manifest_ (e.g [DASH], FLIC [I-D.irtf-icnrg-flic]), which + contains the names of the corresponding segments (or individual + frames) of video and audio and their sizes. + + * Internet telephony applications use vocoders that typically employ + fixed-size audio frames. Therefore, their size is known either a + priori, or via an initialization exchange at the start of an audio + session. + + The more complex cases arise where the data size is not known at the + time the Interest must be sent. Much of the nuance of the proposed + scheme is in how mismatches between the expected data size and the + actual Data message returned are handled. The consumer can either + under- or over-estimate the data size. In the former case, the + under-estimate can lead to congestion and possible loss of data. In + the latter case, bandwidth that could have been used by data objects + requested by other consumers might be wasted. We first consider + "honest" mis-estimates due to imperfect knowledge by the ICN + application; later we consider malicious applications that are using + + + +Oran Expires 28 April 2022 [Page 6] + +Internet-Draft Maintaining Flow Balance October 2021 + + + the machinery to mount some form of attack. We also consider the + effects of Interest aggregation if the aggregated Interests have + differing expected data sizes. Also, it should be obvious that if + the Data message arrives, the application learns its actual size, + which may or may not be useful in adjusting the expected data size + estimate for future Interests. + + In all cases, the expected data size from the Interest can be + incorporated in the corresponding Pending Interest Table (PIT) entry + of each CCNx/NDN forwarder on the path and hence when a (possibly + fragmented) Data object comes back, its total size is known and can + be compared to the expected size in the PIT for a mismatch. Aside: + In the case of fragmentation, we assume a fragmentation scheme in + which the total Data message size can be known as soon as any one + fragment is received (a reasonable assumption for most any well- + designed fragmentation method, such as that in [Ghali2013]). + +3.2. Handling 'too big' cases + + If the returning Data message is larger than the expected data size, + the extra data could result in either unfair bandwidth allocation or + possibly data loss under congestion conditions. When this is + detected, the forwarder has three choices: + + 1. It could forward the Data message anyway, which is safe under + non-congestion conditions, but unfair and possibly unstable when + the output link is congested + + 2. It could forward the data when un-congested (e.g. by assessing + output queue depth) but drop it when congested + + 3. It could always drop the data, as a way of "punishing" the + requester for the mis-estimate. + + Either of the latter two strategies is acceptable from a congestion + control point of view. However, it is not a good idea to simply drop + the Data message with no feedback to the issuer of the Interest + because the application has no way to learn the actual data size and + retry. Further, recovery would be delayed until the failing Interest + timed out. Therefore, an additional element needed in protocol + semantics is the incorporation of a "Data too big" error message + (achieved via the use of an "Interest Return" packet in CCNx). + + Upon dropping data as above, the CCNx/NDN forwarder converts the + normal Data message into an Interest Return packet containing the + existing [RFC8609] T_MTU_TOO_LARGE error code and the actual size of + the Data message instead of the original content. It propagates that + back toward the client identically to how the original Data message + + + +Oran Expires 28 April 2022 [Page 7] + +Internet-Draft Maintaining Flow Balance October 2021 + + + would have been handled. Subsequent nodes upon receiving the + T_MTU_TOO_LARGE error treat identically to other Interest Return + errors. When the Interest Return eventually arrives back to the + issuer of the Interest, the user MAY reissue the Interest with the + correct expected data size. + + One detail to note is that an Interest Return carrying + T_MTU_TOO_LARGE must be deterministically smaller than the expected + data size in all cases. This is clearly the case for large data + objects, but there is a corner case with small data objects. There + has to be a minimum expected data size that a client can specify in + their Interests, and that minimum cannot be smaller than the size of + a T_MTU_TOO_LARGE Interest Return packet. + +3.3. Handling 'too small' cases + + Next we consider the case where the returning data is smaller than + the expected data size. While this case does not result in + congestion, it can cause resources to be inefficiently allocated + because not all of the set-aside bandwidth for the returning data + object gets used. The simplest and most straightforward way to deal + with this case is to essentially ignore it. The motivation for not + worrying about the smaller data mismatch is that in many situations + that employ usage-based resource measurement (and possibly charging), + it is trivial to just account for the usage according to the larger + expected data size rather than actual returned data size. Properly + adjusting congestion control parameters to somehow penalize users for + over-estimating their resource usage requires fairly heavyweight + machinery, which in most cases is not warranted. If desired, any of + the following mechanisms could be considered: + + * Attempt to identify future Interests for the same object or + closely related objects and allocate resources based on some + retained state about the actual size of prior objects + + * Police consumer behavior and decrease the expected data size in + one or more future Interests to compensate + + * For small objects, do more optimistic resource allocation on the + links on the presumption that there will be some "slack" due to + clients overestimating data object size. + + + + + + + + + + +Oran Expires 28 April 2022 [Page 8] + +Internet-Draft Maintaining Flow Balance October 2021 + + +3.4. Interactions with Interest Aggregation + + One protocol detail of CCNx/NDN that needs to be dealt with is + Interest Aggregation. Interest Aggregation, while a powerful feature + for maintaining flow balance when multiple consumers send Interests + for the same Named object, introduces subtle complications. Whenever + a second or subsequent Interest arrives at a forwarder with an active + PIT entry it is possible that those Interests carry different + parameters, for example hop limit, payload, etc. It is therefore + necessary to specify the exact behavior of the forwarder for each of + the parameters that might differ. In the case of the expected data + size parameter defined here, the value is associated with the ingress + face on which the Interest creating the PIT entry arrived, as opposed + to being global to the PIT entry as a whole. Interest aggregation + interacts with expected data size if Interests from different clients + contain different values of the expected data size. As above in + Section 3.3, the simplest solution to this problem is to ignore it, + as most error cases are benign. However, there is one problematic + error case where one client provides an accurate expected data size, + but another who issued the Interest first underestimates, causing + both to receive a T_MTU_TOO_LARGE error. This introduces a denial of + service vulnerability, which we discuss below together with the other + malicious actor cases. + + There are two cases to consider: + + 1. The arriving Interest carries an expected data size smaller than + any of the values associated with the PIT entry. + + 2. The arriving Interest carries an expected data size larger than + any of the values associated with the PIT entry. + + For Case (1) the Interest can be safely aggregated since the upstream + links will have sufficient bandwidth allocated based on the larger + expected data size (assuming the original Interest's expected data + size was itself sufficiently large to accommodate the actual size of + the returning Data). On the other hand, should the incoming face + have bandwidth allocated based on the larger existing Interest's + expected data size, or on the smaller value in the arriving interest? + Here there are two possible approaches: + + a. Allocate based on the data size already in the PIT. In this case + the consumer sending the earlier Interest can cause over- + allocation of link bandwidth for other incoming faces, but there + will not be a T_MTU_TOO_LARGE error generated for that Interest + + + + + + +Oran Expires 28 April 2022 [Page 9] + +Internet-Draft Maintaining Flow Balance October 2021 + + + b. Allocate based on the value in the arriving Interest. If the + returning Data is in fact larger, generate a T_MTU_TOO_LARGE + Interest Return on that ingress face, while successfully + returning the Data message on any faces that do not exhibit a too + small expected data size + + It is RECOMMENDED that the second policy be followed. The reasons + behind this recommendation are as follows: + + 1. The link can be congested quite quickly after the queuing + decision is made, especially if the data has a long link- + occupancy time, so this is a safer alternative. + + 2. The cost of returning the error is only one link RTT, since the + consumer (or downstream forwarder) can immediately re-issue the + Interest with the correct size and perhaps pick up the cached + object from the upstream forwarder's Content Store. + + 3. Being optimistic and returning the data interacts with the + behavior of aggregate resource control and resource accounting, + which in turn raises the messy issue of whether to "charge" the + consumer for the actual bandwidth used or only for the requested + bandwidth in the expected data. + + 4. The rabbit hole goes deeper if you add differential QoS to the + equation or consumers "playing games" and intentionally + underestimating so their interests get satisfied when links + aren't congested. This makes handling malicious actors + (Section 4) more difficult. + + For Case (2) above, the Interest MUST be forwarded rather than + aggregated to prevent a consumer from mounting a denial of service + attack by sending intentionally too small expected data size (see + Section 4 for additional detail on this and other attacks). As above + for Case (1) it is RECOMMENDED that policy (b) above be followed. + +3.5. Operation when some Interests lack the expected data size option + and some have it + + Since the expected data size is an optional hop-by-hop packet field, + forwarders need to be prepared to handle an arbitrary mix of packets + containing or lacking this option. There are two general things to + address. + + First, we assume that any forwarder supporting expected data size is + running a more sophisticated congestion control algorithm that one + employing simple interest counting. The link bandwidth resource + allocation is therefore based directly, or indirectly, on the + + + +Oran Expires 28 April 2022 [Page 10] + +Internet-Draft Maintaining Flow Balance October 2021 + + + expected Data size in bytes. Therefore, the forwarder has to assign + a value to use in the resource allocation for the reverse link. This + specification does not mandate any particular approach or a default + value to use. However, in the absence on other guidance, it makes + sense to do one of two things: + + 1. Pick a default based on the link MTU of the face on which the + Interest arrived and use that for all Interests lacking an + expected data size. This is likely to be most compatible with + simple interest counting which would rate limit all incoming + interests equally. + + 2. Configure some values for given Name prefixes that have known + sizes. This may be appropriate for dedicated forwarders + supporting single use cases, such as: + + * A forwarder handling IoT sensors sending very small Data + messages + + * A forwarder handling real-time video with large average Data + packets that exceed link MTU and are routinely fragmented + + * A forwarder doing voice trunking where the vocoders produce + moderate sized packets, still much smaller than the link MTU + + The second area to address is what to do if an interest lacking an + expected Data size is responded to by a Data message whose size + exceeds the default discussed above. It would be inappropriate to + issue a T_MTU_TOO_LARGE error, since the consumer is unlikely to + understand or deal correctly with that new error case. Instead, it + is RECOMMENDED that the forwarder: + + * Ignore the mismatch if the reverse link is not congested and + return the requested Data message anyway. + + * If the reverse link is congested, issue an Interest Return with + the T_NO_RESOURCES error code + + This specification does not define or recommend any particular + algorithm for assessing the congestion state of the link(s) to carry + the Data message downstream to the requesting consumers. It is + assumed that a reasonable algorithm is in use, because otherwise even + basic Interest counting forms of congestion control would not be + effective. + + + + + + + +Oran Expires 28 April 2022 [Page 11] + +Internet-Draft Maintaining Flow Balance October 2021 + + +4. Dealing with malicious actors + + First we note that various known attacks in CCNx or NDN can also be + mounted by users employing this method. Attacks that involve + interest flooding, cache pollution, cache poisoning, etc. are neither + worsened nor ameliorated by the introduction of the congestion + control capabilities described here. However, there are two new + vulnerabilities that need to be dealt with. These two new + vulnerabilities involve intentional mis-estimation of data size. + + The first is a consumer who intentionally over-estimates data size + with the goal of preventing other users from using the bandwidth. + This is at most a minor additional concern given the discussion of + how to handle over-estimation by honest clients in Section 3.2. If + one of the amelioration techniques described there is used, the case + of malicious over-estimation is also dealt with adequately. + + The second is a user who intentionally under-estimates the data size + with the goal having its Interest processed while the other + aggregated interests are not processed, thereby causing + T_MTU_TOO_LARGE errors and denying service to the other users with + overlapping requests. There are a number of possible mitigation + techniques for this attack vector, ranging in complexity. We outline + two below; there may be others as or more effective with acceptable + complexity and overhead: + + * (Simplest) A user sending Interests resulting in a T_MTU_TOO_LARGE + error is treated similarly to users mounting interest flooding + attacks; the a router aggregating Interests with differing + expected data sizes rate limits the face(s) exhibiting these + errors, thus decreasing the ability of a user to issue enough mis- + estimated Interests to collide and generate Interest aggregation. + + * An ICN forwarder aggregating Interests remembers in the PIT entry + not only the expected data size of the Interest it forwarded, but + the maximum of the expected data size of the other Interests it + aggregated. If a T_MTU_TOO_LARGE error comes back, instead of + propagating it, the forwarder MAY treat this as a transient error, + drop the Interest Return, and re-forward the Interest using the + maximum expected data size in the PIT (assuming it is is bigger). + This recovers from the error, but the attacker can still cause an + extra round trip to the producer or to an upstream forwarder with + a copy of the data in its Content Store. + + + + + + + + +Oran Expires 28 April 2022 [Page 12] + +Internet-Draft Maintaining Flow Balance October 2021 + + +5. Mapping to CCNx and NDN packet encodings + + The only actual protocol needed is a TLV in Interest messages that + states the size in bytes of the expected Data Message coming back, + and in the Interest Return on a "too big" error to carry the actual + data size. In the case of CCNx, this covers the encapsulated Data + Object, but not the hop-by-hop headers. + +5.1. Packet encoding for CCNx + + For CCNx[RFC8569] there is a new hop-by-hop header TLV, and a new + value of the Interest Return "Return Type". + + Expected Data Size (for Interest messages), or Actual Data Size (for + Interest Return messages) TLV + + +============+===========+================================+ + | Abbrev | Name | Description | + +============+===========+================================+ + | T_DATASIZE | Data Size | Expected (Section 3) or Actual | + | | | (Section 3.2) Data Size | + +------------+-----------+--------------------------------+ + + Table 1: Data Size TLV + +5.2. Packet encoding for NDN + + TBD based on [NDNTLV]. Suggestions from the NDN team greatly + appreciated. + +6. IANA Considerations + + Please Add the T_DATASIZE TLV to the Hop-by-Hop TLV types registry of + RFC8609, with fixed length of 2, and data type numeric + + Expected/Actual Data Size TLV encoding. The range has an upper bound + of 64K bytes, since that is the largest MTU supported by CCNx. + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +---------------+---------------+---------------+---------------+ + | T_DATASIZE | 2 | + +---------------+---------------+---------------+---------------+ + | Expected/Actual Data Size | + +---------------+---------------+ + + Figure 1: Expected/Actual Datazize using RFC8609 encoding + + + + +Oran Expires 28 April 2022 [Page 13] + +Internet-Draft Maintaining Flow Balance October 2021 + + +7. Security Considerations + + Section 4 addresses the major security considerations for this + specification. + +8. Acknowledgements + + Klaus Schneider and Ken Calvert have contributed a number of useful + comments which have substantially improved the document. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Semantics", RFC 8569, + DOI 10.17487/RFC8569, July 2019, + . + + [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Messages in TLV Format", RFC 8609, + DOI 10.17487/RFC8609, July 2019, + . + +9.2. Informative References + + [Carofiglio2012] + Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- + by-hop and receiver-driven interest control protocol for + content-centric networks, in ICN Workshop at SIGcomm + 2012", DOI 10.1145/2377677.2377772, 2102, + . + + [DASH] "Dynamic Adaptive Streaming over HTTP", various, + . + + + + + + + + + +Oran Expires 28 April 2022 [Page 14] + +Internet-Draft Maintaining Flow Balance October 2021 + + + [Ghali2013] + Ghali, C., Narayanan, A., Oran, D., Tsudik, G., and C. + Wood, "Secure Fragmentation for Content-Centric Networks, + in IEEE 14th International Symposium on Network Computing + and Applications", DOI 10.1109/nca.2015.34, 2015, + . + + [I-D.ietf-quic-transport] + Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed + and Secure Transport", Work in Progress, Internet-Draft, + draft-ietf-quic-transport-27, 21 February 2020, + . + + [I-D.irtf-icnrg-flic] + Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like + ICN Collections (FLIC)", Work in Progress, Internet-Draft, + draft-irtf-icnrg-flic-02, 4 November 2019, + . + + [Mahdian2016] + Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, + "MIRCC: Multipath-aware ICN Rate-based Congestion Control, + in Proceedings of the 3rd ACM Conference on Information- + Centric Networking", DOI 10.1145/2984356.2984365, 2016, + . + + [minmaxfairness] + "Max-min Fairness", various, + . + + [NDN] "Named Data Networking", various, + . + + [NDNTLV] "NDN Packet Format Specification.", 2016, + . + + [proportionalfairness] + "Proportionally Fair", various, + . + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + . + + + + + +Oran Expires 28 April 2022 [Page 15] + +Internet-Draft Maintaining Flow Balance October 2021 + + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, + . + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + . + + [Schneider2016] + Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A + Practical Congestion Control Scheme for Named Data + Networking, in Proceedings of the 2016 conference on 3rd + ACM Conference on Information-Centric Networking - ACM-ICN + '16", DOI 10.1145/2984356.2984369, 2016, + . + + [Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level + Multi-path Interest Control for Information Centric + Networking, in 5th ACM Conference on Information-Centric + Networking", DOI 10.1145/3267955.3267971, 2018, + . + + [Wang2013] Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I. + Rhee, "An Improved Hop-by-hop Interest Shaper for + Congestion Control in Named Data Networking, in ACM + SIGCOMM Workshop on Information-Centric Networking", + DOI 10.1145/2534169.2491233, 2013, + . + +Author's Address + + Dave Oran + Network Systems Research and Design + 4 Shady Hill Square + Cambridge, MA 02138 + United States of America + + Email: daveoran@orandom.net + + + + + + + + + +Oran Expires 28 April 2022 [Page 16] diff --git a/draft-oran-icnrg-flowbalance-06.xml b/draft-oran-icnrg-flowbalance-06.xml new file mode 100644 index 0000000..f3d4128 --- /dev/null +++ b/draft-oran-icnrg-flowbalance-06.xml @@ -0,0 +1,477 @@ + + + + + + + + + + + + + + + + + + + + + + + + Maintaining CCNx or NDN flow balance with highly variable data object sizes + + + + + + Network Systems Research and Design +
+ + 4 Shady Hill Square + + Cambridge + MA + 02138 + USA + + + daveoran@orandom.net + +
+ + + + + + ICNRG + + icn + + + + Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. + Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. + + + + + +
+ Introduction + Deeply embedded in some ICN architectures, especially Named Data Networking () and Content-Centric Networking (CCNx ,) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. + + This approach leads to a desire to make the size of the objects carried in Data messages small and near constant, because flow balance can then be kept using simple bookkeeping of how many Interest messages are outstanding. While simple, constraining Data messages to be quite small - usually on the order of a link Maximum Transmission Unit (MTU) - has some constraints and deleterious effects, among which are: + +
    +
  • Such small data objects are inconvenient for many applications; their natural data object sizes can be considerably larger than a link MTU.
    • +
  • Applications with truly small data objects (e.g. voice packets in an Internet telephony applications) have no way to communicate that to the network, causing resources to still be allocated for MTU-sized data objects
    • +
  • When chunking a larger data object into multiple Data messages, each message has to be individually cryptographically hashed and signed, increasing both computational overhead and overall message header size. The signature can be elided when Manifests are used (by signing the Manifest instead), but the overhead of hashing multiple small messages rather than fewer larger ones remains.
    • +
+ + One approach which helps with the last of these is to employ fragmentation for Data messages larger than the Path MTU (PMTU). Such messages are carved into smaller pieces for transmission over the link(s). There are three flavors of fragmentation: end-to-end, hop-by-hop with reassembly at every hop, and hop-by-hop with cut-through of individual fragments. A number of ICN protocol architectures incorporate fragmentation and schemes have been proposed for both NDN and CCNx, for example in . Fragmentation alone does not ameliorate the flow balance problem however, since from a resource allocation standpoint both memory and link bandwidth must be set aside for maximum-sized data objects to avoid congestion collapse under overload. + + The design space considered in this document does not however extend to arbitrarily large objects (e.g. 100's of kilobytes or larger). As the dynamic range of data object sizes gets very large, finding the right tradeoff between handling a large number of small data objects versus a single very large data object when allocating link and buffer resources becomes intractable. Further, the semantics of Interest-Data exchanges means that any error in the exchange results in a re-issue of an Interest for the entire Data object. Very large data objects represent a performance problem because the cost of retransmission when Interests are retransmitted (or re-issued) becomes unsustainably high. Therefore, the method we propose deals with a dynamic range of object sizes from very small (a fraction of a link MTU) to moderately large - about 64 kilobytes or equivalently about 40 Ethernet packets, and assumes an associated fragmentation scheme to handle link MTUs that cannot carry the Data message in a single link-layer packet. + + The approach described in the rest of this document maintains flow balance under the conditions outlined above by allocating resources accurately based on expected Data message size, rather than employing simple interest counting. +
+ +
+ Requirements Language + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. +
+ +
+ Method to enhance congestion control with signaled size information in Interest Messages + Before diving into the specifics of the design, it is useful to consider how congestion control works in NDN/CCNx. Unlike the IP protocol family, which relies on end-to-end congestion control (e.g. TCP, DCCP, SCTP, QUIC), CCNx and NDN employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path and therefore for each outstanding Interest, bandwidth for data returning on the inverse path can be allocated. In many current designs, this allocation is done using simple Interest counting - by queueing and subsequently forwarding one Interest message from a downstream node, implicitly this provides a guarantee (either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send back one Data message. A number of congestion control schemes have been developed that operate in this fashion, for example ,,,. Other schemes, like neither count nor police interests, but instead monitor queues using AQM (active queue management) to mark or drop returning Data packets that have experienced congestion. It is worth noting that every congestion control algorithm has an explicit fairness goal and associated objective function (usually either or ). If your fairness is to be based on resource usage, pure interest counting doesn't do the trick, since a consumer asking for large thing can saturate a link and shift loss to consumers asking for small things. + + In order to deal with a larger dynamic range of Data message size, some means is required to allocate link bandwidth for Data messages in bytes with an upper bound larger than a Path MTU and a lower bound lower than a single link MTU. Since resources are allocated for returning Data based on arriving Interests, this information must be available in Interest messages. + + Therefore, one key idea is the inclusion of an expected data size TLV in each Interest message. This allows each forwarder on the path taken by the Interest to more accurately allocate bandwidth on the inverse path for the returning Data message. Also, by including the expected data size, large objects will have a corresponding weight in resource allocation, maintaining link and forwarder buffering fairness. The simpler Interest counting scheme was nominally "fair" on a per-exchange basis within the variations of data that fit in a single PMTU packet because all Interests produced similar amounts of data in return. In the absence of such a field, it is not feasible to allow a large dynamic range in object size. While schemes like would not employ the expected data size to allocate reverse link bandwidth, they can still benefit from the information to affect the AQM congestion marking algorithm, preferentially marking data packets that exceed the expected data size from the corresponding Interest. + + It is natural to ask whether the additional complexity introduced into an ICN forwarder, and the additional computational cost for the congestion control operations is worthwhile. For congestion control schemes like the additional overhead is not trivial, since no Interest counting is happening. However, if a congestion control is already counting Interests, the additional overhead is minimal, only reading one extra TLV from the Interest and incrementing the outstanding data amount for the corresponding queue by that number rather than a constant of 1. The overhead on returning data is simply reducing the amount by the actual Data message size, rather than by 1. + +
+ How to predict the size of returning Data messages + + This of course raises the question "How does the requester know how big the corresponding Data message coming back will be?". For a number of important applications, the size is known a priori due to the characteristics of the application. Here are some examples: + +
    +
  • For many sensor and other Internet-of-Things applications, the data is instrument readings which have fixed known size.
    • +
  • In video streaming, the data is output of a video encoder which produces variable sized frames. This information is typically made available ahead of time to the streaming clients in the form of a Manifest (e.g , FLIC), which contains the names of the corresponding segments (or individual frames) of video and audio and their sizes.
    • +
  • Internet telephony applications use vocoders that typically employ fixed-size audio frames. Therefore, their size is known either a priori, or via an initialization exchange at the start of an audio session.
    • +
+ + The more complex cases arise where the data size is not known at the time the Interest must be sent. Much of the nuance of the proposed scheme is in how mismatches between the expected data size and the actual Data message returned are handled. The consumer can either under- or over-estimate the data size. In the former case, the under-estimate can lead to congestion and possible loss of data. In the latter case, bandwidth that could have been used by data objects requested by other consumers might be wasted. We first consider "honest" mis-estimates due to imperfect knowledge by the ICN application; later we consider malicious applications that are using the machinery to mount some form of attack. We also consider the effects of Interest aggregation if the aggregated Interests have differing expected data sizes. Also, it should be obvious that if the Data message arrives, the application learns its actual size, which may or may not be useful in adjusting the expected data size estimate for future Interests. + + In all cases, the expected data size from the Interest can be incorporated in the corresponding Pending Interest Table (PIT) entry of each CCNx/NDN forwarder on the path and hence when a (possibly fragmented) Data object comes back, its total size is known and can be compared to the expected size in the PIT for a mismatch. Aside: In the case of fragmentation, we assume a fragmentation scheme in which the total Data message size can be known as soon as any one fragment is received (a reasonable assumption for most any well-designed fragmentation method, such as that in ). +
+ +
+ Handling 'too big' cases + If the returning Data message is larger than the expected data size, the extra data could result in either unfair bandwidth allocation or possibly data loss under congestion conditions. When this is detected, the forwarder has three choices: + +
    +
  1. It could forward the Data message anyway, which is safe under non-congestion conditions, but unfair and possibly unstable when the output link is congested
    2. +
  2. It could forward the data when un-congested (e.g. by assessing output queue depth) but drop it when congested
    3. +
  3. It could always drop the data, as a way of "punishing" the requester for the mis-estimate.
    4. +
+ + Either of the latter two strategies is acceptable from a congestion control point of view. However, it is not a good idea to simply drop the Data message with no feedback to the issuer of the Interest because the application has no way to learn the actual data size and retry. Further, recovery would be delayed until the failing Interest timed out. Therefore, an additional element needed in protocol semantics is the incorporation of a "Data too big" error message (achieved via the use of an "Interest Return" packet in CCNx). + + Upon dropping data as above, the CCNx/NDN forwarder converts the normal Data message into an Interest Return packet containing the existing T_MTU_TOO_LARGE error code and the actual size of the Data message instead of the original content. It propagates that back toward the client identically to how the original Data message would have been handled. Subsequent nodes upon receiving the T_MTU_TOO_LARGE error treat identically to other Interest Return errors. When the Interest Return eventually arrives back to the issuer of the Interest, the user MAY reissue the Interest with the correct expected data size. + + One detail to note is that an Interest Return carrying T_MTU_TOO_LARGE must be deterministically smaller than the expected data size in all cases. This is clearly the case for large data objects, but there is a corner case with small data objects. There has to be a minimum expected data size that a client can specify in their Interests, and that minimum cannot be smaller than the size of a T_MTU_TOO_LARGE Interest Return packet. +
+ +
+ Handling 'too small' cases + Next we consider the case where the returning data is smaller than the expected data size. While this case does not result in congestion, it can cause resources to be inefficiently allocated because not all of the set-aside bandwidth for the returning data object gets used. The simplest and most straightforward way to deal with this case is to essentially ignore it. The motivation for not worrying about the smaller data mismatch is that in many situations that employ usage-based resource measurement (and possibly charging), it is trivial to just account for the usage according to the larger expected data size rather than actual returned data size. Properly adjusting congestion control parameters to somehow penalize users for over-estimating their resource usage requires fairly heavyweight machinery, which in most cases is not warranted. If desired, any of the following mechanisms could be considered: +
    +
  • Attempt to identify future Interests for the same object or closely related objects and allocate resources based on some retained state about the actual size of prior objects
    • +
  • Police consumer behavior and decrease the expected data size in one or more future Interests to compensate
    • +
  • For small objects, do more optimistic resource allocation on the links on the presumption that there will be some "slack" due to clients overestimating data object size.
    • +
+
+ +
+ Interactions with Interest Aggregation + + One protocol detail of CCNx/NDN that needs to be dealt with is Interest Aggregation. Interest Aggregation, while a powerful feature for maintaining flow balance when multiple consumers send Interests for the same Named object, introduces subtle complications. Whenever a second or subsequent Interest arrives at a forwarder with an active PIT entry it is possible that those Interests carry different parameters, for example hop limit, payload, etc. It is therefore necessary to specify the exact behavior of the forwarder for each of the parameters that might differ. In the case of the expected data size parameter defined here, the value is associated with the ingress face on which the Interest creating the PIT entry arrived, as opposed to being global to the PIT entry as a whole. Interest aggregation interacts with expected data size if Interests from different clients contain different values of the expected data size. As above in , the simplest solution to this problem is to ignore it, as most error cases are benign. However, there is one problematic error case where one client provides an accurate expected data size, but another who issued the Interest first underestimates, causing both to receive a T_MTU_TOO_LARGE error. This introduces a denial of service vulnerability, which we discuss below together with the other malicious actor cases. + + There are two cases to consider: + +
    +
  1. The arriving Interest carries an expected data size smaller than any of the values associated with the PIT entry.
    2. +
  2. The arriving Interest carries an expected data size larger than any of the values associated with the PIT entry.
    3. +
+ + For Case (1) the Interest can be safely aggregated since the upstream links will have sufficient bandwidth allocated based on the larger expected data size (assuming the original Interest's expected data size was itself sufficiently large to accommodate the actual size of the returning Data). On the other hand, should the incoming face have bandwidth allocated based on the larger existing Interest's expected data size, or on the smaller value in the arriving interest? Here there are two possible approaches: + +
    +
  1. Allocate based on the data size already in the PIT. In this case the consumer sending the earlier Interest can cause over-allocation of link bandwidth for other incoming faces, but there will not be a T_MTU_TOO_LARGE error generated for that Interest
    2. +
  2. Allocate based on the value in the arriving Interest. If the returning Data is in fact larger, generate a T_MTU_TOO_LARGE Interest Return on that ingress face, while successfully returning the Data message on any faces that do not exhibit a too small expected data size
    3. +
+ + It is RECOMMENDED that the second policy be followed. The reasons behind this recommendation are as follows: + +
    +
  1. The link can be congested quite quickly after the queuing decision is made, especially if the data has a long link-occupancy time, so this is a safer alternative.
    2. +
  2. The cost of returning the error is only one link RTT, since the consumer (or downstream forwarder) can immediately re-issue the Interest with the correct size and perhaps pick up the cached object from the upstream forwarder's Content Store.
    3. +
  3. Being optimistic and returning the data interacts with the behavior of aggregate resource control and resource accounting, which in turn raises the messy issue of whether to "charge" the consumer for the actual bandwidth used or only for the requested bandwidth in the expected data.
    4. +
  4. The rabbit hole goes deeper if you add differential QoS to the equation or consumers "playing games" and intentionally underestimating so their interests get satisfied when links aren't congested. This makes handling malicious actors () more difficult.
    5. +
+ + For Case (2) above, the Interest MUST be forwarded rather than aggregated to prevent a consumer from mounting a denial of service attack by sending intentionally too small expected data size (see for additional detail on this and other attacks). As above for Case (1) it is RECOMMENDED that policy (b) above be followed. +
+ +
+ Operation when some Interests lack the expected data size option and some have it + + Since the expected data size is an optional hop-by-hop packet field, forwarders need to be prepared to handle an arbitrary mix of packets containing or lacking this option. There are two general things to address. + + First, we assume that any forwarder supporting expected data size is running a more sophisticated congestion control algorithm that one employing simple interest counting. The link bandwidth resource allocation is therefore based directly, or indirectly, on the expected Data size in bytes. Therefore, the forwarder has to assign a value to use in the resource allocation for the reverse link. This specification does not mandate any particular approach or a default value to use. However, in the absence on other guidance, it makes sense to do one of two things: + +
    +
  1. Pick a default based on the link MTU of the face on which the Interest arrived and use that for all Interests lacking an expected data size. This is likely to be most compatible with simple interest counting which would rate limit all incoming interests equally.
    2. +
  2. + Configure some values for given Name prefixes that have known sizes. This may be appropriate for dedicated forwarders supporting single use cases, such as: +
      +
    • A forwarder handling IoT sensors sending very small Data messages
      • +
    • A forwarder handling real-time video with large average Data packets that exceed link MTU and are routinely fragmented
      • +
    • A forwarder doing voice trunking where the vocoders produce moderate sized packets, still much smaller than the link MTU
      • +
    +
    3. +
+ + The second area to address is what to do if an interest lacking an expected Data size is responded to by a Data message whose size exceeds the default discussed above. It would be inappropriate to issue a T_MTU_TOO_LARGE error, since the consumer is unlikely to understand or deal correctly with that new error case. Instead, it is RECOMMENDED that the forwarder: + +
    +
  • Ignore the mismatch if the reverse link is not congested and return the requested Data message anyway.
    • +
  • If the reverse link is congested, issue an Interest Return with the T_NO_RESOURCES error code
    • +
+ This specification does not define or recommend any particular algorithm for assessing the congestion state of the link(s) to carry the Data message downstream to the requesting consumers. It is assumed that a reasonable algorithm is in use, because otherwise even basic Interest counting forms of congestion control would not be effective. +
+
+ +
+Dealing with malicious actors + First we note that various known attacks in CCNx or NDN can also be mounted by users employing this method. Attacks that involve interest flooding, cache pollution, cache poisoning, etc. are neither worsened nor ameliorated by the introduction of the congestion control capabilities described here. However, there are two new vulnerabilities that need to be dealt with. These two new vulnerabilities involve intentional mis-estimation of data size. + + The first is a consumer who intentionally over-estimates data size with the goal of preventing other users from using the bandwidth. This is at most a minor additional concern given the discussion of how to handle over-estimation by honest clients in . If one of the amelioration techniques described there is used, the case of malicious over-estimation is also dealt with adequately. + + The second is a user who intentionally under-estimates the data size with the goal having its Interest processed while the other aggregated interests are not processed, thereby causing T_MTU_TOO_LARGE errors and denying service to the other users with overlapping requests. There are a number of possible mitigation techniques for this attack vector, ranging in complexity. We outline two below; there may be others as or more effective with acceptable complexity and overhead: + +
    +
  • (Simplest) A user sending Interests resulting in a T_MTU_TOO_LARGE error is treated similarly to users mounting interest flooding attacks; the a router aggregating Interests with differing expected data sizes rate limits the face(s) exhibiting these errors, thus decreasing the ability of a user to issue enough mis-estimated Interests to collide and generate Interest aggregation.
    • +
  • An ICN forwarder aggregating Interests remembers in the PIT entry not only the expected data size of the Interest it forwarded, but the maximum of the expected data size of the other Interests it aggregated. If a T_MTU_TOO_LARGE error comes back, instead of propagating it, the forwarder MAY treat this as a transient error, drop the Interest Return, and re-forward the Interest using the maximum expected data size in the PIT (assuming it is is bigger). This recovers from the error, but the attacker can still cause an extra round trip to the producer or to an upstream forwarder with a copy of the data in its Content Store.
    • +
+
+ +
+ Mapping to CCNx and NDN packet encodings + The only actual protocol needed is a TLV in Interest messages that states the size in bytes of the expected Data Message coming back, and in the Interest Return on a "too big" error to carry the actual data size. In the case of CCNx, this covers the encapsulated Data Object, but not the hop-by-hop headers. + +
+ Packet encoding for CCNx + For CCNx there is a new hop-by-hop header TLV, and a new value of the Interest Return "Return Type". + + Expected Data Size (for Interest messages), or Actual Data Size (for Interest Return messages) TLV + + Data Size TLV + + + + + + + + + + + + + + +
AbbrevNameDescription
T_DATASIZEData SizeExpected () or Actual () Data Size
+
+ +
+ Packet encoding for NDN + TBD based on . Suggestions from the NDN team greatly appreciated. +
+
+ + + + + +
+ IANA Considerations + Please Add the T_DATASIZE TLV to the Hop-by-Hop TLV types registry of RFC8609, with fixed length of 2, and data type numeric + + Expected/Actual Data Size TLV encoding. The range has an upper bound of 64K bytes, since that is the largest MTU supported by CCNx. + +
+ Expected/Actual Datazize using RFC8609 encoding + +
+ +
+
+ Security Considerations + addresses the major security considerations for this specification. + +
+ +
+ Acknowledgements + Klaus Schneider and Ken Calvert have contributed a number of useful comments which have substantially improved the document. +
+ + + + + + + + + + References + + Normative References + + + + + + + + Informative References + + + + + + + + + Secure Fragmentation for Content-Centric Networks, in IEEE 14th International Symposium on Network Computing and Applications + + + + + + + + + + + + + MIRCC: Multipath-aware ICN Rate-based Congestion Control, in Proceedings of the 3rd ACM Conference on Information-Centric Networking + + + + + + + + + + + + Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks, in ICN Workshop at SIGcomm 2012 + + + + + + + + + + + + An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking, in ACM SIGCOMM Workshop on Information-Centric Networking + + + + + + + + + + + + + + SMIC: Subflow-level Multi-path Interest Control for Information Centric Networking, in 5th ACM Conference on Information-Centric Networking + + + + + + + + + + + A Practical Congestion Control Scheme for Named Data Networking, in Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking - ACM-ICN '16 + + + + + + + + + + + + + Named Data Networking + + various + + + + + + NDN Packet Format Specification. + + + + + + + + Max-min Fairness + + various + + + + + + Proportionally Fair + + various + + + + + + Dynamic Adaptive Streaming over HTTP + + various + + + + + + + + +