<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-tiesel-taps-socketintents-01" category="exp">

  <front>
    <title abbrev="SocketIntents">Socket Intents</title>

    <author initials="P.S." surname="Tiesel" fullname="Philipp S. Tiesel">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>
        <email>philipp@inet.tu-berlin.de</email>
      </address>
    </author>
    <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>
        <email>theresa@inet.tu-berlin.de</email>
      </address>
    </author>
    <author initials="A." surname="Feldmann" fullname="Anja Feldmann">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>
        <email>anja@inet.tu-berlin.de</email>
      </address>
    </author>

    <date year="2017" month="October" day="27"/>

    <area>General</area>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document outlines Socket Intents, a concept that allows applications to share their knowledge about upcoming communication and express their performance preferences in a generic, intuitive and, portable way.
Using Socket Intents, an application can express what it knows, assumes, expects, or wants regarding its network communication.
The information provided by Socket Intents can be used by the network stack to optimize communication in a best-effort way.</t>

<t>Socket Intent can be used to stem against the complexity of exploiting transport diversity, e.g., to automate the choice among multiple paths, provisioning domains or protocols.
By shifting this complexity from the application developer to the operating system, it enables the use of these transport features to a wider range of applications.</t>



    </abstract>


  </front>

  <middle>


<section anchor="conventions-and-definitions" title="Conventions and Definitions">

<t>The words “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, and
“MAY” are used in this document. It’s not shouting; when these
words are capitalized, they have a special meaning as defined
in <xref target="RFC2119"/>.</t>

<t>Association Set, Association, Stream, or Message are used as defined in <xref target="I-D.tiesel-taps-communitgrany"/>.</t>

</section>
<section anchor="intro" title="Introduction">

<t>Despite recent advances in the transport area, the adaption of new transport protocols and transport protocol features is slow.
In practice, this only happens in limited fields as Web browsers or within datacenters.
The same problem occurs for taking advantage of paths or provisioning domains (PvDs).
In both cases, the benefits of the new transport diversity come at the cost of an increased complexity that has to be mastered by the application programmer.</t>

<t>To enable transport features like TCP fast open <xref target="RFC7413"/> or to control how MPTCP <xref target="RFC6824"/> creates subflows requires specialized APIs.
These APIs are not part of the standard socket API, usually not portable, and not available in many programming languages.
Using them often requires profound knowledge of the transport protocol internals.</t>

<t>To use multiple paths, applications usually have to use their own heuristics to select which paths, provisioning domains, or access network to use.
Choosing the right path is difficult as their characteristics differ, e.g., regarding performance.
Obtaining the necessary information is difficult since it may require special privileges and non-portable APIs.</t>

<t>In all cases mentioned above, an application that wants to take advantage of the available transport diversity is faced with substantially higher complexity regarding network APIs and networking code.</t>

</section>
<section anchor="problem-statement" title="Problem Statement">

<t>Application programmers opening a communication channel typically know how this channel will be used.
There is more information available than the protocol and destination address needed to establish a communication channel:
An application developer has an intuition about many aspects of an upcoming communication.
These intuition may include:</t>

<t><list style="hanging">
  <t hangText='preferences:'>
  whether to optimize for bandwidth, latency, or cost</t>
  <t hangText='characteristics:'>
  expected packet rates, byte rates or how many bytes will be sent or received.</t>
  <t hangText='expectations:'>
  towards path availability or packet loss</t>
  <t hangText='resiliences:'>
  whether the application can gracefully handle certain error cases</t>
</list></t>

<t>These preferences, expectations and other information known about the upcoming communication should be expressible in an intuitive, generic way, that is independent of the network and transport protocol.
Its representation should be independent of the actual API used for network communication and should be expressible in whatever API available, e.g., as socket options for BSD sockets or as part of the address resolution configuration for <xref target="I-D.trammell-taps-post-sockets">Post Sockets</xref>.</t>

<t>Socket Intents should enable the OS to adjust the communication channel according to the application’s intents in a best-effort fashion:
They should provide the information needed to automatically enabling transport features the application can benefit from or help choosing the most suitable (combination) of paths based on the properties of the access networks or PvD (see <xref target="RFC7556"/>, Section 6.2) available.
The actual implementation is not part of the Socket Intents concept, it is left to an OS policy that may choose the best transport protocol, default parameters and PvDs available and may also try to further optimize wherever possible.</t>

</section>
<section anchor="concept" title="Socket Intents Concept">

<t>Socket Intents are pieces of information that allow an application to express what they know about the application’s communication.
They indicate what the application wants to achieve, knows, or assumes in general, intuitive terms.
An application can use them to annotate the characteristics, preferences, and intentions it associates with each communication unit.
Depending on the API used, Socket Intents can be used on a per
Association Set, Association, Stream or, Message level.</t>

<t>Socket Intents are optional information that can be considered in a <spanx style="emph">best-effort</spanx> manner.
Socket Intents <spanx style="emph">do not include requirements</spanx>, such as reliable in-order delivery.
Typical examples include desired transport characteristics, e.g., low delay, high throughput, or minimal cost, as well as expected application behavior, e.g., will send 500 bytes.
As this information captures the intents of an applications and passes them along with the communication socket, we call these pieces of information Socket Intents.</t>

<t>Applications have an incentive to specify their intents as accurately as
possible to take advantage of the most suitable existing resources.
Applications are expected to selfishly specify their preferences.
It is up to the OS’s policy to prevent commitment of excessive resources.</t>

<section anchor="interactions-between-socket-intents-and-qos" title="Interactions between Socket Intents and QoS">

<t>Socket Intents are not QoS labels, but have an orthogonal meaning.
While the purpose of QoS is to specify what an application requires, Socket Intents are used to specify what an application knows or prefers.
Therefore,</t>

<t><list style="symbols">
  <t>Socket Intents SHALL be purely advisory.</t>
  <t>Socket Intents MUST NOT be used to derive IntServ / RSVP style guarantees.</t>
  <t>Socket Intents SHOULD be taken into account on a best-effort basis and MAY be used to derive DiffServ Service Classes as described in <xref target="RFC4594"/>.</t>
</list></t>

</section>
</section>
<section anchor="typespec" title="Socket Intent Types">

<t>Socket Intents are structured as key-value-pairs.</t>

<t>The key, called short name, specifies the Socket Intent type.
It is identified by a string of the lower-case characters [a-z],  numbers [0-9] and the separator “-“.</t>

<t>The namespace for the short names is partitioned as follows:</t>

<t><list style="symbols">
  <t>All Socket Intent type not starting with “x-“ or “y-“ are managed by an IANA registry.
  The assignment of new types requires an RFC or expert review (TO BE DECIDED).</t>
  <t>Socket Intent type starting with “x-“ are for experimental use.</t>
  <t>Private or vendor specific Socket Intent type MUST start with “y-[vendor]-“.</t>
</list></t>

<t>Values can be represented as Enum, Int, Float, ASCII-String <xref target="RFC0020"/> or a sequence of the aforementioned data types.
Implementations determine how these types are represented on the respective platform.</t>

<t>The data type for the individual Socket Intents are determined by the document defining the Socket Intent and MUST NOT be changed by an implementation.
For Enum data types, a list of valid values MUST be provided by the document specifying that intent as well as a default value that is equivalent to not specifying this intent.</t>

</section>
<section anchor="types" title="Initial Socket Intent Types">

<t>The following sections contain a list or Socket Intent types and their possible values.
Recommended default values for Enum values are marked with an asterisk (*) behind the level name.</t>

<section anchor="traffic-category" title="Traffic Category">

<t>The Traffic Category describes the dominating traffic pattern of the
respective communication unit expected by the application.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  category</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream</t>
  <t hangText='Data type:'>
  Enum</t>
</list></t>

<texttable>
      <ttcol align='left'>Level</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>query</c>
      <c>Single request / response style workload, latency bound</c>
      <c>control</c>
      <c>Long lasting low bandwidth control channel, not bandwidth bound</c>
      <c>stream</c>
      <c>Stream of bytes/messages with steady data rate</c>
      <c>bulk</c>
      <c>Bulk transfer of large messages, presumably bandwidth bound</c>
      <c>mixed*</c>
      <c>Don’t know or none of the above</c>
</texttable>

<t><list style="hanging">
  <t hangText='Note:'>
  Most categories suggest the use of other intents to further describe the traffic pattern anticipated, e.g., the bulk category suggesting the use of the Size to be Sent intent or the stream category suggesting the
Stream Bitrate and Duration intents.</t>
</list></t>

</section>
<section anchor="size-to-be-sent-received" title="Size to be Sent / Received">

<t>This Intent is used to communicate the expected size of a transfer.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  send_size / recv_size</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream, Message</t>
  <t hangText='Data type:'>
  Int (bytes)</t>
</list></t>

</section>
<section anchor="duration" title="Duration">

<t>This Intent is used to communicate the expected lifetime of the
respective communication unit.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  duration</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream</t>
  <t hangText='Data type:'>
  Int (msec)</t>
</list></t>

</section>
<section anchor="stream-bitrate-sent-received" title="Stream Bitrate Sent / Received">

<t>This Intent is used to communicate the bitrate of the respective
communication unit.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  send_bitrate / recv_bitrate</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream</t>
  <t hangText='Data type:'>
  Int (bits/sec)</t>
</list></t>

</section>
<section anchor="burstiness" title="Burstiness">

<t>This Intent describes the anticipated burst characteristics of the traffic for this communication unit.
It expresses how the traffic sent by the application is expected to vary over time, and, consequently, how long sequences of consecutively sent packets will be.
Note that the actual burst characteristics of the traffic at the receiver side will depend on the network.</t>

<t>This Intent can provide hints to the application on what the resource usage pattern for this communication unit will look like, which can be useful for balancing the requirements of different application.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  bursts</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream</t>
  <t hangText='Data type:'>
  Enum</t>
</list></t>

<texttable>
      <ttcol align='left'>Level</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>no_bursts</c>
      <c>Application sends traffic at a constant rate</c>
      <c>regular_bursts</c>
      <c>Application sends bursts of traffic periodically</c>
      <c>random_bursts</c>
      <c>Application sends bursts of traffic irregularly</c>
      <c>bulk</c>
      <c>Application sends a bulk of traffic</c>
      <c>mixed*</c>
      <c>Don’t know or none of the above</c>
</texttable>

</section>
<section anchor="timeliness" title="Timeliness">

<t>This Intent describes the desired delay characteristics for this communication unit.
It provides hints for the OS whether to optimize for low delay or for other criteria.
There are no hard requirements or implied guarantees on whether these requirements can
actually be satisfied.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  timeliness</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream, Message</t>
  <t hangText='Data type:'>
  Enum</t>
</list></t>

<texttable>
      <ttcol align='left'>Level</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>stream</c>
      <c>Delay and packet delay variation should be kept as low as possible</c>
      <c>interactive</c>
      <c>Delay should be kept as low as possible, but some variation is tolerable</c>
      <c>transfer*</c>
      <c>Delay and packet delay variation should be reasonable, but are not critical</c>
      <c>background</c>
      <c>Delay and packet delay variation is no concern</c>
</texttable>

</section>
<section anchor="disruption-resilience" title="Disruption Resilience">

<t>This Intent describes how an application deals with disruption of its communication, e.g. connection loss.
It communicates how well the application can recover from such disturbance and can have implications on how many resources the OS should allocate to failover techniques for this particular communication unit.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  resilience</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream, Message</t>
  <t hangText='Data type:'>
  Enum</t>
</list></t>

<texttable>
      <ttcol align='left'>Level</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>sensitive</c>
      <c>Disruptions result in application failure, disrupting user experience</c>
      <c>recoverable*</c>
      <c>Disruptions are inconvenient for the application, but can be recovered from</c>
      <c>resilient</c>
      <c>Disruptions have minimal impact for the application</c>
</texttable>

</section>
<section anchor="cost-preferences" title="Cost Preferences">

<t>This describes the Intents of an Application towards costs cased by the respective communication unit.
It should guide the OS how to handle cost vs. performance and reliability tradeoffs.</t>

<t><list style="hanging">
  <t hangText='Short name:'>
  cost</t>
  <t hangText='Applicability:'>
  Association Set, Association, Stream, Message</t>
  <t hangText='Data type:'>
  Enum</t>
</list></t>

<texttable>
      <ttcol align='left'>Level</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>no_expense</c>
      <c>Avoid expensive transports and consider failing otherwise</c>
      <c>optimize_cost</c>
      <c>Prefer inexpensive transports and accept service degradation</c>
      <c>balance_cost*</c>
      <c>Do not bias balancing cost and other criteria</c>
      <c>ignore_cost</c>
      <c>Ignore cost, choose transport solely based on other criteria</c>
</texttable>

<t><list style="hanging">
  <t hangText='Note:'>
  the “no_expense” level implicitly asks the OS to fail communication attempts if no inexpensive transports are available.</t>
  <t>Application developers MUST be aware that this also no hard requirement and can be ignored or overridden by the OS policy.</t>
</list></t>

</section>
</section>
<section anchor="implementation-guidelines" title="Implementation Guidelines">

<t>Implementations faced with unknown Socket Intent types SHOULD ignore these intents for forward compatibility.
The API MAY include a parameter to change this behavior and make specifying unknown Socket Intent types return an error.</t>

<t>Invalid values SHOULD return an error to the application.</t>

<t>For debugging purposes, implementations SHOULD allow to enumerate the Socket Intents that are understood by the implementation.
They MAY expose which of the Socket Intents were considered by the implementation.</t>

</section>
<section anchor="sec" title="Security Considerations">

<section anchor="performance-degradation-attacks" title="Performance Degradation Attacks">

<t>We assume that applications specify their preferences in a selfish, but
not malicious way and that it is up to the OS to find a compromise
between demands.</t>

<t>A malicious application could confuse the OS in a way that leads to scheduling traffic with certain Intents on a more expensive interface,
penalizing this traffic, or even rejecting it.
The attack vector added by this is negligible:
As the malicious application could also generate the traffic it claims
to intend, it already has a much more powerful attack vector.</t>

<t>As a mitigation, the OS could monitor and compare the intents specified
with the traffic actually generated and notify the user if the usage
of Socket Intents is unusual or defective.</t>

</section>
<section anchor="information-leakage" title="Information Leakage">

<t>Varying the transport or IP layer parameters of packets belonging to
different Streams or Messages multiplexed in the same encrypted
association might enable an attacker to gain some ground truth
about the shares of different kinds of traffic. As this might also
be implied by packet timings, application developers might weight the
small additional information disclosure against the possible
performance gains. Using Socket Intents on Association level can be
considered safe.</t>

</section>
</section>
<section anchor="iana" title="IANA Considerations">

<t>The Socket Intents type namespace SHOULD be managed by the IANA
registry. Details conforming to <xref target="RFC5226"/> are laid out in
<xref target="typespec"/>, the initial types for the registry are described in
<xref target="types"/>.</t>

</section>
<section anchor="publications-history" title="Publications History">

<t><list style="symbols">
  <t>The original idea of Socket Intents was published in <xref target="CoNEXT2013"/>.</t>
  <t>A performance study “Socket Intents: OS Support for Using Multiple Access Networks and its Benefits for Web Browsing” is under submission.</t>
</list></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>This work has been supported by Leibniz Prize project funds of DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC0020" target='https://www.rfc-editor.org/info/rfc20'>
<front>
<title>ASCII format for network interchange</title>
<author initials='V.G.' surname='Cerf' fullname='V.G. Cerf'><organization /></author>
<date year='1969' month='October' />
</front>
<seriesInfo name='STD' value='80'/>
<seriesInfo name='RFC' value='20'/>
<seriesInfo name='DOI' value='10.17487/RFC0020'/>
</reference>



<reference  anchor="RFC5226" target='https://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC4594" target='https://www.rfc-editor.org/info/rfc4594'>
<front>
<title>Configuration Guidelines for DiffServ Service Classes</title>
<author initials='J.' surname='Babiarz' fullname='J. Babiarz'><organization /></author>
<author initials='K.' surname='Chan' fullname='K. Chan'><organization /></author>
<author initials='F.' surname='Baker' fullname='F. Baker'><organization /></author>
<date year='2006' month='August' />
<abstract><t>This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms.  There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4594'/>
<seriesInfo name='DOI' value='10.17487/RFC4594'/>
</reference>



<reference  anchor="RFC4960" target='https://www.rfc-editor.org/info/rfc4960'>
<front>
<title>Stream Control Transmission Protocol</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart' role='editor'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t><t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services to its users:</t><t>--  acknowledged error-free non-duplicated transfer of user data,</t><t>--  data fragmentation to conform to discovered path MTU size,</t><t>--  sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t><t>--  optional bundling of multiple user messages into a single SCTP packet, and</t><t>--  network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t><t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4960'/>
<seriesInfo name='DOI' value='10.17487/RFC4960'/>
</reference>



<reference  anchor="RFC6824" target='https://www.rfc-editor.org/info/rfc6824'>
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<author initials='A.' surname='Ford' fullname='A. Ford'><organization /></author>
<author initials='C.' surname='Raiciu' fullname='C. Raiciu'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='O.' surname='Bonaventure' fullname='O. Bonaventure'><organization /></author>
<date year='2013' month='January' />
<abstract><t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers.  The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t><t>Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.  This  document defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='6824'/>
<seriesInfo name='DOI' value='10.17487/RFC6824'/>
</reference>



<reference  anchor="RFC7413" target='https://www.rfc-editor.org/info/rfc7413'>
<front>
<title>TCP Fast Open</title>
<author initials='Y.' surname='Cheng' fullname='Y. Cheng'><organization /></author>
<author initials='J.' surname='Chu' fullname='J. Chu'><organization /></author>
<author initials='S.' surname='Radhakrishnan' fullname='S. Radhakrishnan'><organization /></author>
<author initials='A.' surname='Jain' fullname='A. Jain'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document describes an experimental TCP mechanism called TCP Fast Open (TFO).  TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged.  However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.  Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.</t></abstract>
</front>
<seriesInfo name='RFC' value='7413'/>
<seriesInfo name='DOI' value='10.17487/RFC7413'/>
</reference>



<reference  anchor="RFC7556" target='https://www.rfc-editor.org/info/rfc7556'>
<front>
<title>Multiple Provisioning Domain Architecture</title>
<author initials='D.' surname='Anipko' fullname='D. Anipko' role='editor'><organization /></author>
<date year='2015' month='June' />
<abstract><t>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t></abstract>
</front>
<seriesInfo name='RFC' value='7556'/>
<seriesInfo name='DOI' value='10.17487/RFC7556'/>
</reference>



<reference anchor="I-D.pauly-taps-guidelines">
<front>
<title>Guidelines for Racing During Connection Establishment</title>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<date month='October' day='24' year='2017' />

<abstract><t>Often, connections created across the Internet have multiple options of how to communicate: address families, specific IP addresses, network attachments, and application and transport protocols.  This document describes how an implementation can race multiple options during connection establishment, and expose this functionality through an API.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pauly-taps-guidelines-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pauly-taps-guidelines-01.txt' />
</reference>



<reference anchor="I-D.trammell-taps-post-sockets">
<front>
<title>Post Sockets, An Abstract Programming Interface for the Transport Layer</title>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='C' surname='Perkins' fullname='Colin Perkins'>
    <organization />
</author>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='October' day='27' year='2017' />

<abstract><t>This document describes Post Sockets, an asynchronous abstract programming interface for the atomic transmission of messages in an inherently multipath environment.  Post replaces connections with long-lived associations between endpoints, with the possibility to cache cryptographic state in order to reduce amortized connection latency.  We present this abstract interface as an illustration of what is possible with present developments in transport protocols when freed from the strictures of the current sockets API.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-trammell-taps-post-sockets-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-trammell-taps-post-sockets-03.txt' />
</reference>



<reference anchor="I-D.tiesel-taps-communitgrany">
<front>
<title>Communication Units Granularity Considerations for Multi-Path Aware Transport Selection</title>

<author initials='P' surname='Tiesel' fullname='Philipp Tiesel'>
    <organization />
</author>

<author initials='T' surname='Enghardt' fullname='Theresa Enghardt'>
    <organization />
</author>

<date month='October' day='26' year='2017' />

<abstract><t>This document provides guidelines how to reason about the composition of multi-path aware systems and how to compose the functionality needed by stacking existing protocols.  It discusses fundamental mechanisms that are used in multi-path systems and the consequences of applying them to different granularities of communication units. This document is targeted as consideration basis for automation of destination selection, path selection, and transport protocol selection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-tiesel-taps-communitgrany-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-tiesel-taps-communitgrany-01.txt' />
</reference>


<reference anchor="DASH" target="https://www.iso.org/standard/65274.html">
  <front>
    <title>Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats</title>
    <author >
      <organization>International Organization for Standardization</organization>
    </author>
    <date year="2011" month="June"/>
  </front>
  <seriesInfo name="Standard ISO/IEC 23009-1:2014" value=""/>
</reference>


<reference anchor="CoNEXT2013" >
  <front>
    <title>Socket intents</title>
    <author initials="P." surname="Schmidt" fullname="Philipp S. Schmidt">
      <organization></organization>
    </author>
    <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
      <organization></organization>
    </author>
    <author initials="R." surname="Khalili" fullname="Ramin Khalili">
      <organization></organization>
    </author>
    <author initials="A." surname="Feldmann" fullname="Anja Feldmann">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
  <seriesInfo name="Proceedings of the ninth ACM conference on Emerging networking experiments and technologies - CoNEXT" value="'13"/>
  <seriesInfo name="DOI" value="10.1145/2535372.2535405"/>
</reference>




    </references>


<section anchor="examples" title="Usage examples">

<section anchor="example-1" title="Example 1">

<t>Consider a cellphone performing an OS upgrade.
This process usually implies downloading a large file.
This is a bulk transfer for which the application may already know
the file size.
Timing is typically noncritical and the data can be downloaded as
background traffic with minimal cost and power overhead.
It would not hurt if the TCP connection was closed during the
transfer as the download can be continued.</t>

<t>For this case, the application should set the “Traffic Category”
to “bulk”, “Timeliness” to “background”, and “Application Resilience”
to “resilient”.
In addition, “Message Size to be Received” can be provided.
Finally, the application may set the the “Cost Preferences” to “no_expense”.</t>

<t>The OS can use this information and therefore may schedule this
transfer on a flaky but not traffic-billed WiFi link and may reject
the connection attempt if no cheap access link is available.</t>

</section>
<section anchor="example-2" title="Example 2">

<t>Consider a user watching non-live video content using MPEG-DASH <xref target="DASH"/>.
This usually means fetching a stream of video chunks.
The application should know the size of each chunk and may know
the bitrate and the duration of each chunk and the whole video.
Disconnection of the TCP connection should be avoided
because that might have an effect that is visible to the user.</t>

<t>For this case, the application should set the “Traffic Category” to
“stream”, the “Timeliness” to “stream”, and “Application Resilience”
to “sensitive”. It may also provide the “Stream Bitrate Received”
and “Duration” expected.
Finally, the application may set the the “Cost Preferences” to
“balance_cost”.</t>

<t>The OS can use this information and, e.g, use MPTCP <xref target="RFC6824"/> if
available to schedule the traffic on the cheaper link (e.g, WiFi)
while establishing an additional subflow over an expensive link
(e.g., LTE).
If the desired bandwidth cannot be matched by the cheaper link, the
more expensive link can be added to satisfy the desired bandwidth.</t>

<t>If the application would set the “Cost Preferences” to
“optimize_cost”, the OS would not schedule traffic on the second
subflow and the application would reduce the video quality to
adapt to the available data rate.</t>

</section>
<section anchor="example-3" title="Example 3">
<t>Consider a user managing a remote machine via SSH.
This usually involves at least one long-lived console session and
possibly file transfers using SCP or rsync multiplexed on the same
association (e.g. TCP connection).</t>

<t>For the packets sent for the console session, the application can set the “Traffic Category” to “control”, the “Burstiness” to “random bursts”, the timeliness to “interactive” and the resilience to “sensitive”.
For the packets of the file transfers, SSH may set both, the “Traffic Category” and “Burstiness” to “bulk”. It may also know the size of the transfer and therefore sets “Message Size to be Sent” or “Message Size to be Received”.</t>

<t>Assuming there are transport opportunities supporting multiple
streams in a single association (e.g. SCPT <xref target="RFC4960"/>),
the OS can use this information to schedule the streams
over different links to meet their requirements (latency vs. bandwidth).
In case the OS has to use TCP, it can still optimize by disabling
TCP Nagle Algorithm for console session related transmissions.</t>

</section>
</section>
<section anchor="changes" title="Changes">

<section anchor="since-00" title="Since -00">

<t><list style="symbols">
  <t>Updates on Terminology (Object -&gt; Message, Flow -&gt; Assocication)</t>
  <t>More detailed Socket Intent Types specification</t>
  <t>Added implementation guidelines</t>
  <t>Many clairfications</t>
  <t>Fixed Authors and affiliations</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAOfe9FkAA+Vca3MbR3b9Pr+iC/6wkgqAKFmyY6aSCiVKtiqSxZj0Ohvb
5RpgGkAvBzPY6RnSsKz/nnPu7Z4XQFneeKu2KvwgAfPovn37Ps59NGazWVK7
Oren5rJcXtvavCpqW9Q+SReLyt7Ey/FqVi6LdIunsypd1bPaWW/zWZ3u/MzL
g04fnJ08SrK0xoOPTx59Pnt0Mnv8ebLEhXVZ7U+N/XmXJG5XnZq6anz9+OTk
i5PHSVrZ9NR8aQtbpXlyW1bX66psdqfm6uzi0nyH765Ymy95Lbm2ezyQnQq9
VWHr2TkpShJfp0X2U5qXBSbfW5/s3Kn5vi6XU+PLqq7syuPTfssPPyZJ2tSb
sjpNzCwx+HOFPzUXc3M5N1eyNrmqS77YuNztdqN7ZbVOC/dLWruyAKXfmme2
yl0h9zyms/WpeZNWyw2+zM3jT+XG0tXgQu/JZdkUNTnzpa22abGXi3abuvzU
7HTe/3BY5bxuZgt5bZ7ZAdFXc/OiWG/SKqt7NF9tbGV9Orz1jye51ml/g+Sz
uXlp8wwvFz2Sz4q/psPr/3h6U8x5hNikKPFo7W4sBMR88/L5ycnjk/Dx6ePH
n4WPjx89+uIU8lysRo8/efrFk/jxi8/im5/9y+N49fMnjz6NH58+lfFezc7n
u7TJ96pV68ZlFuRYH2/WVbrd2jxo3a70dVC97omeVi7L7bYpXL2usGQ+cH52
+dWprN2YVvjDHxgdFUqYnebmbY/3Buszl9QviFK4Ft4NNmRyvscmuqVJs3RH
Rsj+4Ar0tryxlfnq6urC3CMN983MXKRVbR5h82zmUrODyMB26FSZ9cvK7eQz
JjTerre4aZTFfhLmbW3Mo9nJZ5GWtFpTJDZ1vfOnDx/e3t7OnS/nWN1DH6h/
+NnTx58/mW/qbR7e8rYC27iHHT/iWs2ry7cPX714DtmCpZo9OsWET/DU8/Lr
F/99hS+fnprzt6/mj07mjx49efrw8dNPn376+eM5/39y8jRJZrOZSRfgRbqE
ibraOG9gSRtZUdnUsr8jAzw1KUS2WNpdDXVKa5PmeXnrTbrb5W4pTPKmLo2H
XlsqnKvMdVHe5jZbW0yGYU2zw/aT90EK9DXhJyww2O3DiztbCWMxHbdhBe3F
Rw81BRVrGmQH+wnb3jjZVYwwNTuY03SRW3Ob7ufJt54THayh6BNslvgeZ77l
olwtRPNJ78EPfMB9u+S7ELbbFKOYyq4pcBje4Ru0lK5huKY5mGpNq4GYaleV
N1CdzCz2I6qEioU1jde7YEE7KORjeU22lhC9rfvFjlgnDFlY6JxdYa5a154M
JhiMzx2q7dak6xQ2r5bJMOQutz/DQJlyxfXmJdiK5UE+Ck+2mgxcrjyeAD/m
6/mU40BbSyzO6hib0mGz0m2J97ZNXjsMaXZpvQHnZO0e9HLQDC9harIT1+EI
y9zPk2d7SI5b6bSUxx5Rq6rcyiT9rcvsjc1LCApJ4U1+TuV9v+cSp9xMW1Ai
RKy4fq4PH/GhW9rKpnVTWRHe1NxijyqDm2t5uC/d4KsoztZlWQ5j/LwsbsBe
EXyK8LldOVg2fk/+7e6/RESDYMGbyZtvL68mU/3ffP1WPl9+dfb6dfuhu/r2
29fnE4pwlkzenP1lYqhosqmQgrqvw3Pzqv4TJLOswVQoHpjyr5BvW+jiE52c
ry/TnavTHIIFBcLNvdmk1CfjIfQO9nZrU9m1FKNzfTaDXzHv3gU38/49uHLm
YfCdbsulraemd2EKo0WLK+rzBnqW0hpEwrtRjYz6QW8hcyUJhLoqs2Yp04W/
d584Xn2fDBl9bj2WZ6GwS+pBmt2k0YxQIDoZINKbqoiJo8DI2PzC3vaeaYVV
NvvweidI2AkP2zgHqbgLEwvNmOoOlUVOFu92thAycih1jdWvHACGJz++swuz
qGCCoG9ichxeLOhYUi4CV9W2eIATzg3x3ppyuWzwOP1hnQoqlbXWqUqxqGFQ
uENFvHdxc+7vC7WLst5AJjztHrmxgKld0cip3ow40hoFKitYF60JzApVh9Zp
CcZyo3vaLM5jk4q+wSptUyhr1Vm+vo6D3LWgiwo7f1UGbT6mu7m7tubq+YVZ
pZwd7FUZJaB5/55Lx2xwXxCS3GzKW/Pmgk/LM8Q/eIak1hjKN4uVeLbK/q1x
HDzoApXEnF280g2ADeFnkWUq2o7YIbApenWjQIgPTiHwDVzmXh8Orkq0Wa6k
NwB+sjpsNuFgu3huVQ571GAzffRrmAW7voJ578jECytgyqzndgM9R4TVKaqi
6SVnaRvHVnvg2SP1Yh5qfUF9dXlbmI1tKuch5woBbA6PCYPjlpsPuQCxCely
Se8bHZ4OPU+eb8oyrtRUbr2pZSTqVuZWK7cEsVQXpWEJ0AE9s5EIPmKr6Ks6
f93DFfPk7aIGFXGOwpKOtNoPvPZgOtADFwevsk33ke2todxV7sblFnsU9rSY
tYBEhYYKBh6qfpmtug4awQWg6AE0ETVRvEEHl17boU6LrrRCc0wpQfsKNiMT
E0KxpljWTrcRHIWf66llx6S4FSreXIteUOCWWbHCF8HyAJLC12Ithy4PjuGo
LnvRTzFSIzSDbSwKm5t6v8Ml0klRFn1VTBDu3zqwMSAaUUbsA25vy2qIuXr8
wZvCslYBuDCAevjG8GyWVSqINlOchJt41/nNXXSeJmfFHZiE9k0MoCBUDi8A
WBQ79QIog408jomjiekGoMxB/vImQzSXJD1UfJqc0rkzxh0gRXqDBZYJSFNv
prAhsBbLvSgdbXSSjLSG4yjYxfp3qViuiiZxCttMLyrmEW9zP2QlvOzb3fAS
PVTibSGE2JlEh1MTwuHr8jYl9BBVDrvjcgGeVZwyL71PEuwFbhyub+QhCG0h
Vku7atQ6FYBmZmkrqraxVcXFUt+SJHC0x7iI7dMOw5UyS1+GKIFx+wRFHo9h
iLPyjGwI8YQLtryTAip5iF0I06eq4o44ILPQiEz4Fx2t6uBxqAFfLWHIIELt
KDgyHrYZ9psqrcCLsnE0cNHg9q7FMEayjJs5UKtd0c5C5oPDK3fKUk7z7PI8
XBbhSf3AVUa1wz9l3uielsXKrZuqi/G/vyCm0KDG/3jvkw+nHe6PAyAfFxTx
A+Z9eyl4P/tr0wVBRywRvFOpVjFEGT3h+5M3Ibt4GIYBhmyYHaLQ7eP0IQSU
cfoi1pmcEFIF4yfkDuOwLlg5oggBrWm8RD21+Y6BWedIt+SjhzAKH+5hzYtg
/+53OHEhiK1s7SXsGTF5J0p9hy17CgBp7nlrA+Z6+vSz9+8B/K1i9M/mj+93
wqLoNcijo/vZtiLs/AGUGofKmoGQ2A5P53ZVC98KbuiuBDsCwKS5lKXbAGS5
zQeKNGX4kdK3Y04AasJr0QBC4p774CWOCLwEMQBGwJyrphJj0drbW/ohKgeE
UTSGjnJE//OQQXn3SVjJ+ztCxYM3iTN3jiCFrOmLT5eNOcAQ5TC7IQGeuNTO
ng0F+tAJ0etkvGDbMQZztBAlXW6cpY0LCRTRdcmhUD3WmkXvJ23A7C1g0dlh
SiaAy61uLUSiyzIMPNZ0aM25S6qRYnwcAaIGouKl4HIsiBxpOsPLOSJFGkxJ
C6rcR0s5/VCyhuaSmPKjImAwZNpGwDmRwqGd4iar7aRyjPc4TA3J8cxSaNCc
mgc9w/OAjrlgvDQa+UFWim4FCBHhK3XPP5jCJoAxKc1w7kIUMoPhgzAz2wuh
3kMYFJVBpFKqrW/HAoxypKbTr4N9UgdBEcV49H0EoFhVVTbrza6pRVzgVt0W
ExCdiDe5hX3n/y0q6QvKwiIWcWWL8gWGwB1m5unJiUITCJdX5Njn5RIRfmtD
owVXMDYIeShOO0iQPrk1rOGsVY4OHYb6HlDBnAoI0SzTcYUdbs18gJN9SMBI
8ExJ1nBLoozVPoQ7kWiCTEb+EPCcuDKJlufukGHoAQD9vaTM6H6baiksG/Cg
sh33NbRbARFjtiFFPT0kOKFtbnbRZ769hGWJxrnkszeSlgQDXb0NKMX+TLfC
5fZokWyPlRQKqVnA51g7ZqBs1H+Vl0zOfezfUc2jfmAcIOWFzYl6m7rdDUj1
plyLXoaU2Dz5buMCmtg11a7U9CIHcL6/Z2I2R5Y5Bu0H5qVNjf3GAGJkNaVD
zvsQBkHI7DRJzGw8ruYSF0KqCEuGcLykWh8+G5OR/aQxTAH3Bo9c2urGPDTf
XP75wvh6Dw6sG2g73uWOHZuZiUuORYkUNFwKrmq48WPgBPDhdEffnP3lCAHn
iMaFAv7DjPPzXFVUUoms0SxiMjEUvDRtOMyIw5ThlXef1PwfXD7qhY/KiK+r
ZknzIcnLa7uf3aR5Y2e71FWSS4E04OpUrIAVKI1VsZI4DfvpguUZUkRKouY4
Inc+KEmxlHOKZ1INhhG11YxBTWdmvfnh+3T2yw8/To0pmu1Cr5zMvvjhRw0h
mJSyxDg1RGYymwRKSZdH3KXBojzV0it5TEIxF/MUxPNS9DkVCTuDmTtchGad
a74XreXk59mEojrZzzRpDR8Fk6SrK8yrs6/PmH6AKRJ5NAIQYQvWRTQOkneU
PWuzXXgRG8xhaZ9AM6yKw2P3rt6aZy/M+Yvnr85fnN8/lEil8giFpGwVx3OC
SnNNRrE0COkjCsF9GK8M/4XdXB4bXTRIpgjj72c/fK/v/fCjcP/PlJoWTbSh
nLL5BfZwygGn5mVepsQTl89fvZpdqiCIaLP0q5lNCAiYQtvbQnSagS7BxNyx
sg8SNkDc1BnCMFfYkGWR2ohwmuzo0xWAUSUKI35pl6c1vVoQpnaaVpiIHBHx
EOkfUaV26jb329YgpSgQg5Yhf8U09AwUI7VOloYBxTx5CUrIzR4PWMjMneao
obsuMze6FzLqwg4qdQOqgj1Wuhi6B4o6oJK28YSM2Ub4FFpcEflQHDYYy8VI
MhQ4HLN05gMm666ooVdgUlWVcpgN7pP571Qgo66/OiK6PtoL18UxgUHz5BtL
n83MQjZcqEb6wujwXdW8uo7pR7ovL4Dw2tx7cJ/ozQXDJFhYTA4FqUqZbjXP
Q2/OgVPX1Y0fa22/D1u2lbhWY2d5ErEtM95BRZKeGB/GAx3kOSxKELS3NpKp
qdhF1MI4zWjx1seEBUlyHkWTr5CHSfKreS1MiX+/mvNe/8FH//2a/Dri3vj7
R/5hIAMTAz53FF2Cu7kGEgyuH4plgJjZgAqYHYDxytrMo1lIdYJjxUpMHOt1
KUUOxaKMEtq8ZftoyMhMRXu6292Y2tnRoy9EXSuNBR5uNfQKkSBkMc32ahaI
n2WIRZNf97hnnvG7RDUrBvorkFgBSseRJPxEhAsovT9K0tb9bLMHvU1EjK0N
BlS+Asa5tdisAeCd5OuyFjl4Q5weRMtJVWq9tiFVFQrZMVepFrWXkYi6EGs/
A/lnCWDp8I2xbajlM0HCpUZRjrNFC9xVzrHrv9hQubukzQg2MKIH5fkd4yRh
S565WlguRfOY53NtNJSM5wDYDCnlD0D80MYSTBnjjwAcO/VWhrS67TkN4752
iw90m+HkT/IcxXt5I5//TkVvg/+RxoNic09E9D6tf2RI8vcvLHcrWwPAfJSt
O1hzFgn4Q+yZrG4LFySLGwnAx+/u72LEIgwfRLZbfvIRy5ctjyOEXQ9f/0CO
YET/MHLlWVNRRyAdyZ3LHfq3nhJDcyt/kHHpVX5F+xWROX9UAF7VMU2I4QMM
bN+Uqs6R2rzzg8TADSun0lJHyZtqRxYzVQJN65wpH4wsKZQIV4VKeWbZcHuY
VeBsWghqC0tzMYqKpXq1jI9ad3gllKQA2pl/l3G1RBJRbchmz4dMJzqPSXvA
lVCKHTGiLLrEaExdQDSZc4k29wPcV2LysryWHoZpqJp3WcZVk4dKXp4Wy7Yi
3kvfcc1a8BY0OoAqI+EWnvk/Eqn8c2KVovxJlxoo6heiqeC+LyDS1yi18Q4J
IBxt4OzjKMdGCLcocNHFQgrLLBRvZBRoQbn9fYO4KswdxhhjksMxUn2mN8bf
iT0g/NDd/HdZopj7lbTugTb+ltkJyuWDdsW48e3lnQXtNoXMVfCCoiBQxFnT
2A2g6TzDHvORrlQSIzK30qWtVIfbCrMf6ReUMVGjQ5zH1qvaeaZnDhWs7hj4
x6KEoG3/jMo2Bt7nsj2aPZfwUvcLHsKNK9XXrIUhbpbale8CTg7rYuYXwtkN
+5vvatrWsyGtm1ESsjmGi4NHxPfg99PMjraySNupYuaYIij1EdFajMLDIhjw
48aX0qeWN+EwVBvPna8a3dlv2naI4yDpLhXdHBYFM5vmIQjKuglYoqhHeqrx
AYkqQimXvRmiuD3IpZNIBuRYURquV2CBFKWlzIRZ66ZaSHM3OcKnJM0uihkr
D3i97TNpKwLROoTdYNFTUR+Cn9Tlij/sclO4v8WkhJgfSWMuaVWPI+CRFnfN
J/+PtNgW3gVlE4pa2ZDmDKZ63FCQyPGmghZEMQI2AWCJCVRJSKovFQmgxjwY
j5xKx9ZSOqldOE8xFiNVszZTKoOxhYUCpePrbtVHKBe5inVFyBfsybEpVN+e
M+a+6CpZR3NPzo88YExpagXxbFB+124n1jO9tCG1CaXfCMle1VHE5bxNFHvB
5mXb5URyb/x8cFqCCqVFXO2rgqHLbLla+cO8lfSA/QPE+59RugEIKZXMTglF
Zzelk0MnlPqbXv+k5j9jiV1kXGovxAa3zqtER0Tyk2zBr0FmIMh3DsimGbgr
H4pWmV1jX6Lo/RrAvY73QMCaprlc6nvAX2brutQi5lFvuS7KKhDEBb6S76GU
Hhth2vq8hzOUnFXoYjgYsM1DUfImHfcmIVurptrVUna+bu1ysMPjljJEQdsd
26RWdHJ3samy/S6h04EqtZ2VXZo+vdWDRhJ6sWbI3pwjmK/1MeyME65kRIG0
IpXLMltEnWw7iDQLP2xN+rI993Z36n380qD/tim0k/BYyj2USJW6gEBjXm+l
OJeWRNp1MbIqqzZSsU+FldLYi5F2nUySGpHqiDIoNkyEbqZr2y9CfIi8ysJf
SyejNFRKJ/OgchLoHz13JFjGq6zIZHbRrNfSkK2Fcz8dVW7aMbWviY1MsC22
iimeUTlJW6BYOi+gtb4uy9bSjitC0tJEjkEIqRQabx/vNru11aDd5o4hiR/s
sqlob5+Hp8Mq3n3i76guq8Bc9Ez3ec8onNU8+HXogQ4c0nc2dFkFHvSbN+5s
0dC+odDLIe41obmBj4ROl41ne2qoA+mZuFE7h+g5yzfSGI0gbgvLmMTujMxi
PZn0tfSGHOBCcW3s8wydXhxTaOLEMmlu00y7KJYbmzV5v5Qj+hR7fFv3y9el
A7yzLhJCUAenCS7xBEdbbwtjSd8R21EgvH+lQ5ZDfaFHUfbA3OAylSZrS4JO
SuOFXeduzZDjVNuM7AdXK+ZJu+DqYWYe/F3mqdv6pC5V7TPpb0zzSmoU0ktu
toTOsr4dGwCYFhoQKOew+BxA3Dp468BZJWBbAloE7RdDUsVO1NAjG7oTsqRt
cWqTJDH4jfRn8dxKEC/FfW4VPhMZQKNG2kQhKuQciREbsFIApF0+XXfUa5te
c4Cj4v7ntNrHHFjnzjDcqwuDgIrNl10jp3S0aipxYZl51D7epEuWKZzxvbNp
vj0G83M8WBfOWkFzqv0Oa0/SHkTaytGU0FicFmFP1PjyiKVGoiEUrKum3iRd
76WclR3l764dczpdMmduYg+bTkU5Sha2zWJAIkNISUxSrIcHd/qOU9+/tfIf
6wJ+y041CLY70nEIUL9EuNfQK/fOisYwO+mDTrk/N8eO3FIv+5BS4YO646Rn
Wn260oMl0g1yYEVdWqR3NOlcHXEH0ofS9rZ0HUi9xhOB7pgraTtPYIBhUXKp
k3Npoetbui14uv79e3ExUNWMh6TBreTdu7aD6P00aJMW79VzxlAjzhH6Hro2
pTiCNildNIvOen+FN1hWPu44ZtIlU1awQLJziOrNocrdMjHSyCGW2BXVnRHn
nDNzNggfEJnD4kyGw5zSiFw2O+1Ax5J0o9/E82Jn2hH+dewIlz5czP4snh7k
OzzX+IznGvHqRG0BAbZvFnAePvrRs2V7eE1ybwerDyGYHFygYVzQ43ilTTf2
tXWLwv3Cjp1fpJmDdt2smqBW5y+/NLPwmwtMq1j+UIN5Sf0Uxp+aL8u6XlXU
re9cvrH5Ng45A87H3Dzdb+69/M//MS9fmKefnzx8Mnt0X6iHiZLMT5J8K/n/
tlP23Sfx41iIk+SF3jGPkp6diwpAD2vzfLdhvjZslJyckob3ZkfEIC31Ts7/
yT7Eo3pqIXgq+LZgIV5PXGkJe+Xy+JprM8htpZv7pbhoHCdrE7z6Je5Uwgc4
mFRT50wgiwv1vTNcRVm0ubHYjCZ19wDKI33S+5T0MmcDf99vDtZEGt2gwPgN
yJGY+VYcHaHMpoGoBn/Eg569HBZ1gpaNSeumiqXpdu1p7CBRonpN1wAHjeR8
X7ZZbcRP0wMehcjdW7WYk3GvyoR+fkKO81x3l3KfGLnerl/PeptJPw7q8oA6
Spv7mMj53WjLeaI8dJr3iumxzjqJi4qdTvPkJa1Ivj9cDDc8rkRWM06SKNW9
CDF0gxF3tK38ow7sIAXarqpTKMrTZ7vNEFC3ytPrveSAuLNBKGYIgnJR0ZfO
gH/X7RkNBXKJtmi3ux5i0BCCYrZ0F0+yyNvO94PPTisf36GVAnhu03q5kSOT
ZTFjm7whO/WgMX15o3by4sWXM/7ECKwv/6PdFc2LisqGYhhJGwZLY0adDWo6
3gbhWTj3fUTSpKgjeCJ0NOgxB77UcqVV1kWv+UIEPTZgHL7H27ebMg/LmjMh
3WNpeVS9ukR5yhwL4NLCLlMVA57LEfQRu6rtiiCwbZPjCeHYvR5A5R+gboR8
E2XpZBqeGSlde/c3Fa5Nk074IwvdoaD+2a7JqM2h1btEho8dHpO2gP5/1b9k
0k8gfaQGSnZ/KrcPD8O7VdI7PFv29bMLC0LtXJQJ2iB6dE8GpVbeT26lP749
Rhv8Vg9vhqP22jegP8USIjeOldzT9qTXVy/46wSrQb2x1yAmJ4QU3dUkM6K7
Pl3C2GQUHgrBwRRqeMeVSnFvf3wypj5WB3t0OxTA4zs0yBlO2tisc1kdi4fs
9RbalSWRV1ExDwkApc1Sd0jNxt9gXiQHXCbysxZtQqbd2bb9rW/yPu2ZvLHF
EwCtRqqyW7ZlbHnuq+CUqbm8/Gpk2lxxU+Y37AeVkJ5dp4WVLhCxl5pppYXx
VkCg/LpJiDH2CiyiM/DBnF5CVHnK2O+L5SBYK7tgbRCiiRiNzNT91q7YNkb0
/frDiK5DxaTcfNDmmEloXYxGp2vz0dvaHRBaAMJDXf1YHunVQCftznfVKTOy
SAdLCiZ6yMcp96k1LPzJj+ldqxB7NaZbkMvQ+h14oDY+F0g1cPeehB2DJ+wG
03MCH8Iu+nszzTYAt1Dr7+UCJBRgGUXbJuWr6/0oUeJD0K9JMO1iPZQXiNlV
OETyxWcn79/fnyb1bxjVsZ0MEyVi3roIn2ZHtndrVX5cNew3uBcbZlncaW2P
/kKLnPuI5SD9ERXSAumWnJFIZc2WorZrAtYQsbyeJE6oBV+nXPFZzs7SerMV
kR+rYWVzSfMIX0OAJr2ZAEGSUm4jM7ZrUhRnJyd9qIQY69tdpr8YUJgrafQv
83K9N/feLiQim/17zLnIKYdbXtBMgWrYfY7xptSDAjBYoOZYR3w8hqE9izyW
IpZ8dLK4+9k6GZVFZebcqviiXH7JlhlzJj9CF8o20IfchSf+F6llGCOcUgAA

-->

</rfc>

