<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category="info" docName="sp-request-reply-01">

  <front>

    <title abbrev="Request/Reply SP">
    Request/Reply Scalability Protocol
    </title>

    <author fullname="Martin Sustrik" initials="M." role="editor"
            surname="Sustrik">
      <address>
        <email>sustrik@250bpm.com</email>
      </address>
    </author>

    <date month="August" year="2013" />

    <area>Applications</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>Request</keyword>
    <keyword>Reply</keyword>
    <keyword>REQ</keyword>
    <keyword>REP</keyword>
    <keyword>stateless</keyword>
    <keyword>service</keyword>
    <keyword>SP</keyword>

    <abstract>
      <t>This document defines a scalability protocol used for distributing
         processing tasks among arbitrary number of stateless processing nodes
         and returning the results of the processing.</t>
    </abstract>

  </front>

  <middle>

    <section title = "Introduction">

      <t>One of the most common problems in distributed applications is how to
         delegate a work to another processing node and get the result back to
         the original node. In other words, the goal is to utilise the CPU
         power of a remote node.</t>

      <t>There's a wide range of RPC systems addressing the problem, however,
         instead of relying on simple RPC algorithm, we will aim at solving a
         more general version of the problem. First, we want to issue processing
         requests from multiple clients, not just a single one. Second, we want
         to distribute the tasks to any number processing nodes instead of a
         single one so that the processing can be scaled up by adding new
         processing nodes as necessary.</t>

      <t>Solving the generalised problem requires that the algorithm
         executing the task in question -- also known as "service" -- is
         stateless.</t>

      <t>To put it simply, the service is called "stateless" when there's no
         way for the user to distinguish whether a request was processed by
         one instance of the service or another one.</t>

      <t>So, for example, a service which accepts two integers and multiplies
         them is stateless. Request for "2x2" is always going to produce "4",
         no matter what instance of the service have computed it.</t>

      <t>Service that accepts empty requests and produces the number
         of requests processed so far (1, 2, 3 etc.), on the other hand, is
         not stateless. To prove it you can run two instances of the service.
         First reply, no matter which instance produces it is going to be 1.
         Second reply though is going to be either 2 (if processed by the same
         instance as the first one) or 1 (if processed by the other instance).
         You can distinguish which instance produced the result. Thus,
         according to the definition, the service is not stateless.</t>

      <t>Despite the name, being "stateless" doesn't mean that the service has
         no state at all. Rather it means that the service doesn't retain any
         business-logic-related state in-between processing two subsequent
         requests. The service is, of course, allowed to have state while
         processing a single request. It can also have state that is unrelated
         to its business logic, say statistics about the processing that are
         used for administrative purposes and never returned to the clients.</t>

      <t>Also note that "stateless" doesn't necessarily mean "fully
         deterministic". For example, a service that generates random numbers is
         non-deterministic. However, the client, after receiving a new random
         number cannot tell which instance has produced it, thus, the service
         can be considered stateless.</t>

      <t>While stateless services are often implemented by passing the entire
         state inside the request, they are not required to do so. Especially
         when the state is large, passing it around in each request may be
         impractical. In such cases, it's typically just a reference to the
         state that's passed in the request, such as ID or path. The state
         itself can then be retrieved by the service from a shared database,
         a network file system or similar storage mechanism.</t>
         
      <t>Requiring services to be stateless serves a specific purpose.
         It allows for using any number of service instances to handle
         the processing load. After all, the client won't be able to tell the
         difference between replies from instance A and replies from instance B.
         You can even start new instances on the fly and get away with it.
         The client still won't be able to tell the difference. In other
         words, statelessness is a prerequisite to make your service cluster
         fully scalable.</t>

      <t>Once it is ensured that the service is stateless there are several
         topologies for a request/reply system to form. What follows are
         the most common:

        <list style = "numbers">
          <t>One client sends a request to one server and gets a reply.
             The common RPC scenario.</t>
          <t>Many clients send requests to one server and get replies. The
             classic client/server model. Think of a database server and
             database clients. Alternatively think of a messaging broker and
             messaging clients.</t>
          <t>One client send requests to many servers and gets replies.
             The load-balancer model. Think of HTTP load balancers.</t>
          <t>Many clients send requests to be processed by many servers.
             The "enterprise service bus" model. In the simplest case the bus
             can be implemented as a simple hub-and-spokes topology. In complex
             cases the bus can span multiple physical locations or multiple
             organisations with intermediate nodes at the boundaries connecting
             different parts of the topology.</t>
        </list>

      </t>

      <t>In addition to distributing tasks to processing nodes, request/reply
         model comes with full end-to-end reliability. The reliability guarantee
         can be defined as follows: As long as the client is alive and there's
         at least one server accessible from the client, the task will
         eventually get processed and the result will be delivered back to
         the client.</t>

      <t>End-to-end reliability is achieved, similar to TCP, by re-sending the
         request if the client believes the original instance of the request
         has failed. Typically, request is believed to have failed when there's
         no reply received within a specified time.</t>

      <t>Note that, unlike with TCP, the reliability algorithm is resistant to
         a server failure. Even if server fails while processing a request, the
         request will be re-sent and eventually processed by a different
         instance of the server.</t>

      <t>As can be seen from the above, one request may be processed multiple
         times. For example, reply may be lost on its way back to the client.
         Client will assume that the request was not processed yet, it will
         resend it and thus cause duplicate execution of the task.</t>

      <t>Some applications may want to prevent duplicate execution of tasks. It
         often turns out that hardening such applications to be idempotent is
         relatively easy as they already possess the tools to do so. For
         example, a payment processing server already has access to a shared
         database which it can use to verify that the payment with specified ID
         was not yet processed.</t>

      <t>On the other hand, many applications don't care about occasional
         duplicate processed tasks. Therefore, request/reply protocol does not
         require the service to be idempotent. Instead, the idempotence issue
         is left to the user to decide on.</t>

      <t>Finally, it should be noted that this specification discusses several
         features that are of little use in simple topologies and are rather
         aimed at large, geographically or organisationally distributed
         topologies. Features like channel prioritisation and loop avoidance
         fall into this category.</t>

    </section>

    <section title = "Underlying protocol">

      <t>The request/reply protocol can be run on top of any SP mapping,
         such as, for example, <xref target='SPoverTCP'>SP TCPmapping</xref>.
         </t>

      <t>Also, given that SP protocols describe the behaviour of entire
         arbitrarily complex topology rather than of a single node-to-node
         communication, several underlying protocols can be used in parallel.
         For example, a client may send a request via WebSocket, then, on the
         edge of the company network an intermediary node may retransmit it
         using TCP etc.</t>

      <figure>
        <artwork>
+---+  WebSocket  +---+    TCP    +---+
|   |-------------|   |-----------|   |
+---+             +---+           +---+
                   | |
     +---+   IPC   | |  SCTP  +---+    DCCP   +---+
     |   |---------+ +--------|   |-----------|   |
     +---+                    +---+           +---+
        </artwork>
      </figure>

    </section>

    <section title = "Overview of the algorithm">

      <t>Request/reply protocol defines two different endpoint types:
         The requester or REQ (the client) and the replier or REP (the
         service).</t>

      <t>REQ endpoint can be connected only to a REP endpoint. REP endpoint
         can be connected only to the REQ endpoint. If the underlying protocol
         indicates that there's an attempt to create a channel to an
         incompatible endpoint, the channel MUST NOT be used. In the case of
         TCP mapping, for example, the underlying TCP connection MUST
         be closed.</t>

      <t>When creating more complex topologies, REQ and REP endpoints are
         paired in the intermediate nodes to form a forwarding component,
         so called "device". Device receives requests from the REP endpoint
         and forwards them to the REQ endpoint. At the same time it receives
         replies from the REQ endpoint and forwards them to the REP
         endpoint:</t>

      <figure>
        <artwork>
                --- requests --&gt;

+-----+   +-----+-----+   +-----+-----+   +-----+
|     |--&gt;|     |     |--&gt;|     |     |--&gt;|     |
| REQ |   | REP | REQ |   | REP | REQ |   | REP |
|     |&lt;--|     |     |&lt;--|     |     |&lt;--|     |
+-----+   +-----+-----+   +-----+-----+   +-----+

                &lt;-- replies ---
        </artwork>
      </figure>

      <t>Using devices, arbitrary complex topologies can be built. The rest
         of this section explains how are the requests routed through a topology
         towards processing nodes and how are replies routed back from
         processing nodes to the original clients, as well as how the
         reliability is achieved.</t>

      <t>The idea for routing requests is to implement a simple coarse-grained
         scheduling algorithm based on pushback capabilities of the underlying
         transport.</t>

      <t>The algorithm works by interpreting pushback on a particular channel
         as "the part of topology accessible through this channel is busy at
         the moment and doesn't accept any more requests."</t>

      <t>Thus, when a node is about to send a request, it can choose to send
         it only to one of the channels that don't report pushback at the
         moment. To implement approximately fair distribution of the workload
         the node choses a channel from that pool using the round-robin
         algorithm.</t>

      <t>As for delivering replies back to the clients, it should be understood
         that the client may not be directly accessible (say using TCP/IP) from
         the processing node. It may be beyond a firewall, have no static IP
         address etc. Furthermore, the client and the processing may not even
         speak the same transport protocol -- imagine client connecting to the
         topology using WebSockets and processing node via SCTP.</t>

      <t>Given the above, it becomes obvious that the replies must be routed
         back through the existing topology rather than directly. In fact,
         request/reply topology may be thought of as an overlay network on the
         top of underlying transport mechanisms.</t>

      <t>As for routing replies within the request/topology, it is designed in
         such a way that each reply contains the whole routing path, rather
         than containing just the address of destination node, as is the case
         with, for example, TCP/IP.</t>

      <t>The downside of the design is that replies are a little bit longer
         and that is in intermediate node gets restarted, all the requests
         that were routed through it will fail to complete and will have to be
         resent by request/reply end-to-end reliability mechanism.</t>

      <t>The upside, on the other hand, is that the nodes in the topology don't
         have to maintain any routing tables beside the simple table of
         adjacent channels along with their IDs. There's also no need for any
         additional protocols for distributing routing information within
         the topology.</t>

      <t>The most important reason for adopting the design though is that
         there's no propagation delay and any nodes becomes accessible
         immediately after it is started. Given that some nodes in the topology
         may be extremely short-lived this is a crucial requirement. Imagine
         a database client that sends a query, reads the result and terminates.
         It makes no sense to delay the whole process until the routing tables
         are synchronised between the client and the server.</t>

      <t>The algorithm thus works as follows: When request is routed from the
         client to the processing node, every REP endpoint determines which
         channel it was received from and adds the ID of the channel to the
         request. Thus, when the request arrives at the ultimate processing node
         it already contains a full backtrace stack, which in turn contains
         all the info needed to route a message back to the original client.</t>

      <t>After processing the request, the processing node attaches the
         backtrace stack from the request to the reply and sends it back
         to the topology. At that point every REP endpoint can check the
         traceback and determine which channel it should send the reply to.</t>

      <t>In addition to routing, request/reply protocol takes care of
         reliability, i.e. ensures that every request will be eventually
         processed and the reply will be delivered to the user, even when
         facing failures of processing nodes, intermediate nodes and network
         infrastructure.</t>

      <t>Reliability is achieved by simply re-sending the request, if the reply
         is not received with a certain timeframe. To make that algorithm
         work flawlessly, the client has to be able to filter out any stray
         replies (delayed replies for the requests that we've already received
         reply to).</t>

      <t>The client thus adds an unique request ID to the request. The ID gets
         copied from the request to the reply by the processing node. When the
         reply gets back to the client, it can simply check whether the request
         in question is still being processed and if not so, it can ignore
         the reply.</t>

      <t>To implement all the functionality described above, messages (both
         requests and replies have the following format:</t>

      <figure>
        <artwork>
+-+------------+-+------------+   +-+------------+-------------+
|0| Channel ID |0| Channel ID |...|1| Request ID |   payload   |
+-+------------+-+------------+   +-+------------+ ------------+
        </artwork>
      </figure>

      <t>Payload of the message is preceded by a stack of 32-bit tags. The most
         significant bit of each tag is set to 0 except for the very last tag.
         That allows the algorithm to find out where the tags end and where
         the message payload begins.</t>

      <t>As for the remaining 31 bits, they are either request ID (in the last
         tag) or a channel ID (in all the remaining tags). The first channel ID
         is added and processed by the REP endpoint closest to the processing
         node. The last channel ID is added and processed by the REP endpoint
         closest to the client.</t>

      <t>Following picture shows an example of request saying "Hello" being
         routed from the client through two intermediate nodes to the
         processing node and the reply "World" being routed back. It shows
         what messages are passed over the network at each step of the
         process:</t>

      <figure>
        <artwork>
                        client
                  Hello    |    World
                   |    +-----+    ^
                   |    | REQ |    |
                   V    +-----+    |
            1|823|Hello    |    1|823|World
                   |    +-----+    ^
                   |    | REP |    |
                   |    +-----+    |
                   |    | REQ |    |
                   V    +-----+    |
      0|299|1|823|Hello    |    0|299|1|823|World
                   |    +-----+    ^
                   |    | REP |    |
                   |    +-----+    |
                   |    | REQ |    |
                   V    +-----+    |
0|446|0|299|1|823|Hello    |    0|446|0|299|1|823|World
                   |    +-----+    ^
                   |    | REP |    |
                   V    +-----+    |
                  Hello    |    World
                        service
        </artwork>
      </figure>

    </section>

    <section title = "Hop-by-hop vs. End-to-end">

      <t>All endpoints implement so called "hop-by-hop" functionality. It's
         the functionality concerned with sending messages to the immediately
         adjacent components and receiving messages from them.</t>

      <t>In addition to that, the endpoints on the edge of the topology
         implement so called "end-to-end" functionality that is concerned
         with issues such as, for example, reliability.</t>

      <figure>
        <artwork>
                   end to end
   +-----------------------------------------+
   |                                         |
+-----+   +-----+-----+   +-----+-----+   +-----+
|     |--&gt;|     |     |--&gt;|     |     |--&gt;|     |
| REQ |   | REP | REQ |   | REP | REQ |   | REP |
|     |&lt;--|     |     |&lt;--|     |     |&lt;--|     |
+-----+   +-----+-----+   +-----+-----+   +-----+
   |         |     |         |     |         |
   +---------+     +---------+     +---------+
   hop by hop      hop by hop      hop by hop
        </artwork>
      </figure>

      <t>To make an analogy with the TCP/IP stack, IP provides hop-by-hop
         functionality, i.e. routing of the packets to the adjacent node,
         while TCP implements end-to-end functionality such resending of
         lost packets.</t>

      <t>As a rule of thumb, raw hop-by-hop endpoints are used to build
         devices (intermediary nodes in the topology) while end-to-end
         endpoints are used directly by the applications.</t>

      <t>To prevent confusion, the specification of the endpoint behaviour
         below will discuss hop-by-hop and end end-to-end functionality in
         separate chapters.</t>

    </section>

    <section title = "Hop-by-hop functionality">

      <section title = "REQ endpoint">

        <t>The REQ endpoint is used by the user to send requests to the
           processing nodes and receive the replies afterwards.</t>

        <t>When user asks REQ endpoint to send a request, the endpoint should
           send it to one of the associated outbound channels (TCP connections
           or similar). The request sent is exactly the message supplied by
           the user. REQ socket MUST NOT modify an outgoing request in any
           way.</t>

        <t>If there's no channel to send the request to, the endpoint won't send
           the request and MUST report the backpressure condition to the user.
           For example, with BSD socket API, backpressure is reported as EAGAIN
           error.</t>

        <t>If there are associated channels but none of them is available for
           sending, i.e. all of them are already reporting backpressure, the
           endpoint won't send the message and MUST report the backpressure
           condition to the user.</t>

        <t>Backpressure is used as a means to redirect the requests from the
           congested parts of the topology to to the parts that are still
           responsive. It can be thought of as a crude scheduling algorithm.
           However crude though, it's probably still the  best you can get
           without knowing estimates of execution time for individual tasks,
           CPU capacity of individual processing nodes etc.</t>

        <t>Alternatively, backpressure can be thought of as a congestion control
           mechanism. When all available processing nodes are busy, it slows
           down the client application, i.e. it prevents the user from sending
           any more requests.</t>

        <t>If the channel is not capable of reporting backpressure (e.g. DCCP)
           the endpoint SHOULD consider it as always available for sending new
           request. However, such channels should be used with care as when the
           congestion hits they may suck in a lot of requests just to discard
           them silently and thus cause re-transmission storms later on. The
           implementation of the REQ endpoint MAY choose to prohibit the use
           of such channels altogether.</t>

        <t>When there are multiple channels available for sending the request
           endpoint MAY use any prioritisation mechanism to decide which channel
           to send the request to. For example, it may use classic priorities
           attached to channels and send message to the channel with the highest
           priority. That allows for routing algorithms such as: "Use local
           processing nodes if any are available. Send the requests to remote
           nodes only if there are no local ones available." Alternatively,
           the endpoint may implement weighted priorities ("send 20% of the
           request to node A and 80% to node B). The endpoint also may not
           implement any prioritisation strategy and treat all channels as
           equal.</t>

        <t>Whatever the case, two rules must apply.</t>

        <t>First, by default the priority settings for all channels MUST be
           equal. Creating a channel with different priority MUST be triggered
           by an explicit action by the user.</t>

        <t>Second, if there are several channels with equal priority, the
           endpoint MUST distribute the messages among them in fair fashion
           using round-robin algorithm. The round-robin implementation MUST also
           take care not to become unfair when new channels are added or old
           ones are removed on the fly.</t>

        <t>As for incoming messages, i.e. replies, REQ endpoint MUST fair-queues
           them. In other words, if there are replies available on several
           channels, it MUST receive them in a round-robin fashion. It must also
           take care not to compromise the fairness when new channels are
           added or old ones removed.</t>

        <t>In addition to providing basic fairness, the goal of fair-queueing is
           to prevent DoS attacks where a huge stream of fake replies from one
           channel would be able to block the real replies coming from different
           channels. Fair queueing ensures that messages from every channel are
           received at approximately the same rate. That way, DoS attack can
           slow down the system but it can't entirely block it.</t>

        <t>Incoming replies MUST be handed to the user exactly as they were
           received. REQ endpoint MUST not modify the replies in any way.</t>

      </section>

      <section title = "REP endpoint">

        <t>REP endpoint is used to receive requests from the clients and send
           replies back to the clients.</t>

        <t>First of all, REP socket is responsible for assigning unique 31-bit
           channel IDs to the individual associated channels.</t>

        <t>First ID assigned MUST be random. Next is computed by adding 1 to
           the previous one with potential overflow to 0.</t>

        <t>The implementation MUST ensure that the random number is different
           each time the endpoint is re-started, the process that contains
           it is restarted or similar. So, for example, using pseudo-random
           generator with a constant seed won't do.</t>

        <t>The goal of the algorithm is to the spread of possible channel ID
           values and thus minimise the chance that a reply is routed to an
           unrelated channel, even in the face of intermediate node
           failures.</t>

        <t>When receiving a message, REP endpoint MUST fair-queue among the
           channels available for receiving. In other words it should
           round-robin among such channels and receive one request from
           a channel at a time. It MUST also implement the round-robin
           algorithm is such a way that adding or removing channels don't
           break its fairness.</t>

        <t>In addition to guaranteeing basic fairness in access to computing
           resources the above algorithm makes it impossible for a malevolent
           or misbehaving client to completely block the processing of requests
           from other clients by issuing steady stream of requests.</t>

        <t>After getting hold on the request, the REP socket should prepend it
           by 32 bit value, consisting of 1 bit set to 0 followed by the 31-bit
           ID of the channel the request was received from. The extended request
           will be then handed to the user.</t>

        <t>The goal of adding the channel ID to the request is to be able to
           route the reply back to the original channel later on. Thus, when
           the user sends a reply, endpoint strips first 32 bits off and uses
           the value to determine where it is to be routed.</t>

        <t>If the reply is shorter than 32 bits, it is malformed and
           the endpoint MUST ignore it. Also, if the most relevant bit of the
           32-bit value isn't set to 0, the reply is malformed and MUST
           be ignored.</t>

        <t>Otherwise, the endpoint checks whether its table of associated
           channels contains the channel with a corresponding ID. If so, it
           sends the reply (with first 32 bits stripped off) to that channel.
           If the channel is not found, the reply MUST be dropped. If the
           channel is not available for sending, i.e. it is applying
           backpressure, the reply MUST be dropped.</t>

        <t>Note that when the reply is unroutable two things might have
           happened. Either there was some kind of network disruption, in which
           case the request will be re-sent later on, or the original client
           have failed or been shut down. In such case the request won't be
           resent, however, it doesn't really matter because there's no one to
           deliver the reply to any more anyway.</t>

        <t>Unlike requests, there's no pushback applied to the replies; they are
           simply dropped. If the endpoint blocked and waited for the channel to
           become available, all the subsequent replies, possibly destined for
           different unblocked channels, would be blocked in the meantime. That
           allows for a DoS attack simply by firing a lot of requests and not
           receiving the replies.</t>

      </section>
   
    </section>

    <section title = "End-to-end functionality">

      <t>End-to-end functionality is built on top of hop-to-hop functionality.
         Thus, an endpoint on the edge of a topology contains all the
         hop-by-hop functionality, but also implements additional
         functionality of its own. This end-to-end functionality acts
         basically as a user of the underlying hop-by-hop functionality.</t>

      <section title = "REQ endpoint">

        <t>End-to-end functionality for REQ sockets is concerned with re-sending
           the requests in case of failure and with filtering out stray or
           outdated replies.</t>

        <t>To be able to do the latter, the endpoint must tag the requests with
           unique 31-bit request IDs. First request ID is picked at random. All
           subsequent request IDs are generated by adding 1 to the last request
           ID and possibly overflowing to 0.</t>

        <t>To improve robustness of the system, the implementation MUST ensure
           that the random number is different each time the endpoint, the
           process or the machine is restarted. Pseudo-random generator with
           fixed seed won't do.</t>

        <t>When user asks the endpoint to send a message, the endpoint prepends
           a 32-bit value to the message, consisting of a single bit set to 1
           followed by a 31-bit request ID and passes it on in a standard
           hop-by-hop way.</t>

        <t>If the hop-by-hop layer reports pushback condition, the end-to-end
           layer considers the request unsent and MUST report pushback condition
           to the user.</t>

        <t>If the request is successfully sent, the endpoint stores the request
           including its request ID, so that it can be resent later on if
           needed. At the same time it sets up a timer to trigger the
           re-transmission in case the reply is not received within a specified
           timeout. The user MUST be allowed to specify the timeout interval.
           The default timeout interval must be 60 seconds.</t>

        <t>When a reply is received from the underlying hop-by-hop
           implementation, the endpoint should strip off first 32 bits from
           the reply to check whether it is a valid reply.</t>

        <t>If the reply is shorter than 32 bits, it is malformed and the
           endpoint MUST ignore it. If the most significant bit of the 32-bit
           value is set to 0, the reply is malformed and MUST be ignored.</t>

        <t>Otherwise, the endpoint should check whether the request ID in
           the reply matches any of the request IDs of the requests being
           processed at the moment. If not so, the reply MUST be ignored.
           It is either a stray message or a duplicate reply.</t>

        <t>Please note that the endpoint can support either one or more
           requests being processed in parallel. Which one is the case depends
           on the API exposed to the user and is not part of this
           specification.</t>

        <t>If the ID in the reply matches one of the requests in progress, the
           reply MUST be passed to the user (with the 32-bit prefix stripped
           off). At the same time the stored copy of the original request as
           well as re-transmission timer must be deallocated.</t>

        <t>Finally, REQ endpoint MUST make it possible for the user to cancel
           a particular request in progress. What it means technically is
           deleting the stored copy of the request and cancelling the associated
           timer. Thus, once the reply arrives, it will be discarded by the
           algorithm above.</t>

        <t>The cancellation allows, for example, the user to time out a request.
           They can simply post a request and if there's no answer in specific
           timeframe, they can cancel it.</t>

      </section>

      <section title = "REP endpoint">

        <t>End-to-end functionality for REP endpoints is concerned with turning
           requests into corresponding replies.</t>

        <t>When user asks to receive a request, the endpoint gets next request
           from the hop-by-hop layer and splits it into the traceback stack and
           the message payload itself. The traceback stack is stored and the
           payload is returned to the user.</t>

        <t>The algorithm for splitting the request is as follows: Strip 32 bit
           tags from the message in one-by-one manner. Once the most significant
           bit of the tag is set, we've reached the bottom of the traceback
           stack and the splitting is done. If the end of the message is reached
           without finding the bottom of the stack, the request is malformed and
           MUST be ignored.</t>

        <t>Note that the payload produced by this procedure is the same as the
           request payload sent by the original client.</t>

        <t>Once the user processes the request and sends the reply, the endpoint
           prepends the reply with the stored traceback stack and sends it on
           using the hop-by-hop layer. At that point the stored traceback stack
           MUST be deallocated.</t>

        <t>Additionally, REP endpoint MUST support cancelling any request being
           processed at the moment. What it means, technically, is that
           state associated with the request, i.e. the traceback stack stored
           by the endpoint is deleted and reply to that particular
           request is never sent.</t>

        <t>The most important use of cancellation is allowing the service
           instances to ignore malformed requests. If the application-level
           part of the request doesn't conform to the application protocol
           the service can simply cancel the request. In such case the reply
           is never sent. Of course, if application wants to send an
           application-specific error massage back to the client it can do so
           by not cancelling the request and sending a regular reply.</t>

      </section>

    </section>

    <section title = "Loop avoidance">

      <t>It may happen that a request/reply topology contains a loop. It becomes
         increasingly likely as the topology grows out of scope of a single
         organisation and there are multiple administrators involved
         in maintaining it. Unfortunate interaction between two perfectly
         legitimate setups can cause loop to be created.</t>

      <t>With no additional guards against the loops, it's likely that
         requests will be caught inside the loop, rotating there forever,
         each message gradually growing in size as new prefixes are added to it
         by each REP endpoint on the way. Eventually, a loop can cause
         congestion and bring the whole system to a halt.</t>

      <t>To deal with the problem REQ endpoints MUST check the depth of the
         traceback stack for every outgoing request and discard any requests
         where it exceeds certain threshold. The threshold should be defined
         by the user. The default value is suggested to be 8.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>New SP endpoint types REQ and REP should be registered by IANA. For
         now, value of 16 should be used for REQ endpoints and value of 17 for
         REP endpoints.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mapping is not intended to provide any additional security to the
         underlying protocol. DoS concerns are addressed within
         the specification.</t>
    </section>

  </middle>

  <back>
    <references>
      <reference anchor='SPoverTCP'>
         <front>
           <title>TCP mapping for SPs</title>
           <author initials='M.' surname='Sustrik' fullname='M. Sustrik'/>
           <date month='August' year='2013'/>
         </front>
         <format type='TXT' target='sp-tcp-mapping-01.txt'/>
       </reference>
    </references>
  </back>

</rfc>