idnits 2.17.1 draft-iyengar-minion-concept-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Iyengar 3 Internet-Draft Franklin and Marshall College 4 Intended status: Standards Track S. Cheshire 5 Expires: April 24, 2014 J. Graessley 6 Apple 7 October 21, 2013 9 Minion - Service Model and Conceptual API 10 draft-iyengar-minion-concept-02 12 Abstract 14 Minion uses TCP-format packets on-the-wire, to provide full 15 compatibility with existing NATs, Firewalls, and similar middleboxes, 16 but provides a richer set of facilities to the application. Minion's 17 richer facilities include a message-oriented API rather than TCP's 18 unstructured byte-stream service model, multiplexing of multiple 19 messages (or message streams) on a single connection, interleaving of 20 multiplexed messages (to eliminate head-of-line blocking), message 21 cancellation, request/reply support, ordered and unordered messages, 22 superseding messages, chained messages, multiple priority levels with 23 byte-granularity preemption, and DTLS Security. Minion can be 24 implemented entirely as a user-level library, without waiting for any 25 special support from OS vendors, and provides immediate benefits to 26 application developers. Additionally, Minion is able to take 27 advantage of some simple kernel extensions to provide enhanced 28 services that go beyond what is possible with traditional TCP. These 29 kernel extensions are optional, and even without them, Minion offers 30 worthwhile benefits to application developers. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 24, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 1. Conventions and Terminology Used in this Document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 68 "OPTIONAL" in this document are to be interpreted as described in 69 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 71 2. Introduction 73 Back in 1983 application developers had the choice of UDP [RFC0768] 74 or TCP [RFC0793]. UDP preserves message boundaries, but provides no 75 reliability, ordering, flow control, or congestion control, and only 76 supports small messages (typically UDP packets larger than 1468 bytes 77 result in undesirable IP fragmentation). TCP provides these 78 important facilities, and doesn't impose any message size limit -- 79 but only because it doesn't have any concept of messages, and doesn't 80 claim to preserve message boundaries. Consequently, whichever base 81 protocol the application developer chose, they were left building 82 part of the transport-layer solution themselves. 84 Thirty years later, in 2013, little has changed. Application 85 developers on mainstream platforms like Android and iOS still have 86 the same two choices -- UDP and TCP. 88 Attempts to provide richer application facilities have failed to 89 achieve widespread adoption. Protocols like SCTP are not supported 90 by mainstream NAT gateways. Consequently, mainstream apps for 91 platforms like Android and iOS don't use SCTP, because it would 92 severely limit their real-world deployment. Consequently, operating 93 systems like Android and iOS don't have in-kernel native 94 implementations of SCTP, because there's little developer demand for 95 a protocol they can't use. Consequently, there's little incentive 96 for NAT gateway vendors to do the work to add support for a protocol 97 that's neither supported in the popular operating systems nor used by 98 mainstream applications. 100 Like SCTP, Minion goes beyond UDP and TCP by providing richer 101 application facilities, making it possible to create applications 102 that work better and more reliably (and can be brought to market 103 quicker and easier) than is possible when each application has to re- 104 create those facilities from scratch every time. 106 However, unlike SCTP, Minion provides facilities that can be used by 107 an application developer immediately, without having to wait for OS 108 support or NAT gateway support. OS support and NAT gateway support 109 can come later, and provide additional incremental improvements. 110 This incremental deployment path -- which begins first with the 111 application developer who can choose to use Minion and immediately 112 reap the benefits of that decision -- is an important property of 113 Minion, and removes one of the major obstacles that hindered SCTP 114 adoption. 116 When used without kernel support, Minion acts like a typical TCP- 117 based application protocol, and as such, performs as well as any 118 other TCP-based application protocol. However, unlike most 119 application-specific protocols, Minion also offers the potential of 120 kernel support giving better low-latency message performance and 121 better prioritization. A general application protocol is unlikely to 122 receive special-case kernel support tailored to support that one 123 specific application, but as a general-purpose transport protocol 124 built to support a wide range of applications, special kernel support 125 for Minion is feasible. 127 Minion preserves the important properties of TCP, like congestion 128 control, while adding a range of richer application facilities: 130 Message Oriented 131 Rather than an unstructured byte stream, Minion supports messages. 132 TCP provides an unstructured byte stream, but virtually every 133 application needs to send and receive semantic messages, which 134 means that virtually every application needs to build its own 135 message framing mechanism on top of TCP. In contrast, Minion 136 respects and preserves semantic boundaries. If an application 137 writes a 27-byte message followed by a 53-byte message, then a 27- 138 byte message and a 53-byte message are delivered to the receiving 139 client, not a single combined block of 80 bytes. 141 Arbitrary Size Messages 142 While most Minion messages are expected to be small, Minion itself 143 imposes no upper limit on message size. For example, a 6 gigabyte 144 movie download could be sent as a single Minion message. Messages 145 do not have to fit in memory. A very large message can be 146 generated incrementally by the sender, and will be delivered 147 incrementally to the receiver. 149 Multiplexing 150 Multiple messages can be sent, in both directions, on a single 151 Minion connection. Unlike protocols like HTTP/1.0 where each 152 request used a separate connection, many Minion messages can share 153 a connection. 155 Interleaving 156 When multiple (possibly large) messages are being sent 157 concurrently on a single Minion connection, the connection 158 bandwidth is shared round-robin between the messages. This avoids 159 head-of-line blocking, where messages are blocked waiting for a 160 large message to complete. 162 Cancellation 163 Messages do not have to be sent to completion. If either the 164 sender or the receiver determines that a message is no longer 165 needed, then that single message can be cancelled without having 166 to tear down the entire Minion connection. 168 Unordered Messages 169 One of the main arguments that is often presented to justify why a 170 particular application protocol is built on UDP instead of TCP is 171 that, "UDP is better for 'real time' applications." The 172 supporting reasoning for this is often that, "TCP insists on 173 continuing to retransmit data long after the client doesn't need 174 any more." In truth the real problem is not retransmission; it is 175 that the conventional TCP APIs don't allow received data to be 176 delivered out of order. Suppose a TCP sender has 50 packets in 177 flight at any given time (e.g. the bandwidth x delay product is 75 178 kB) then the loss of a single packet causes all 49 following 179 packets to stall at the receiver because the API doesn't allow for 180 them to be delivered to the client until the missing packet has 181 been received. A simple kernel extension (in the form of a new 182 socket option) removes this limitation, and allows out-of-order 183 data to be delivered to the client. This avoids the problem where 184 a single lost TCP segment causes all the following TCP segments to 185 be delayed. 187 Note that this kernel extension is not *required* for a client to 188 use Minion; it is an optional extension that provides better 189 performance for real-time applications in situations where there 190 is packet loss or reordering. For many applications it is an 191 irrelevant benefit and they can operate perfectly well without it. 192 For a few applications it is a significant benefit, and it allows 193 Minion to provide the low-latency performance that often drives 194 developers to use UDP. 196 Sender Ordering 197 While out-of-order data can be useful, there are are also many 198 cases where there is a logical order to send the data. For 199 example, H.264 video P-frames may not strictly depend upon each 200 other for decoding, but there is still a logical order to send 201 them. It makes sense for earlier frames to be sent sooner than 202 later frames. Therefore, delivering all frames concurrently, 203 sharing the available bandwidth fairly, may cause the first frame 204 to be delivered unecessarily late, and the last frame to be 205 delivered unecessarily early. Respecting the natural order of the 206 frames makes sense. However, in the event of packet loss that 207 delays a particular frame beyond its playback time, there is no 208 reason to artificially delay delivery of later frames that have 209 already been received. For data of this kind, the sender uses 210 Sender Ordering to indicate that a particular message should 211 follow another message on the wire. 213 Receiver Ordering 214 There are cases where the delivery ordering requirements are 215 stricter than merely expressing a preference about transmission 216 order. In some cases the receiver cannot usefully use (certain) 217 messages out of order, and delivering them potentially out of 218 order would burden the application with the task of sorting the 219 messages back into the correct order before processing them. In 220 such cases, it is more convenient for the application to have 221 Minion deliver messages to it in the right order. For this reason 222 Minion supports receiver-ordered messages as well as sender- 223 ordered and unordered messages. Unordered messages and ordered 224 messages are supported simultaneously on a single Minion 225 connection. 227 Other transport protocols support the notion of multiple message 228 streams sharing a single connection. Minion takes this idea and 229 generalizes it to the more expressive notion of Receiver Ordering 230 Message Dependencies. Receiver Ordering Message Dependencies 231 indicate that a dependent message must not be delivered before the 232 message it depends upon. 234 Traditional message streams can be created in Minion by using a 235 sequence of Receiver Ordering Message Dependencies: If message B 236 is specified to follow message A, and message C is specified to 237 follow message B, and so on, then messages A,B,C... form an 238 ordered "stream". Similarly, if at the same time message Q is 239 specified to follow message P, and message R is specified to 240 follow message Q, and so on, then messages P,Q,R... form another 241 independent ordered "stream" of their own. 243 In addition to such disjoint ordered streams (A,B,C... and 244 P,Q,R...), Receiver Ordering Message Dependencies also allow 245 richer relationships to be expressed. For example, in H.264 246 video, P-frames reference I-frames, but P-frames do not reference 247 other P-frames. If a single P-frame is lost or delayed, it is not 248 necessary to delay all subsequent P-frames. Each P-frame has a 249 time it is due to be displayed, and when that time arrives the 250 frame should be displayed if possible, even if (or especially if) 251 preceding P-frames did not arrive in time. However, there is no 252 benefit in delivering a P-frame to the application before the 253 I-frame it depends upon. 255 To give another example, a web browser client may need to retrieve 256 many resources to display a page, but it cannot display *any* of 257 the page until it has received the style sheet. Consequently it 258 would be beneficial if the web browser client could request all of 259 the resources it needs, but for each one, indicate that it depends 260 on the style sheet resource (or upon some other resource which 261 depends by transitive closure on the sheet resource). This 262 dependency information tells the sender that it should not devote 263 *any* bytes of available bandwidth to delivering other resources 264 until after it has completed sending the all-important style 265 sheet. 267 Superseding Messages 268 Similar to Receiver Ordered Messages are Superseding Messages. 269 Where a Receiver Ordered Message follows its predecessor, a 270 Superseding Message follows its predecessor *and renders it 271 irrelevant*. For example, in a real-time video game, a message 272 giving the player's current position supersedes any previous 273 message giving a previous position. Generally, old position data 274 becomes irrelevant when newer position data is available. 275 Messages of this kind are specified to be Superseding Messages. 276 On the sending side, if Message B is specified to supersede 277 Message A, and Message A has not yet been sent, then Message A is 278 discarded without being sent. This avoids wasting network 279 capacity sending obsolete data. If Message A has been sent, but 280 (due to packet loss or reordering) arrives at the receiver after 281 Message B, then the receiver discards the late-arriving message A 282 without delivering it to the client. This avoids delivering data 283 to the application in the wrong order. The Superseding Message 284 mechanism allows client application code to specify that a certain 285 group of messages have a specified delivery order, without 286 delaying later messages in the event that a prior message has not 287 yet arrived. 289 Chained Messages 290 Minion is intended to be used to deliver messages containing a 291 single logical semantic unit. Although Minion can "stream" a 292 message of unbounded size to the receiver, Minion is not generally 293 intended to be used to batch multiple logical semantic units into 294 single large message, which is then "streamed" to the receiver, 295 which then parses the incoming "streamed" message as it arrives 296 for the logical semantic units contained within it. Part of the 297 purpose of Minion is to take the burden of message framing off the 298 application writer; treating a single unbounded "streaming" Minion 299 message like a TCP connection places the burden of parsing firmly 300 back in the hands of the application developer. 302 In the event that a logical message contains multiple related 303 parts, like a header with an associated body, Minion can 304 facilitate this structuring through the use of Chained Messages. 306 Chained Messages are substantially similar to Receiver Ordering 307 Message Dependencies, except that in addition to controlling the 308 order of data transmission on the wire, and the order of message 309 delivery to the client, the chained message relationship is also 310 exposed to the client application at the receiving end. Instead 311 of being delivered to the Minion connection's main message handler 312 function, the way most messages are, Chained Messages are 313 delivered instead to the Chained Message handler function of the 314 previous message in the chain. 316 The Chained Message mechanism allows an application to provide a 317 main message handler function that receives and processes the 318 "header" portion of each two-part message, and that main message 319 handler function in turn provides a different message handler 320 function that receives and processes the subsequent "body" 321 portion. 323 As with other messages, each component in a message chain can 324 optionally generate an explicit reply, which is delivered to the 325 reply handler for the specific message in the chain that elicited 326 the reply. 328 If any message in a chain is cancelled by the sender or the 329 receiver, then all subsequent messages in that chain are 330 implicitly cancelled. 332 The sender of a chain of messages may wait at each step for a 333 reply confirming that the previous message was acceptable before 334 sending the next message of the chain, or it may send the entire 335 chain and let the receiver cancel the message chain if an error 336 occurs. 338 Request/Reply Support 339 Many application protocols are request/reply-oriented. Minion 340 facilitates this by allowing an outgoing message to be explicitly 341 identified as a reply to a previously-received message, which 342 causes the reply message to be delivered automatically to the 343 appropriate message handler at the receiving end. 345 When a message has a reply handler, the remote peer is expected to 346 generate exactly one reply for this message. If the remote peer 347 does not, that is a client programming bug. This is because the 348 outbound message ID is reserved until one reply is received, then 349 discarded. If no reply is received, the ID will remain active 350 indefinitely. If a reply is sent for a message that does not have 351 a reply handler (or, for a message that does have a reply handler, 352 more than one reply is sent) then that is also a client 353 programming bug. If this happens then an error message SHOULD be 354 logged (to facilitate debugging) and the message MUST NOT be 355 delivered to the client application (e.g. reply messages that do 356 not match any current active message ID MUST NOT be delivered to 357 the connection's default message handler instead). 359 When a client application generates a reply to a received Minion 360 message, the reply inherits the ordering properties of the message 361 to which it replies. 363 If a request message was unordered, then its reply is unordered. 365 If a request message B was declared to have a Sender Ordering 366 contstraint that it follow message A on the wire, then its reply 367 message B' automatically inherits the Sender Ordering contstraint 368 that it follow reply message A' on the wire. In the event that 369 message A does not generate an actual reply A', before reply 370 message B' will be eligible for sending, the client application 371 must signal via some other API mechanism (e.g. by disposing of the 372 message object) that it has finished handling message A. 374 If a request message B was declared to have a Receiver Ordering 375 contstraint that it be delivered after message A, then its reply 376 message B' automatically inherits the Receiver Ordering 377 contstraint that it must be delivered after reply message A'. 379 If a request message B was declared to be a Chained Message 380 following message A, then its reply message B' becomes a Receiver 381 Ordering message that must be delivered after reply message A'. 383 Subject to the Sender Ordering and Receiver Ordering constraints, 384 replies can be interleaved and share bandwidth just as other 385 messages do. 387 Replies can themselves generate further replies, resulting in an 388 unbounded back-and-forth of ping-pong messages, each going to the 389 appropriate reply handler on the receiving side. 391 Priority Levels 392 While Sender Ordering, Receiver Ordering, Superseding Messages, 393 and Message Chaining allow relationships between messages to be 394 adequately expressed where they are known in advance, sometimes 395 there are urgent messages that need to be sent at short notice 396 that are not known in advance. For example, consider a music 397 application which is streaming out audio data with a generous 398 playback buffer, and then the user performs a user-interface 399 operation to change the volume level. We would like this volume 400 change to be performed as promptly as possible, regardless of how 401 much audio data is queued up in the transmit buffer. For this 402 reason Minion supports four priority levels. A higher-priority 403 message can preempt a lower-priority message at any arbitrary byte 404 boundary in the lower-priority data stream. (This byte- 405 granularity preemption is made possible by the Minion wire 406 protocol [minprot]). 408 Minion provides strict priorities, meaning that no lower-priority 409 data at all is sent as long as there is higher-priority data 410 waiting. This means that a sustained flow of higher-priority data 411 can starve lower-priority data indefinitely. For this reason, 412 Minion priorities are intended to support small amounts of high- 413 priority data intermixed with larger amounts of lower-priority 414 data. If the amount of high-priority data exceeds the current 415 throughput of the Minion connection then all the available 416 throughput will be consumed attempting to meet the high-priority 417 data demand, and no lower-priority data will be sent. If this 418 outcome is undesirable to the application, it should ensure that 419 it does not generate sustained high-priority data at a rate 420 exceeding the network throughput for a prolonged period of time. 421 Minion does not attempt to provide proportional or weighted 422 bandwidth allocation between different priority levels. 424 The Minion model is that if message B has a Receiver Ordering or 425 Sender Ordering dependency upon message A, then Minion should not 426 expend any available throughput delivering any part of message B 427 until after message A has been entirely sent. Similarly, if 428 message C is higher priority than messages A and B, then Minion 429 should not expend any available throughput delivering any part of 430 messages A or B until after message C has been entirely sent. 432 Because of the strict priority policy, a Minion message may have a 433 Receiver Ordering or Sender Ordering dependency on another message 434 of equal or higher priority, but not on a message of lower 435 priority. 437 The priority of a Minion message cannot be changed mid- 438 transmission. 440 DTLS Security 441 Minion includes security support. Because of the potential for 442 out-of-order message reception, Minion uses DTLS (which includes 443 an explicit record number) instead of TLS (which assumes strictly- 444 ordered delivery over TCP). 446 3. Stream-Free Operation 448 Minion eschews the notion of multiple message streams multiplexed on 449 a single connection. Rather than requiring every message to be 450 assigned to one particular ordered stream (or assigned to no steam 451 for unordered messages), each Minion message stands alone. Messages 452 are ordered and scheduled not by virtue of what linear ordered stream 453 they are assigned to, but by virtue of explicitly expressed message 454 dependencies. 456 4. Conceptual API 458 While different implementations in different languages may provide 459 APIs that differ in details and programming model, the common 460 conceptual framework of Minion APIs is as follows: 462 o Outbound Connections 464 * Create new Minion Connection to remote peer, with handler 465 function or object to receive incoming messages. 467 * Close Minion Connection when it is no longer needed. 469 o Inbound Connections 471 * Listen on a port for incoming connections. 473 * Upon receipt of incoming connection request, a new Minion 474 Connection object (substantially similar to the Outbound Minion 475 Connection object above) is generated, and delivered to the 476 application. 478 * Set handler function or object to handle incoming messages 479 received on an inbound connection. 481 * Stop listening for incoming connections. 483 o Sending Messages 485 * Create new Outbound Minion Message, associated with an existing 486 connection (either outbound or inbound), specifying the 487 priority level for the message. 489 * Optionally, indicate Sender Ordering for this message by 490 reference to some previously-created Minion message. 492 * Optionally, indicate Receiver Ordering for this message, or 493 Superseding for this message, or Chaining for this message, or 494 that this message is a reply to some previously received Minion 495 message. Note that these four options are mutually exclusive. 496 An outgoing message can be identified as a response to a 497 received message, or a subsequent member of a multi-part 498 message chain, or a message with a Receiver Ordering Message 499 Dependency, or a message that supersedes an earlier message, 500 but not more than one of these four things. 502 * Optionally, provide a reply handler function or object to 503 receive replies to this message. 505 * Provide (possibly incomplete) data for the message. 507 * Optionally, add further units of data to the message. 509 * Indicate when message is complete. This tells the Minion 510 implementation layer that it should now send the message. 511 Alternatively, a message can also be cancelled if it is no 512 longer needed. 514 * Dispose of the message when it is no longer needed. 516 o Receiving Messages 518 * Upon receipt of a message, a handler function or object is 519 handed a new inbound message: 521 * If the message is a chained continuation message, and a 522 specific handler exists for that chain, then that specific 523 handler is invoked. 525 * Else, if the message is a reply, and a specific handler exists 526 for the originating message, then that specific handler is 527 invoked. 529 * Else, the Minion Connection's generic message handler is 530 invoked. 532 * Read data from the message. For large messages, this may not 533 be the entire message. After one or more reads, a return code 534 (or similar) indicates to the application when the message is 535 complete (or alternatively, that is is incomplete, and will not 536 be completed, because it has been cancelled by the sender). 538 * The application may decide to reject a message before it has 539 been entirely received, by canceling it. 541 * The message handler may generate outbound messages in response 542 to the received message, including outbound explicit reply 543 messages, outbound chained messages, and simple outbound 544 standalone messages. 546 * Dispose of the received message when it is no longer needed. 548 5. Connection-Level Flow Control 550 Minion operates using connection-level flow control. Not having 551 streams, Minion does not implement per-stream flow control; nor does 552 it implement message-level flow control. This means that if a Minion 553 client sends a message or messages to a peer that fails to consume 554 those messages, then the entire connection could become staled until 555 those messages are consumed. For this reason Minion clients should 556 refrain from sending messages that the receiving end is not in a 557 position to consume. Minion supports arbitrarily large messages, but 558 this facility should only be used in cases where the receiver is 559 expected to be able to consume the message as it arrives. 561 [Should we discover that there are credible cases where message-level 562 flow control proves to be necessary, this design decision can be 563 reconsidered.] 565 6. Client Isolation 567 Minion allows multiple messages to share the available throughput of 568 a single connection. The sources of those multiple messages (if not 569 the same application) are assumed to be mutually trusting. Minion 570 does not attempt to prevent one message source on a connection from 571 consuming an unfair share of the bandwidth, nor does Minion attempt 572 to guard against a client that fails to read its messages, causing 573 the receive window to close, thereby preventing any messages from 574 being received. 576 In the event that some proxy or similar technology allows multiple 577 mutually untrusting clients to share a single Minion connection, that 578 application-layer code that is allowing the single Minion connection 579 to be shared is responsible for policing the traffic so that the 580 single Minion connection is shared reasonably. 582 7. TCP-derived benefits 584 By virtue of building upon TCP, Minion is able to leverage work being 585 done to enhance TCP. For example, Minion could eliminate the three 586 way handshake to set up a new connection via the new developments 587 being made surrounding TCP Fast Open. 589 Similarly, Minion could offer mobility and load balancing across 590 multiple paths by building on Multipath TCP. In addition, future 591 extensions to Minion could implement Multipath functionality using 592 messages at the Minion-layer rather than using TCP options, which 593 could improve compatibility with middleboxes that drop packets 594 containing TCP options. 596 8. IANA Considerations 598 No IANA actions are required by this document. 600 9. Security Considerations 602 No new security risks occur as a result of using this protocol. 604 10. Acknowledgements 606 Many thanks to Bryan Ford, Padma Bhooma and Anumita Biswas for their 607 contributions to the development of Minion. 609 11. References 611 11.1. Normative References 613 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 614 August 1980. 616 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 617 RFC 793, September 1981. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 11.2. Informative References 624 [minprot] Iyengar, J., "Minion - Wire Protocol", 625 draft-iyengar-minion-protocol-02 (work in progress), 626 October 2013. 628 Authors' Addresses 630 Janardhan Iyengar 631 Franklin and Marshall College 632 Mathematics and Computer Science 633 PO Box 3003 634 Lancaster, Pennsylvania 17604-3003 635 USA 637 Phone: +1 717 358 4774 638 Email: janardhan.iyengar@fandm.edu 640 Stuart Cheshire 641 Apple Inc. 642 1 Infinite Loop 643 Cupertino, California 95014 644 USA 646 Phone: +1 408 974 3207 647 Email: cheshire@apple.com 649 Josh Graessley 650 Apple Inc. 651 1 Infinite Loop 652 Cupertino, California 95014 653 USA 655 Phone: +1 408 974 5710 656 Email: jgraessley@apple.com